What am I going to get and when am I going to get it? That’s what every business stakeholder of a software project wants to know. Once they know those answers, the project cost is a simple calculation.
You have three choices for answering the questions:
- Conduct a detailed and thorough analysis to arrive at defendable conclusions;
- Conduct a less than thorough analysis and add plenty of padding to cover yourself;
- Tell the stakeholders what they want to hear and hope for the best.
It’s unlikely that you’ll have enough time for #1. It requires a substantial commitment by the stakeholders and they have a business to run. Estimating project size and building software is your job. (Note: #1 also requires that a crystal ball be available to anticipate future needs. Let me know how that goes!)
#2 may actually work if you have enough experience to know what you don’t know. The problem inherent in #2 is that it just doesn’t feel right. You’re providing a firm commitment around a set of vague definitions. Are you feeling lucky?
It may seem like #3 is there just for fun. It’s not. Stakeholders often demand that software features be developed by a fixed deadline. They are usually quite adamant and not open to negotiation. Just do whatever it takes … or else!
Stakeholders have been asking questions about features and time frames for years on project after project and have received acceptable answers (often after some give and take). However, they seem to forget that actual project results often differ substantially from what was committed. Deadlines are extended. Features are missing. Defects are rampant. Budgets are blown. Credibility is lost.
I’ve seen projects, estimated at 3 months, take 12 months. I’ve seen projects deliver on time yet be so full of defects as to be unusable. I’ve also seen projects deliver near on time and full featured though the end result was hardly optimal.
Time to reboot the relationship
Given such dismal results, why do stakeholders continue to ask the same old questions? Even worse, why do they continue to accept the answers they get?
It’s time to re-define the relationship between business stakeholders and software developers. Playing games built upon complex change control mechanisms (required for #1) is wasteful. Padding estimates (for #2) is unethical. Coercion (#3) is a dumb tactic.
Relationships succeed when they are built upon respect and trust. Those that aren’t fail and take down entire companies with them.
So the next time you’re asked to commit to a feature list and a time frame without enough information to do either, educate the requester as to what is needed to provide such estimates. Then suggest a collaborative, agile approach instead (e.g. Scrum, Kanban, Lean or XP), whereby software is delivered incrementally and stakeholders have ample opportunity to ask questions and offer feedback.
If that doesn’t work, consider finding another place to work. After all, who wants to work on a doomed software project?