Project Management - In the Trenches

As I lay on the operating table watching the anethesitist's mask come toward me, I shudder to think about the fact that in a few moments my brain will be totally exposed and in the hands of my trusted physician.  The problem discovered required immediate attention.  I never got a chance to meet the surgeon who would be performing the life and death emergency surgery.  As the gas starts to take effect I glance ove, the surgeon is walking into the room...strange, he looks familar....no....it couldn't be......
 

The doctor is a young Jerry Lewis, circa the Nutty Professor era.
I scream in horror, then wake-up. It was only a dream.
I really shouldn't eat so close to bedtime.
So what does my cold pizza induced nightmare have to do with project management you might ask?
More than we might want to admit, I answer.
You see, people in charge around many organizations, do not understand that project management is a skilled profession that requires training, expertise, and experience.  Instead they think that they just need an average person as a placeholder, someone they can call the project manager.  This is humorous as those Holiday Inn Express commercials where the guy walks into the nuclear power plant control room and calmly circumvents a meltdown after which the awe-inspired control room operators ask after his credentials.  Is he with the Atomic Energy Commission? 

No but he stayed at a Holiday Inn Express last night! 

You get the idea.
Have you ever managed a multi-million fast -track 18 month critical risk project?
No, but I slept at a Holiday Inn Express last night!
If you're not a project manager and have had thoughts that just anyone can do this, then I want you to go and apologize to your poor, trained and experienced PM right now.   What did he ever do to you?
If you're an experienced PM then try to use some analogies with your superiors to help them understand the dangers of underestimating the value of experienced project management.  "Sure boss, let John from janitorial do it,  I'm gonna be busy running AR for Sara for the next couple of months."
Am I being snobbish, insisting that only certified PM's be allowed to manage projects? No.
I and many others were managing projects long before the Project Management Institute and the holy of holies the PMBOK ever existed.
Am I insinuating that project management is an exclusive realm?  By no means.  I think that there is a place for business people (of all types) who know how to manage projects as part of their larger job description in any organization.
The point that I'm trying to make is that you don't become a brain surgeon by putting on the costume and you don't become a project manager because someone says you are.  If you want someone to manage a project, make sure that they have the experience level and skills commensurate with the project to be managed.  A great approach would be to identify individuals who you think have the proper skills, get them some training, and then give them greater responsibility as they successfully or unsuccessfully manage larger and larger efforts.  We give kids "Learner's Permits," don't we?   A really bad approach is to realize at the last minute that an experienced project manager who is capable of managing a multi-million dollar fast track effort is going to cost you $250/hour and scrounge around for a mid-level manager with some free time as a substitute.
Could the mid level manager learn everything and have things come out ok?
It could happen.
But is the risk to your organization worth finding out?
Probably not.
Let the mid level manager cut his project management teeth on a low dollar low risk project and find someone with experience to drive the "big one." 

You'll sleep better at night!

Oh yeah, don't eat cold pizza with anchovies before you go to bed.

 

Many times we worry about the technical details of a project, thinking that that is where we will win or lose.  Is it possible to have a successful project if the end product doesn't meet expectations?

Any good project manager will tell you that a successful project is one that stays within scope, is under budget and on time.  What is missing from this statement is the underlying premise...a successful project meets expectations. Scope, budget, and timing are all objective criteria that document (as best can be done) the expectations surrounding a project.

Think about it for a second.

 

The impact upon how you manage projects will be profound.  Instead of worrying about bits, bytes, interfaces and GUI's, you'll start to go back to the fundamental questions.  Who is the sponsor?  Is he actively involved or is there a disconnect between him and the people that he has given authority?  Have you identified all of the stakeholders?  Have you documented their expectations? Have you documented the fact that some expectations cannot be met because of project constraints?  Have you built consensus?

 

These are the important questions at the beginning of any project.  The better that you answer these questions, and document those answers, the better able you will be to manage your project as it moves from initiation and planning into implementation.
 
There are two fundamental documents that are invaluable in helping you build consensus and documenting this process.  The first of these is the business case and the second is the project charter.  Check out the examples in the documents section of this site.  You'll see that these documents, if used correctly, will force you to seriously consider, question, and document the expectations of your project.  Remember, a journey of 1,000 miles starts with a single step, but if that step is in the wrong direction, it'll take you much longer to get there!

 

Not worth the paper it's printed on."

"Talk is cheap."

How many cliches can you find to discount the value of words? How do you overcome these attitudes when developing the most important document of your project's life -- The Project Charter?

Talk is cheap.  Unfortunately, preparing for a project requires a great deal of communication.  If you haven't realized it, approximately 80% of project management comprises communication in one form or another.  Perhaps the single most important document in your project's life (after the final acceptance ;) ) is the Project Charter.  Unfortunately, far too little time is spent in developing this document.  The results can be; a project that has no bounds, a project that does not have a large enough scope, inadequate risk planning, improper communication and even an unempowered project manager. 

Not really desireable project traits are they?

There is a principle in learning that says that people will only replicate about 80% of what you teach.  As a project manager it is essential that you remember this rule and that you over teach by at least 20% the importance of the project charter.  That way your stakeholders will focus the proper amount attention upon this defining document.

According to PMBOK the project charter is the essential tool that delegates authority to you to manage resources that may not typically report to you.  Given that you are being asked to martial resources to complete a task in a certain amount of time this empowerment is essential to your project's success.  The project charter is also the base document for defining roles, responsibilities, risks, milestones and deliverables. 

"If your stakeholders don't take the Project Charter seriously, then I guarantee that they are not taking the project itself seriously."

In that last statement lies the secret of achieving the proper level of respect for the project charter.  You need to let your stakeholders know that the actual document is not important because of the paper it is printed on. Rather, it is important because of the agreements and principles that have been built between people and captured in paper form.  As a project manager you must constantly guard against the attitude that many people have about the tools that we use.  Stakeholders and outsiders can view our documents as an attempt to manage the effort through documentation, instead of what it really is -- documenting the management of effort.  There is a a HUGE difference between the two.

Of course you have to be constanly on guard to make sure that good practices don't become "religion."  A really good project manager knows how to achieve the proper balance of documentation for the given effort, maturity, size and risk of any given project.  Again, the project charter helps to set that tone and the rationale for the level of documentation (or lack thereof) that will be maintained throughout the rest of the effort.

Make sure that your stakeholders understand that when you capture words to paper, that they are important, not because of the paper they are printed on, but because of the ideas that they embody.  Create a good project charter and your work will be far easier.  If your project charter isn't worth the paper it's printed on, your project will be worth far less.

Good Luck and Good Projects,

Rob

Getting things done right shouldn?t be hard, right?

 

We purchase things and have things built every day in the ?real world.?  But, when we go to buy and build things in the IT world all of our common sense seems to fly right out the window.  Take for example the need to build or implement a large-scale (read multi-million dollar) system.  It seems that you would make absolutely certain that you knew exactly what you wanted from such a beast and that you would make every effort to plan for problems and changes.

 

I like to use analogies so that people can relate the ?real world? to the nefarious world of project management.  A very good analogy (one of many) is building a house.  Very few people would give a sum of money to a contractor and say, ?I want a house.?  You can be sure that before someone builds their ?dream home? or even a modest starter home that that person has spent considerable time and money having very specific plans drawn up that specify the type of home that they want.  This is nothing more than scope in the PM world.

 

Unfortunately, we still have large pockets of people that think that a vague idea accompanied by several million dollars is a replacement for scope.  To go back to our analogy these people would say something like, ?I want a house that costs $200,000. Can you build me one??

 

Now an ethical contractor would not take that customer?s money.  They would insist that the customer develop those detailed plans that we talked about earlier.  They would also insist that the customer set aside a contingency fund for problems and changes.  But in the IT realm, as in most other trades, we have a group of either uninformed, or unethical (you take your pick) contractors who will gladly take a vague specification and promise delivery of a super-duper whizbang application all within the multi-million dollar budget and on-time no less.

 

How will they do it, you might ask.

 

The answer is that they won?t.

 

This is the classic ?the scope is in the mail? problem.  The contractor starts building and defines scope as they go.  ?Scope, we don?t need no stinking scope,? is their battle cry. ?We?ll just implement the solution and worry about the details later.?

 

An ad hoc poll of former project managers that now manage fast food establishments shows that this methodology simply does not work.  It has been empirically proven, time and time again, that one of two things will happen.  In the first scenario, every time that a piece of work is encountered that was not in the original ?build me a house? scope the implementing company will issue a change request.  ?Oh you wanted windows in that house?  Well that will cost you extra.  Changes?  Oh, they are billed at our ?normal? bill rate not at the rate we quoted you in the RFP.?  The price of the house soon exceeds the budget of the customer?s whole IT organization for several years (with compounded interest).  The implementation stops.  Lawsuits ensue and senior IT executives glut the job market for fast food establishment managers with Masters degrees in IT.

 

The second scenario is quite different.  Work happens, change orders are written, and denied.  The enterprise gets a house that is not fit for occupancy.  The senior IT executives responsible, beaten out by their more acute predecessors from scenario one, end up merely flipping burgers instead of managing the fast food establishments.  There is a true sense of justice and on the job training though as the burger flippers soon come to understand the slogan, ?have it your way.?

 

OK, so I really didn?t take an ad hoc poll of former project managers that now manage fast food establishments.  You caught me.

 

The point remains the same.  Without a good definition of scope before contract award the chances of success are less than 20% that you will be on-time, in budget, and in scope.  58% of projects that start this way will get 42% of originally desired scope (scenario 2) and pay 189% of the originally budgeted cost (scenario 1) for that less than adequate system.  22% will be halted after spending lots of time and money.  Not good odds.

 

How can we stop the insanity?

 

We need to simply use the same common sense that we use in our everyday life and make sure that scope is ?in hand? and not ?in the mail.?

 

Good Luck, and Good Projects

 

Rob