Overlooking tradeoffs could kill your project
Tradeoffs are good
One of our readers, Bill Nicholls, has just written in with a comment on my "Housebuilding as a metaphor for software development" blog.
He says: "Deadline, quality, functions - pick any two." In short, every project is a tradeoff. The above assumes that cost is fixed, but if that is a variable, the above line becomes: "Cost, deadline, quality, functions - pick any three."
"Every project has those characteristics, from small to very large. Project management is the process that (tries to) optimise the result by the priority of the tradeoff items. The specific [algorithms] are left as an exercise for the student. :-}
"I think that in most projects the above selections and priorities are not made a priori, but only get discussed when some part of the project looks like it might fail. To me, this delay in selecting the order of tradeoffs is the critical failure of most projects, rather than the planning."
Well, I see what he means – although the reason for any delay in managing tradeoffs may be that the "pointy haired manager" won't accept that there are any tradeoffs: "Well, of course I want it tomorrow. I didn't get where I am...What do you mean that means that there will still be defects in it? Aren't you aware of my 'zero defect' initiative? If you aren't I'm sure I can hire people who are...What now? Deliver less function? In two words im-possible. I promised that functionality to the CEO."
In other words, in immature organisations rational arguments over tradeoffs often aren't possible. Sometimes managers want to adopt politically expedient deadlines without compromising their other objectives: 100 per cent security, zero defects, and the lowest possible cost. Oh, and zero risk of coming in late.
And this sort of exchange probably means that the pointy-haired manager has a resource he isn't exploiting (or appreciating) - the experience of his or her developers.
Bill Nicholls again: "Having a plan is important, but knowing in advance how to tradeoff the priorities and when to implement those changes are the missing pieces in a lot of projects I have seen and been involved in. And this stems from another pool of experience I have been immersed in - understanding complexity and specification drift.
"The more complex a project is, the more probable that the project will run into the need for tradeoffs. This is a result of finding hidden interactions the hard way, and is almost unavoidable in large projects. Specification drift comes simply from the nature of human beings. Ask anyone to specify a screen layout, and go back a month later with the same question. Need changes? Wotta surprise, Not.
"In summary, projects need their tradeoff parameters set at the beginning, not when trouble appears. The more complex the project, and the more people involved, the bigger the chance that you will have to use that information to deliver the best results."
I can only agree. But something similar applies to a lot more than just project management. It is always best to think through your contingency plans with a clear head – before something actually fails and everyone is in headless chicken mode. This applies equally to business continuity planning and disaster recover and to the "compensating transactions" needed when something goes horribly wrong in a loosely-coupled asynchronous e-commerce environment. ®
Sponsored: DevOps and continuous delivery