Site icon IT World Canada

Project management for weasels, by weasels

Project managers are lying, self-interested flatulent weasels.

At least that’s the way I felt after a recent project steering committee meeting. Perhaps I am overreacting – a little. Sleep deprivation, fear of taking a vacation and too much coffee may have played a role.

Notwithstanding, being the project manager I am the most familiar with the timeline of my project. Irritatingly, an inextricable deadline has appeared on the horizon and we don’t have the gas to get there. Here is how I know:

The project is a full desktop and laptop PC rollout, intended to get rid of non-Y2K friendly PCs and software, standardize software and connect everyone to the company network. We started the hardware/software rollout on April 7. At time of writing, it is July 13, one week past three months into the rollout.

We have completed 58 per cent of the work in 3.25 months. A deadline that allows a margin of error is Sept. 12. This gives us two months. Assuming we do the same amount of work at the same rate (questionable), we need 2.35 months in which to do it.

At the same time, the team is tiring, slowing down and running into a tougher area of the project. As with everything the last 20 per cent of the work takes 80 per cent of the effort and definitely causes 80 per cent of the personality disorders.

If this isn’t a case for more resources, I don’t know what is. Fortunately this is the type of project where if you take a short time hit for training people you will make it up and start to move faster.

At the steering committee meeting I prepared solutions and expected to be grilled but, by the end of the meeting, I also expected my wishes of additional resources to be granted. As you can guess, this did not happen; I became the smelly weasel mentioned above.

Where did I go wrong? I even know what is causing the rollout to slow-down. There are two classic problems: the users are getting in the way by asking too many questions, because there isn’t any on-the-spot training; and there have been surprise technical problems that were not in the plan. This is because, if they hadn’t been a surprise, I would have planned for them.

What I heard in my meeting was: “Near the end, we can use the regular service people to get it all done.”

In the history of rollouts in the universe, this never works. Projects usually cause increased demand for the regular steady-state workers. I didn’t think to ask when “near the end” was.

For round two of my pitch, I will ask my clients to pretend it’s now “near the end.” They must now stop all other projects and pray that there are not too many critical problems. How soon will the steady-state people be able to fully devote themselves to my project? Three weeks? A month?

The other thing I heard was: “When the users ask questions, tell the team members to say that they can’t help them and that it’s the Training Department’s issue.”

Yeow, I thought. Yes, Training should have been more involved, but they were busy with other things. The problem is not whether to train or not to train, but the lost time the teams incur having to tell the users to shove off when they have training questions. Often it’s quicker to answer the question.

Now what? I have a late project that the clients and my service providers don’t think is late. Should I panic? (Nah, done that.) Run for the hills? (I live in Vancouver; the hills are mountains.) Cover my butt? (Done that too – that’s why I’m part man/part weasel.)

What I really want is to finish the project on time, spend just the right amount of money and go on vacation someplace where my parting words from the project aren’t “I told you so.”

Ford is a Vancouver-based systems consultant. He can be reached at quokka@portal.ca.

Exit mobile version