Project planning is clearly meant for people with an ability to ignore pain. An IT project plan is one of those voluminous documents with all those cute milestones, dependencies and resources. It is, unfortunately, not one of those brilliant schemes written on the back of a paper napkin.
In the past few days, I have approved a formal project plan worth somewhere between $5 and $15 million (vagueness included for the benefit of my client) which spans about six months of work occurring in 40 cities around the world.
A good plan, even one with 5,000 tasks being maintained using project software, has these features:
– far fewer than 5,000 tasks.
– agreement by people who sign your invoices.
– some vague connection to reality.
– a baseline which has been submitted to the client sometime before the end of the project. (By the way, a baseline is a copy of your first version of the plan that shows you just how bad your estimates become over time.)
A bad plan is one that is:
– used as a weapon, especially against you.
– kept handy when you need real toilet paper to cover your backside.
– written by a project manager whose knowledge of technology is less than that of a drugged squirrel.
If you are wondering why project managers curse so much, it’s because planning an IT project is not as much fun as spontaneous liver donations, but it’s awfully close. The problem is that planning is controlled clairvoyance. You are in fact trying to predict the future and, unlike Madame Zoingo, you have to write it all down so that people can annoy you later.
If you intend to author a plan, or even contribute to one, there are certain challenges you will face:
By the time you figure out exactly, or even approximately, how long a task will take, you will have already finished the task.
The endless explaining of your assumptions to everyone in the world will continue until the sun goes nova and collapses into itself from boredom. Everyone wants a project plan but – once in a Gantt chart – your assumptions are absorbed, never to be seen again.
If you don’t complete the plan, baseline it, and start it, you will never do a real day’s work again. You will stay forever stuck in the planning vortex. On the other hand, if you complete the plan too early, you will be asked to justify variances until your head falls off. Take your pick.
People seem to believe that the current staff can perform tasks in substantially less time than they have historically without major changes in the work environment.
The client always wants the project done faster for less money.
The money issue is big, not just because of our monetary-oriented society but because in most cases adding staff rarely speeds things up in a team environment. For a proper explanation of this, read The Mythical Man-Month. Written before PCs existed, you will discover that nothing has changed.
However, let’s assume that you do have a way to increase staff which will actually reduce the timeline. Your client still won’t be happy, because:
Adding staff costs more money.
Adding time to the plan costs more money because whatever it is you are building has likely been justified based on cost savings over time.
Planning more adds time to the plan, which in the end costs money.
Now that you’re depressed, my tip is to forget everything and think intuitively. Write on the left side of a piece of paper today’s date. At the far right, jot down the last possible date the project could be done without you being fired (for example, Dec. 31, 1999). Then roughly mark out each month between the two dates. Stand back and ask yourself, “Given what I know now, which mark on this page represents a date that seems reasonable to finish this project?” Don’t answer right away, let the quiet voice in your subconscious tell you the answer.
Then go back and write a plan that ends on the last day of the month you chose.
Ford is a Vancouver-based systems consultant. He can be reached at quokka@portal.ca.
