An Interesting Exchange on Managing Software Development Projects
On 4/3/04 Joe Marasco wrote:
As much as we would like to rigidly define KSIs [Key Success Indicators] and stick to them, the reality is that the world changes, sometimes significantly, over the duration of any non-trivial project. To the extent that we are incapable of perfectly predicting the future, some of our original KSIs may become irrelevant during the course of the project's execution, and other new ones may become important.
Now you could completely re-scope and start over, ...
On 4/4/04 Max Wideman replied:
If what you want to do in the first instance is create a voyage of discovery, then so be it. In which case, project management is largely irrelevant. The objectives of the majority of projects, and certainly of project management, is to create something that adds value and to do it cost effectively. Thus, project management is about control. (Some prefer "effective guidance" or some other such similar euphemism.)
Of course, "control" can be over done, but I would argue that in that case the objective of cost-effectiveness has been defeated. If you don't want to exercise any control, then dispense with project management altogether and save the overhead. Which is exactly the problem I have with Agile ...
[Regarding re-scoping and starting over] Actually, in most cases that is exactly what you should do. The unfortunate part is that few people recognize the correct timing and don't have the moral fortitude to do so.
On 4/4/04 Joe Marasco responded:
With respect to the "voyage of discovery" comment, let me make myself clear on this issue.
I am definitely against having serious projects become "voyages of discovery." It is very important that technology projects, especially in the area of software development, not lose sight of the business objectives. Effective project management in my view consists of applying good business discipline to technically challenging projects so that the result makes sense both from a technology and business point of view. I certainly don't believe in giving the engineers free rein, which is why I also have a problem with the Agile "methodology." It's just too loose for my tastes.
Having said all that, I also have seen far too many projects go down the tubes due to high-ceremony process and "over management." In particular, when things begin to go wrong, the wheels of the machine seem to grind the wrong way. Audits, witch hunts, random re-scopings, and other manifestations of premature panic appear. These turn out to be by and large counterproductive. They are also a manifestation of weak leadership; the "captain" has gone to the procedures manual to figure out how to steer the ship through the storm. Bad idea. Every storm is different. Always throwing out the drogue anchor is not a good idea.
What I believe the truly great project managers do is the following. They get a good grip on what is not working. Then they do two things: they work internally with their teams to make the necessary adjustments to get the car out of the ditch (boy, are we mixing metaphors here.) Then, they go to their management and explain. They tell their management what they are doing to get going again, spending as little time as possible explaining how the car got in the ditch in the first place, which most of the time their management won't fully appreciate anyway. They provide covering fire for their team. They take the heat. This is what good project managers do.
The net result, if this is done right, is the following. Expectations get ratcheted down without causing the huge "crisis" that would be precipitated by pulling on the emergency stop cord and starting all over again with a new re-scoping. While that is intellectually the "cleanest" solution, it is often far too disruptive to be practical. The team gets to keep working without taking time out to get flogged, which would serve little anyway. If it is a good team, they are already working harder not to let down their boss again, and are more sensitive to critique from him than from anyone higher up the chain anyway. The project manager gets to negotiate the best outcome, which makes sense because he is the one person in the whole chain who has the most context and can figure out the best compromise.
I actually believe that the approach I outline is the hardest way to proceed, but also the most effective. It requires real management, not application of formula. It requires context, diligence, moral fortitude, courage, intelligence, domain knowledge, and, most important, good judgment. But that is why to some extent really good project managers are born, not made.
So what I am proposing is not the absence of project management, but project management at its best. The reason it is a minority point of view is that you can't encapsulate the approach in a "one minute manager' book of "best practices." But, in my humble opinion, if your project manager is not capable of doing what I suggest, then no set of best practices is going to save him or his project anyway. At best, they will help limit the damages.
Footnote:
Joe Marasco is a retired Senior Vice President with Rational Software, now a part of IBM. He spends his time indulging in many hobbies, including writing. You can find out more about him on his web site at http://www.barbecuejoe.com.
|
