The Business Objective Model (BOM) is one of the foundational models we use as part of the ArgonDigital requirements methodology. The BOM defines the rationale for doing a project. Every BOM has the following key component parts.
1. Problems – the business problems to be solved or addressed
2. Objectives – the targeted objectives or expected outcomes.
3. Product Concept – the software solution that is being built to help achieve the stated objectives.
4. Features – a high level listing of key features that the product will have
5. Success Metrics – specific quantifiable outcomes measured after the release of the product to determine whether the objectives were achieved or not.
In my experience, most teams do a very good job of identifying problems, defining objectives, coming up with a product concept and associated features. However, when it comes to defining success metrics there is a tendency to rely largely on project outcomes instead of making hardcore measures of financial outcomes enabled by the delivered software.
While measures of project and product success are valid outcomes to be tracked, relying solely on these as measures of ultimate success is problematic. The danger is that all the success measures from a project perspective can be achieved without actually solving the underlying business problem. It is counter intuitive to think that an IT team can deliver a product with every feature requested on time and within budget, that also has widespread adoption, can still be deemed a failure. But that is precisely what it is, if it does not solve the underlying business problem that was the impetus for the project in the first place.
A simple example will make this clear. Acme Widgets has consistently missed sales targets set by management. After studying the problem, a multi-disciplinary task force identified the sales application used by the sales team as the culprit and started an ambitious project to improve it. The team created a BOM for the project and came up with the following success metrics to be measured on completion of their efforts.
1. The new sales solution is adopted by the entire sales staff within 2 months of product release
2. The legacy sales application is retired completely within 3 months of product release
3. Time to create a quote is reduced from 10 minutes to 2 minutes
4. Time to create an order is reduced from 20 minutes to 5 minutes
5. Deliver the product within 6 months of product launch
6. Total project budget is USD 2 Million or less
After the product was released the team went back and made the success measurements they defined when they started the project. They hit every single metric and were thrilled. The entire team went on a weekend trip to Lake Tahoe and celebrated a hard earned victory.
One quarter later they were confronted by an angry management team that wanted to know why the company had not hit their sales target for the prior quarter. They had failed.
By focusing exclusively on the project and product success, metrics they had missed the point of the project totally – increase sales and hit sales targets. Success metrics do not just impact the outcome of the project and what is measured. It also impacts how the team thinks about the product and required features. For example, an intense focus on success metrics defined in terms of an increase in sales numbers may have led to the development of features that addressed the core problem – like suggestions based on past purchases, easy access to add-ons and accessories and other similar sales enhancement suggestions to sales people using the product. Instead they likely focused all their efforts on optimizing existing functionality to hit aggressive performance improvement targets specified in the success measures. The result was that transactions were processed a lot faster with no qualitative difference in “what” was being sold. Net, net – sales numbers did not move from prior trends.
This is why it is essential to define success metrics that actually measure the business outcomes expected of a project. There is definitely a place for product and project success measures. However, focusing on the latter at the expense of the financial objectives of the project can and will lead to unexpected failures.
