Traditionally, software project success is measured primarily by two metrics:
- Did we complete the project on time?
- Did we complete the project within the budget?
The goal of Project A was to take a previously created prototype, which was built on top of a third-party software product, and turn it into a functioning system to allow the company to better manage its internal systems. The prototype was missing several key features, so the scope of the project was to add these features, then do a final run-through to make sure that nothing else was missing. We completed the project well ahead of schedule and roughly 25% under budget.
The goal of Project B was to create a website that could allow our client to consolidate several spreadsheets, Access databases, and paper documents into a single location for one of the company’s departments. We were to build the product so our client’s partners could log in and update the information themselves. We completed the project several months behind schedule and were almost 100% over budget.
Would it surprise you to know that I consider Project B to be the more successful project by a fairly wide margin? To see why, I’ll dig into what the respective businesses were actually trying to accomplish with these projects.
The high-level goal for project A was to implement a small project using the aforementioned third-party software as an evaluation to see whether it would be worth rolling out that software company-wide. The business need chosen was not a particularly good fit for this software, and the prototype was more built around the software than built with it. So as a demonstration of the software’s abilities, the project really was a failure even before I started writing code. To make matters worse, I had made a technical assumption that turned out to be incorrect, which led to some severe system performance problems. The company lost faith in the product, though our sales team persuaded them to move forward with the next phase anyway. They did, but kept tight control over the subsequent project, nearly derailing it in the process.
On the other hand, the long-term goal for project B was to consolidate several departments’ worth of spreadsheets and other disparate systems into a single software product for all of the departments to use. And while the initial phase of the software was significantly late and over-budget, it was generally understood that there was plenty of blame to go around, so we all took it as a learning experience and moved on. Because both our firm and the client improved our approaches, not only were we able to add two more departments to the product with relative ease, but we were able to do so significantly under budget, while continuing to make improvements for the first department. The overall product was a success because it met the most important business goals – increasing company capacity and increasing accuracy by reducing manual processes and disconnected systems. As a bonus, the company was able to glean insight they had no way of getting previously through the use of reports.
Then what are the metrics that software projects should use for success? They will vary project by project, but they should always be tied to desired business outcomes. For instance, a new eCommerce system should have revenue and profit goals, or a new workflow management system should have productivity goals. No, we shouldn’t ignore time and budget completely, since budget is a component of a profit goal, but budget is never looked at on its own. Yes, this means that many of these metrics will be influenced by multiple departments. In the case of the eCommerce site, meeting revenue goals would be partly the responsibility of the marketing department. But if your business is functioning well, that means that marketing and IT would have shared responsibility for the success of the software product, leading to increased collaboration and cooperation. Isn’t that a good thing?
