Here’s the problem. Most software projects that I have seen are managed as a subset of a larger project. Most software project managers are given, or they negotiate, a budget and their job is to squeeze as much out of that budget as they can … to deliver the best value.
Q: What are you managing, Mr Project Manager?
A: Product Scope, Quality, Schedule and Budget – project things.
The benefits / money-making side of the project is someone else’s responsiblity – i.e. the project sponsor’s or a marketing guy’s.
Q: What are you managing, Mr Project Sponsor?
A: Profit, Stategy, Tactics, etc. – business things.
Most IT people are happy with this arrangement. Sure the IT folks usually do lots to make the product better, but their training is in bits-and-bytes, not marketing or accounting. After all, what influence do the IT guys have over the profit? None.
WRONG … the IT guys have lots of influence over profit. Lots and lots of influence.
The IT guys influence, by their choice of development methodology, when the project first realises value / makes money:
- If the IT guys use a one-shot waterfall (or V-model for those who niavely think it’s different) that is supposed to be the cheapest way to build software (it’s not, it just looks like it should be). This choice forces the cash flow to be delayed until every single damned requirement is finished. The really important features wait for the not-so-important features , and the not-so-important features wait for the we-aren’t-sure-if-we-need-this-but-if-we-don’t-include-it-in-the-requirments-document-then-well-never-get-it features, then when they’re all finished, tested and reworked the software is shipped.
- If, on the otherhand, the IT guy’s use a methodology where they can deliver their big projects in small releases of the most important features, then (a) the product starts realsiing most of it’s value much sooner and (b) the customer can test the product with real live users and customers, then learn and adapt.
My last big waterfall project ran for 4 years. It took 4 years, with 50–100 people working on it during the last 2 years, to earn anything. Now imagine that my last project had delivered the first 20% of the features to the market within, say, 6 months. It would have probably pleased 50, 60, 80% of the customers – who knows? – and it would have started bringing in money within 6 months, not 4 years. Based on the feed-back from the customers they could then have figured out the next 20%.
The project was way over budget, late (repeatedly), of adequate quality, and was missing many wanted features, while it contained many unwanted ones. But who cares? Even after 4 years it was still very profitable. Everyone was thrilled! The 4–sided-iron-triangle is irrelevant.
But, what if it hadn’t been profitable? What if the product had failed in the market?
It was forecast in it’s business case to have revenue of £20M per year. This figure was 4 years old by the time we finished. It was calculated by forecasting (guessing) that the market was worth £400M each year and we’d win 5% of it. One guess multiplied by another guess
What if the guess was wrong? Wouldn’t it have been nicer to know this after 6–12, not 48, months?
But the solution isn’t necessarily to adopt “agile”. In fact, who cares about TDD, Refactoring, Scrum, etc. when simply running the project as several much shorter phases would achieve such a dramatic improvement?
No, the solution is for IT to change it’s mindset. Software development is always part of a bigger picture. Software development is all about making money for our customers. Agile approaches allow our customers to make more money by enabling the earlier release of working software that, in turn, makes the customers more money. This is a profound shift in thinking. This is the what our customers want to hear about. They don’t care about techniques (provided the techniques work). They care about the money.
Or, at least, they should do.
