Software Development Projects

The realm of software development, there are broadly two approaches to project planning. The first approach treats the project plan as a predictive tool, a guide to what we can reasonably expect to happen given where we are now and given the present state of our knowledge. Taking this approach, the project plan is a living document.


When reality diverges too much from what we had planned, we alter our plan in order to keep it realistic. The second approach, on the other hand, treats the project plan as something more like a set of commandments, a binding contract whose timings must be adhered to. Taking this second approach, reality is forced to conform to the plan, come what may.

Things to Know About Software Development

Although few project managers would openly admit to being adherents of the second approach, I know from my experience of software development projects that - deep down - many of them are. A common scenario in the IT industry is that, before one jot of estimating has been done, someone senior to the project manager has decided what dates must be hit. Let me stress that this, in itself, does not have to be a bad thing.


Whether it becomes a bad thing depends on how the project manager responds to it. If he adopts the first approach, he will try to find a way of planning a realistic project (and this may mean somewhat decreasing the scope of what is to be delivered) whose timescales are as prescribed. He will also accept that despite his team's best efforts, meeting those timescales is not guaranteed; re-planning may have to be done in the future if the dates prove unachievable for whatever reason.

Managing Expectations In Software Development

He will be open and honest about all of this with the project stakeholders, explicitly communicating any anticipated reduction in scope or quality, as well as highlighting the very real risk of project slippage. If he adopts the second approach, he will pledge to deliver the project to exactly the dates prescribed, with no compromises.


He will not seek out estimates of effort from his own team - or if he does, he will refuse to accept any estimates that contradict what the plan says. He is not interested in disconfirmation of the project plan, only in confirmation of it. And when push comes to shove, when a milestone is fast approaching and the team is not on course to meet it, what then?

Exploring The Software Development Field

Quite possibly he will get his team to drop everything else they are doing and focus exclusively on the milestone in question -- but given the extent of what has to be dropped, this just stacks up problems for the future. He has preserved the appearance of being on course (for now), but sooner or later the divergence between plan and reality will become so pronounced that everyone will come to see the project timescales cannot be met.


The second approach, before it turns sour, has its attractions. The project manager may feel it to be more politically expedient. But the first approach seems to me to be the better way to go, if the project manager can bring himself to hold to it even in the face of pressure. It is a more honest approach, and more respectful of reality.