The following material is excerpted from what I’ll be presenting Wednesday at the ALM Forum in (wet) Seattle. It contains the foundational ideas for software’s contribution to organizational value
Only the outcomes that unambiguously measure value have been selected as direct evidence for Evidence-Based Management of Software Organizations (EBM). Many other contenders were discarded either because they were intermediate measures or because their interpretation was contextual.
Someone looking to invest in a company looks for unambiguous evidence of its value. Revenues are often suggested, but the credibility of revenues is affected by the expense of acquiring them. Profit might have been selected, but profit may be affected by such financial decisions as deferred expenditures or recent acquisition or sale of assets.
The direct evidence identified below has met the test of standing on its own and being unambiguous.
Evidence of value from outcomes
Value consists of both current value and the ability to sustain or increase that value. Although many elements in an organization contribute to value, we are only assessing the change in value caused by software initiatives.
Three value aggregates were selected. Organizations without strength in all three may have short-term value, but are not able to sustain it.
Current value is the organization’s current value in the marketplace. The three pillars of value are:
- ability of employees to generate revenues
- likelihood of the employees to continue creating value
- likelihood of the customer to continue generating revenues
There are other measurements that could have been used. However, most either was later reflected in these measures, or they were circumstantial, explained in a number of indirect ways.
Time to market consists of direct evidence of the software organization’s ability to bring new features, functions, and products to the customers. Productivity was excluded, as speed is only one component of time to market; lean, focused functionality comes to market quicker than overburdened functionality developed with higher productivity.
Ability to innovate
Much of the software in the marketplace is encumbered. Despite being able to get it to the market rapidly, the customers may not want to implement it. They may have found that it was too hard to implement the last release, that much of the functionality was irrelevant to their needs, and that the overall product was flawed with unneeded functionality as well as hard to use because of defects. As this occurs to software, more and more of the software organization’s budget is consumed maintaining the product, further reducing the funds available to innovate.
The value metrics are displayed in a radar graph that helps visualize the relative strengths and weaknesses of organizational value. For instance, we might spot that even though revenues per employee are going up, the organizations ability to deliver new products is declining.
When the metrics are gathered every three months, changes can be noticed. Potential causes include:
- Competition in the marketplace,
- Internal change, such as improvements in customer support;
- Release of a service pack that improves the functionality and quality of an existing release; and,
- Internal initiatives such as co-locating developers and putting them into teams.
These metrics change even when the cause is unknown, as is the way of the market. As these changes are recorded, management can discuss impact, consequences, and prepare potential responses as more becomes known.
The Agility Index is part of the dashboard; The Agility Index is a calculation that combines the current value and the ability to sustain it. Using a number from 1-100, it reflects the health of the organization’s value and its real value in a competitive, fluid marketplace. The calculation is sophisticated, relatively weighing each metric and allocating at least four times more weight to current value metrics.
The Agility Index of one organization can be compared to similar sized organizations in the same standard industry code.
EBM has introduced rational, evidence-based decision making into the organizations that have used it so far. Focusing on outcomes of value, it elevates our conversations from preferences and opinions to contribution.
Now the work begins.
Evidence-Based Management provides a quantifiable basis for managing software development organizations. Initiatives to improve the value of software to the organization can be correlated to the outcomes they generate.
Pingback: Evidence of Software’s Value to an Organization | M Anthony Librizzi
Pingback: Evidence of Software’s Value to an Organization - The Agile Product Report
The Time to Market paragraph is very complex to me.
Which one criteria; speed or productivity is excluded from Time to Market?
Does it measure focused functionality as in, sprints, for Time to Market?
One thing I do grasp from that paragraph; Success in delivering a difficult feature is increased by decompose feature into meaningful small chunks than is to prescribe increased head count.
I suggest we measure outputs, not circumstances that cause them. Time to market, such as time time it takes to get a standard release to market, or to get a critical piece of functionality delivered to a customer, is an output. Productivity, quality, cyclomatic complexity, code coverage, etc. are all factors that interact and are managed to optimize the output.
These outputs are primarily for one organization, not to compare between different organizations. If an organization is decomposing critical features to look good to itself, it has deeper problems than value.
Pingback: Studying for the PSM II exam – Thoughts on Software Management and Development