I have a question for you. How do you define a successful software project? Here are some choices. If you don’t like any of them, please leave a comment with your definition.
A. The product is delivered on time but over budget.
B. The product is delivered on budget but late.
C. The product meets the original time and budget goals but is unstable and/or cumbersome.
D. The product meets the original time, budget and quality goals but is missing some desired features.
E. The product meets all of its original goals.
(Sorry. I had to cross out E. It’s fictitious and has never occurred. If you think it’s happened to your project, I’ll bet you’ve glossed over some details or broadened the definition of the original product goals. That’s okay by me. As long as your management team views the project as successful, you win!)
Goals? What Goals?
So why is it that software projects never meet their original goals? I’m sure you know that there are many reasons why — too many for me to enumerate in this brief posting. Yet, the most common reason is simple — the business and technology people are disconnected.
It starts when the business side doesn’t clearly define what they want except by establishing time and cost goals that appear to have been conjured from the deepest, darkest, reaches of reality. They create a crisis atmosphere without explaining why time is so important or why money is so limited. Lack of trust in the software development organization often results in such behavior.
The technology side then jumps to conclusions without taking the time to truly understand what the business needs. They make assumptions about what the software must do and how it must be implemented. They call meetings to discuss the project without recognizing that business people are usually incapable of visualizing a software solution or understanding technical constraints.
Reduce Risk, But Not Too Much
Enterprise software projects are fraught with risk. Many things have to go right for a project to be successful yet only one thing needs to go wrong for a project to fail. The odds are stacked against us.
You won’t find success by simply reducing risk. You can reduce risk to the point where the project plan becomes so conservative that success is almost guaranteed. If your company is in a secure position within a market that’s not competitive, the conservative approach makes sense. If the company is in a competitive market, the conservative approach will leave gaps for the competition to move in and take market share.
That’s why my answer to the original question is “D”. Time and money are always limited. Quality always needs to be the best we can reasonably achieve. Something has to give and the most reasonable choice is the feature set.
Here’s the Approach
Start by creating a long list of all the features and functions the business would like to have. Rank them by putting them into buckets such as “must have”, “want to have”, and “nice to have”. Now get to work. Implement as much as you can in the time allowed by following Scrum practices — short iterations, test as you go, frequent deployments, and a constant focus on being done.
Keep iterating until time or money runs out. If you’ve ranked features well and collaborated with the stakeholders and power users throughout, the project will be viewed as a major success.
photo credit: lshimokawa via photopin cc