The dirty secrets of project management revealed

29.06.2015
For business systems, the project go-live date really does matter -- and project managers seem willing to sacrifice budget limits more often than they're willing to blow past a scheduled deadline. There are sound business reasons for doing this as bonuses, commissions and stock valuations depend upon the revenues and earnings for the quarter. So you don't want to make any changes that would mess up this quarter's results, but you do want to implement changes as early as possible next quarter.

Now for the problem: You've got a few days to go, and the time pressure to do the cutover will only increase. And with that, the collective IQ of the project team will only decrease. Because of the 4th of July weekend, everyone will be lobbying for a slash-cutover to the new system so everyone can make their Q2 bonuses.

Institutionalized rationalization

In the final push to release, you'll hear all kinds of helpful suggestions to expedite things:

In other words, you'll hear all kinds of half-baked, rookie ideas coming from people who are otherwise professionals. This is the kind of stuff you'd immediately reject a job applicant for suggesting, but when the ideas come from a review committee full of bosses...well, you sometimes have to bite your tongue (and sometimes almost clear off).

We've all been there. The whole industry has been there since the '60s ("The Mythical Man Month" and horror stories from ControlData OS releases come to mind), and only the most zealous Agile team will resist the temptation to cut corners.

But the industry doesn't seem to be getting any better at this, particularly when it comes to projects with lots of dependencies, or with complexities that could have been avoided. I'm particularly irked about the kind of magical thinking that just begs for train wrecks: "well, while we're at it, let's add THIS risky artificial complexity to THAT out-of-control project..."

The answer is in the question

How to avoid this kind of project schedule crisis Make the project less tightly coupled. We did it with software (asynchronous web services), why aren't doing it with the project itself

Try these ideas on for size:

Some of the above ideas may sound nuts. But why are we still making project decisions with management ideas from 50 years ago It's time to try something new.

(www.cio.com)

David Taber

Zur Startseite