Problems with project estimation

Dear Bob ...I observed several challenged IT projects over the years. The developers' estimates were low. The project managers scheduled based on the estimates. Needless to say, the projects were late. Are there reliable ways to estimate? Are there sound ways to track project status so you can tell your user community with confidence that their system will be ready by a certain date?You said in a recent newslett

Dear Bob ...

I observed several challenged IT projects over the years. The developers' estimates were low. The project managers scheduled based on the estimates. Needless to say, the projects were late. Are there reliable ways to estimate? Are there sound ways to track project status so you can tell your user community with confidence that their system will be ready by a certain date?

You said in a recent newsletter: the future lies with versatile developers who can create working software without creating volumes of documentation artifacts. Without detailed documentation, how do you determine who agreed with what requirements? When you are testing the software, how do you determine if a problem is a defect or a change? I guess if people involved have a great deal of mutual trust, then it may work.

--Managing

Dear Managing ...

Project estimation is one of those black arts I try to avoid. In addition to the karmic burden created by having to perform the required rituals, having to sacrifice the occasional chicken makes a terrible mess in my office.

My "solution" is to avoid estimating. When pressed I'm willing to give a "smells like" guesstimate for large efforts. The only estimates I'll provide are for next-phase projects I have the time and staff to properly plan. Then it isn't an estimate anymore - it's the computed cost of executing a project plan.

Sound ways to track project status? Of course: Weekly status meetings, where all participants report the status of their assignments (assignments are no longer than a week and status is either done or not done). Couple this practice with a discipline of keeping projects short and teams small and you can start to finish projects reliably.

Your question about documentation is harder to answer, because nothing works in all situations. Sometimes, especially in CYA sorts of environments or situations where different stakeholders have conflicting needs, you can need more. Nonetheless ...

Projects of any size and scope should always be about helping one or more parts of the business operate differently, not about delivering software that meets specifications. That being the case, the whole process of collecting software requirements from various stakeholders and reconciling it is bogus. Start the conversation by asking how the business should operate and everything about what follows changes. In particular, software requirements stop being a matter of finding compromises among various statements of "I want" and start being a simple account of the role software plays in new or changed business processes.

Testing also becomes something different in this sort of situation: It moves to a "Conference Room Pilot" where business users execute the new or changed process under controlled conditions. It doesn't much matter then whether a defect is the result of incorrect design, faulty programming, or end-users failing to anticipate their needs properly. All that matters is that the business can't run its process as it wants, which means the software must be tweaked to permit it.

And yes, all of this does require trust. Without it, a business has much bigger fish to fry than fixing software defects.

- Bob