The Nimble PM

I just had another one of those ah hah moments.  Intuition needs to be grounded in context.  By this I mean sometimes we have the intuitive impression that something is important but not the exact context in which to evaluate whether our intuition is right or not.  Years ago I stumbled onto a project portfolio management technique I now think of as context seeking.  It only works when you know the contents of the proposed portfolio very well and have a sense about the projects.  If pressed it would be possible to articulate to someone all of the synthesized information you are actually attempting to consider (after all that’s all intuition is; just synthezied knowledge held in the unconscious) but if you’re smart and don’t share your analyses prematurely no one will ask you to. 

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 just had one of the those nightmare customer service experiences with my new phone company, who shall remain nameless to protect the guilty.  What I found particularly interesting was that the experience is now driving me to make a decision I NEVER thought I’d consider which is to give up my landline.  So what does this have to do with project management?  The answer is we need to be very careful about making sure people think through exactly what some of the business process and system changes they implement actually mean over the longer term.  Based on experience I know that very few IT departments have a way to ask what the effect will be on revenue if the billing system goes down.  In fact I’m sure they assume there will be absolutley no effect.  After all who gets upset if they can’t pay their bill right away?  Assuming they even think that far, I’m sure no one asks what the effect on revenue will be if they have the billing department try and upsell customers on new services (which should generate revenue) to the exclusion of having them able to help with a current account.  Now common sense should say that a disgruntled client won’t buy more service but I’ve sat in meetings just like the one that I’m sure happened when the Customer Service decision was made.

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.

I was just doing some research on change management and I had another light bulb moment.  The article I was reading said you needed to make a business case for change, and my immediate gut reaction was “on what planet?  Nobody ever makes a change for the sake of change.”  In my experience most organizations, change is a by-product of acquiring something else that is deemed to be valuable.  Let me try and be more specific – if there’s a bright idea by some process wonk that by changing action X, the process can be improved and nobody else thinks the process was broken – it’s a very BAD IDEA.  If the company needs to improve their logistics process because their lunch is getting eaten by the competition and everyone in the company knows it; making a process change is a very GOOD IDEA.

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???

For those of you who have never discovered the LibraryThing, I have to say it’s both a blessing and a curse.  A blessing because if you have as many books as I do it actually provides a way to categorize and organize (at least virtually) what you have.  It’s a curse because it’s the books lover equivalent of playing Doom.  You get started and the next thing you know you poke your head up and it’s 5 hours later and the family has eaten dinner without you.  The LibraryThing also has a feature that Amazon must love.  It will tell you who has a library close to yours.  This means you can troll through there books and go “oh goody…  There’s a book on this subject and one on that, and how I have I never known that this book exists??”  To give you some idea of what LibraryThing can do for you; here is my current tag cloud based on the almost 400 books in my collection.

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.

How many of you have given this advice to a new PM?  I know I have.  I remember vividly explaining to a fellow consultant the mistakes she made in failing to determine exactly what the client wanted when she started the project and then offering a few techniques that I felt would help her in the future.  The only problem is that the advice I gave her, while sound was completely wrong for the situation she had found herself in.  What’s worse was, that my advice didn’t reflect the very things she’d seen me do when I came over to help the project get back on track.

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.

I’ve used software package “A” (the product shall remain nameless since this is a personal opinion and not a Gartner MQ type of comment) since the first version came out on windows 3.1.  Originally is was cheap enough that I didn’t mind being a loyal customer and I upgraded faithfully.  Somewhere about 10 years ago the upgrade price started to get progressively more expensive but they still offered the occasional sale so they kept me in the fold.  For whatever reason, I simply draw the line at more than 100 dollars to upgrade software.  So at $149 they started losing me and at $179 (as I remember) I decided they were completely out of their minds.  I stopped using the software and I stopped recommending it entirely.  Fortunately for them — they do what they do (keep track of disparate pieces of information) better than any other software I’ve ever used.  So it was with a huge amount of reluctance I went out to the web site to see what it would cost to get a version that would run under windows 7.  Surprise, surprise they now offer it at $50 dollars a year.  I’ve never been a fan of not owning my software but at 50 dollars a year for the most current version there is only one alternative.

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

A while ago I asked the Gartner PPM exchange community on linkedin to answer a couple of questions about their PPM methodology.  One interesting outcome to this survey is that the majority of respondents answered that they had a separate methodology for Agile.  I’m guessing that they meant they had a separate SDLC for Agile rather than a separate PPM method for managing an agile project since my experience is most organizations haven’t spent a lot of time truly considering what and why agile is different. 

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.

I’m going to be writing a note about packaged Project Management Methods and I thought I’d start out by asking some questions about the decision process many of you use to select your approach toward the adoption of a PM method. 

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.

One of the topics I had planned to spend more time discussing in 2010 is change management.  I found this quote today that I think offers a nice perspective on one element of change management

“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.

woke up this morning thinking about the fact that when I talk to CIOs many (if not most) tell me they know they don’t have the best project managers currently on staff.  My own experience would absolutely confirm this as true so the question is why don’t we fix it?