The next step that I’ve always followed is to develop a long list of appropriate contexts and then bounce the projects against them.  Given that I already have some sense as to which things should be significant I can do this analysis fairly quickly.  Sometimes I’ll find that what I thought was relevant loses its importance in the majority of contexts and sometimes I’ll find that something is over whelmingly important when looked at from a certain point of view.  And therein lies the reason this technique only works for a small handful of people.  You have to know the projects, you have to have a highly developed sense of intuition and you have to be able to develop a list of enough contexts that you can connect all the dots into an integrated whole, and finally and most importantly you also have to think that doing all this work is fun.  After almost 20 years of trying to teach this technique I’ve realized that it’s the later activity that is the most important and the most telling.  The biggest part of what makes doing this type of analysis fun is the way your brain is wired.  For some people this technique will be a  tremendous amount of work for very little payback, whereas for people who are associational thinkers (see  http://bit.ly/9ZO4aI for an explanation of associational thinking) it’s fast and generally yields a few nuggets of gold we couldn’t have gotten to any other way.

I understand everything the company has done to cut costs and I’m sure all their decisions made sense internally BUT it’s clear no one ever asked the question “and how will our customers react?”  And they clearly missed the concept that you can’t cost reduce your way into profitability when your cost reductions all directly lead to reduced revenue somewhere down stream.

I’ve been fighting the concept of going to VOIP, but today’s experience has absolutely made my decision for me.  I will be getting rid of the second line and replacing it with VOIP.  If that works well I will be dropping my primary landline as well.  I’ve actually worked for one of the baby bells and I know the caliber of people and the level of dedicaton that defined much of the old telecom industry.  I am now finally willing to admit that the telecom industry of old and the service level that supported it is gone the way of the dodo bird.

When I was much less experienced than I am now (reader younger) I routinely came up with good ideas of how we could improve the way we did things.  I had two ways of handling these good ideas.  In some cases I’d go walk around and talk to the people in the chain and say “are you on board with this if I implement it?”  If they said yes, I never asked permission I just did it.  These tended to work out quite well.  The problem was always with my big ideas that involved spending money or getting other business units to change where I didn’t have a personal network.  Generally I’d have to go to management and 99% of the time they’d say “Good idea, but not now” and sent me back to my office.  Most staff professionals get very angry and very frustrated when their ideas get shot down but I found it left me more curious than anything else. I knew they had a reason for making the judgment they did – I just didn’t understand it – hence the light bulb moment.

 What I now understand is that contrary to most literature, incremental change imposed by somebody with a bright idea is VERY EXPENSIVE and largely unnecessary.  Joe Proctor, a former CIO of Intel, gave me the best advice on the subject I’ve ever received.  His question was “who else thinks this is a problem worth solving right now?”  Sometimes Joe and I didn’t see eye to eye but that question was profoundly brilliant and is 90% of the threshold condition for making any change (the other 10% is what I call the burning building test — but that’s a subject for another blog).

So a proposal that does not have advocacy from a broad range of people is simply too expensive to do because it creates unnecessary change AND change has a price.  (see my blog The Unfamiliarity Factor is Critically Important in Change Management ).  The more I think about this the more I understand why I’ve looked at some of the “level 4 continuous improvement” literature and shuttered in horror (and NO the Gartner maturity model for PPM does not have a continuous improvement level).  I believe in continuous improvement but it absolutely has to be from the ground up.  If it’s top down it needs to be so clear cut as to why it should be adopted that people are literally beating on management to let them do it.  

There’s an old book called Up the Organization by Robert Townsend that had another piece of advice that I immediately knew was absolute wisdom the moment I read it.  Townsend’s contented that it was essential to never introduce a small change unless people were so busy and so stressed they would accept the change with open arms because it was going to help them (he was talking about adding staff but the advice is extendable).

I hope by sharing my insight that I can possibly help reduce the frustration I know many of you feeel about the fact that your organization is refusing to follow your lead and get on the formal project management process bandwagon.  After all top management asked you to make the change and then they (senior management) refused to force people to accept it, leaving you feeling like you are banging your head against a stone wall.  But feeling frustrated isn’t worth your time.  The answer to the problem is actually very simple if you can’t sell it bottom-up and there’s no burning building to drive adoption top down — go back to the drawing board and rethink what you are doing.

Thoughts?  comments?  Violently disagree???

If you want to dig deeper and see if LibraryThing would work for you check it out at www.LibrayThing.com.  It’s free for the first 200 books and then they ask you to pay $25 for a lifetime membership.  Could some of the software features be better?  Of course but truly it’s good enough to use now, so go check it out. By the way if you want to dig down further into my library, just run a search on the Nimblepm. Also, as a book junky,  if you have a book to suggest that I don’t have please let me know and tell me why you’d recommend it.  Consder it my attempt at social bookmarking.

Just like the quote above from another PPM blog, my advice focused on talking to the customer to get the requirements and indirectly implied that every client should know exactly what they wanted so that the PM could go away and execute.  The only problem was sometimes the client absolutely doesn’t know what they wanted because it had never been done before and it’s the PMs job to work with them to help them find out what they needed. 

Unlike the PM I was advising I recognized that the only way the project could be successful was to take an approach that supported Rapid Application Development  (the precursor to agile) so when the VP asked me to take a look at his prize project which was tanking badly, I walked over and knew what to do. I got the team talking to the users, shifted over to a plan for six 30 day release cycles and then got down to work iterating ever closer to what was going to get them to done.  If I reflect back on the situation the major skill I brought to the party was the fact that I wasn’t upset or concerned that the users didn’t know what they wanted.  I had a 4 GL tool for rapid development (a proprietary piece of software that was unmaintainable in the long term but well suited for the short term) and a good team of people who were committed to results.  

Looking back on it, I hope the new PM I was talking to watched what I did and paid less attention to what I said.  Yes, projects most often fail when no one know where they are going.  And yes, we (as PPM Leaders) do need to spend time making sure our PMs know how to help the client define “What done looks like”. But if the client can’t really paint the picture and there isn’t a choice to delay the project to a later date when things are clearer, we need to ensure that our PMs know to to put on their hiking boots and to plan for a few extra twists and turns on their way to a destination that someone will recognize when they see it.  

Projects are inherently uncertain activities.  Obviously some projects are more uncertain than others, but in the final analysis being prepared and comfortable doing something the hard way probably ensures that the easy stuff gets done more reliably as well.

The exact opposite situation exists with software package “B”.  I’ve upgraded faithfully until version 7 and I’ve now decided I’m off the band wagon.  (I just WON’T pay $179 especially when I get 90% of the most important feature functions in a free version from somebody else).  Are the free/SaaS products as good?  Nope, not in total, but the question I’ve come to ask myself is do I care?  Do I get enough out of them to make them worth the price especially since it’s coming out of my own checkbook? I don’t like to change any more than the next person but I’m finding as part of the “new frugality” that this economic crises has engendered that I feel more secure saying to a vendor “I’ll pay for what I use” which is the concept that underlies SaaS.  

So why do you care about any of this, if you are in charge of a PMO or managing a project?  I think the answer is that the model underlying our software acquisitions is changing. What we need today may not be what we need tomorrow and the more rapid the possible change cycle the less attractive it is to invest heavily now in something that may have a very short life-cycle.  I also am a big believer in starting small and then seeing what I think before I spend real money (by recommending a purchase at my company or somebody else’s).  So today I’ve decided to go SaaS with too productivity tools.  I’ll report back in a year and we’ll see if it’s money well spent or if I think it was a mistake and why.

I’d  love to hear from other’s looking at the same issue either personally with applications you run to improve your own productivity or professionally with PPM software you’ve chosen to acquire for your organization

Back in 2005 a group of us who had been in the “agile” space since before we even knew to call it agile got together and spent a few days attempting to articulate exactly what we meant by Agile Project leadership.  Our output was entitled the Declaration of Interdependence.

The list as you can find it on the Agile Project Leadership web site is as follows:

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliabilitythrough situationally specific strategies, processes and practices.

While the statements have value in and of themselves they have more value when used as a basis for defining how Agile Project Leadership actually operates.  In future blogs I intend to explore the statements in more detail.

If you’re game to take a short (10 question) survey compliments of survey monkey then please go here.

 Thanks in advance for your participation.

“It’s called the culture buffer because you have to put effort in to get past it and break through. It’s a buffer because it is highly resistant, not because the old is bad and the new is good or that the old is good and the new is bad, but because it’s what we have got used to. Good or bad doesn’t come in to it.”
The ChangeFactor

I think we often under estimate what Martin Fenwick calls the “culture buffer” and what I call the “unfamiliarity factor”.  It’s actually quite simple — difference requires attention and attention requires energy.  As a normal over committed and over stressed human being I will always want to minimize anything that I consider low value that requires my attention and hence consumes energy.  In New Zealand it’s resistance to a new formulation of crème eggs for Easter, for me it’s been diet drinks with the splenda rather than aspartame. When I grab a diet drink I want it to taste like I expect it to taste so there’s no thought involved (the focus is on quenching my thirst).  If my first sip says “this tastes different” then I have to decide if I like that taste or not and if I don’t whether or not I’m going to continue to consume the product.  If my answer is no, then I need to go in search of something else to quench my thirst and the whole thing has turned into a production.

Software Projects that make small but annoying changes to user interfaces are an area we need to focus on more consciously when we’re making decisions about what’s included in our projects.   Some organizations respond by changing the new user interface back to the old to make users happy, BUT that might be a very costly and unnecessary fix.  The right answer is simply to be conscious about it and actually make a decision as to the cost/value of the change.

By the way the best discussion on “value” in this context that I’ve read recently is Stand Back and Deliver.