Large Software Projects Are Hard
Large software projects are often delayed, exceed their budgets and in some cases fail altogether. They are hard to get right. If a project is on time, on budget, fully functional and to a satisfactory quality, it is considered successful. This type of success is rarely achieved. A constant stream of new techniques and methodologies presents hope of solve the old problems. And yet, software project problems don’t seem to go away. Most of these new techniques increase the mystique around software development that in turn, fuels an unregulated industry of “agile coaches”. Executives are often frustrated that, in spite of employing some of these new techniques, many of their IT projects still exceed the budget or fail. I will show that just four metrics are all that is needed to get on top of this problem.
Valid Agile Metrics
Can project predictability be improved? Can the long bug-fixing periods be avoided? Can there be a better way? Can this be achieved without diving into the technical details? YES!
I’ll show you that by using these four metrics you can improve the basis of project decisions, raise the transparency of project progress and reduce project failure rates. These metrics can be easily be understood by non-technical leaders too. I’ve spent 30 years in IT, looked at hundreds of software projects and learned much from other experts. I’ve concluded that most organisations could enjoy more success by using just four straightforward metrics.
Firstly, it is important to use valid metrics. There are many inappropriate metrics that are frequently promoted such as counting lines of code, story points, and t-shirt sizes, but these usually lead to poor management decisions because the metrics on which the decisions are being based, are unreliable. For success you will need to base decisions on valid, consistent, universal, ungameable metrics; and four is all you need.
With just these four metrics you can get a grip on scope, resources, schedule and quality. Using them them will also help to reduce some common software project risks. You’ll soon get a reputation for delivering successful software projects.
These four metrics will go a long way to helping IT managers ensure that their projects are delivered successfully , regardless of techniques they adopt (agile, scaled agile, kanban, waterfall) . For any type of software (business application, enhancements, maintenance, system software, embedded systems) focussing on just these four metrics really works:
1. Scope
Size is not everything that matters on software, but it is the most significant factor on software projects. How big is your project really? You need a consistent measure before you start (for estimation), during the project (for control) and afterwards (for benchmarking). Measuring size is possible. It can be done using the universally applicable, valid, consistent, open, engineering (ISO) standard measurement for software size COSMIC function points. So the first metric is:
Metric #1: Functional Size in COSMIC Function Points (CFP)
2. Productivity
How quickly are we creating the software? Will we be done on time? If we know the size and monitor the output delivered per month (or per sprint) , we can predict if we are on track.
Metric #2: CFP delivered per month
3. Quality
If there are too many bugs, we can’t release the software, so we must keep track of quality throughout. How do we verify quality as we develop?
Metric #3: Defects (found and created) per CFP
4. Resources
What will it cost? How many technical staff will we need?
Metric #4: Cost per CFP
This is not all there is to managing software. There are many other important factors that influence these metrics such as: working conditions, tools, executive support, complexity, team trust, collaboration and staff competency. Nevertheless, by focusing on just these four metrics, technical and non-technical leaders in any organisation can increase their project success rate.
In most cases it is also useful to track some related measures, such as:
- Scope change during the project in CFP.
- Defect potentials per CFP and tests per CFP.
- Defects found per hour of unique testing
- Defects fixed vs defects found each month/sprint.
- Risk adjusted ROI
COSMIC Function Points – The Modern Software Engineering Standard for Measuring Software
At the core of this recommendation is size measurement in COSMIC function points. Check out our introduction to CFP. Counting CFPs is a skill that can be learned in a matter of days. The standard documentation is open, the manual is free to download and is available from https://www.cosmic-sizing.org. There is even a certification exam to ensure that you measure correctly. For those wanting to shortcut and accelerate the process, a CFP estimate can be generated automatically from requirements by using ScopeMaster.
If you’d like to know more about how to manage software projects more successfully and how to use these metrics effectively, please get in touch.
Summary
Here is a re-cap of those four key metrics for managing successful software projects:
- Scope: Functional Size in COSMIC Function Points (CFP)
- Productivity: CFP delivered per month
- Quality: Defects (found and created) per CFP
- Resources: Cost per CFP
Colin Hammond is a consultant in project assurance and creator of the world’s first analyser of software requirements for automated quality assurance and estimation. https:///www.scopemaster.com
Additional Useful Agile Metrics
Quality
- Code complexity (McCabe) measures
- Unit Test coverage
- Deployment frequency
- Defect fix rate
- Defects found and fixed at each stage
Scope
- CFP affected by performance non-functional requirements
- Scope change per month (% of total CFP )
Metrics for non-technical leaders
Most software metrics are unsuitable for non-technical leaders. The finance director cannot be expected to understand the terminology and nuances of scaled agile, risk based-testing coverage rates, code complexity levels, story points, t-shirt sizes etc. Yet the whole boardroom needs to be able to have a conversation about software investment that they can all understand. What is needed is a valid universal set of measures that reliably inform non-technical leaders. I will introduce just four valid metrics that can provide a common language for executives to use in the context of software investment decisions and that will help achieve greater project success.