Measuring the performance of software development projects
The performance of an organization depends on how well its managers and executives know their goals, which can best be used to measure their business’ performance and results against them.
When it comes to optimizing business value in software development and delivery projects, the same performance management practices we regularly use can and need to be applied. This is crucial in today’s world, where software is used by many successful organizations to gain competitive advantages and drive innovation.
According to the Standish Group’s “CHAOS Chronicles”, only 34% of software projects are deemed successful, costing over $300B annually; 49% of budgets suffer overruns and 62% fail to meet their schedules. Considering today’s economic difficulties, results have to be delivered not only under deadline-induced pressure, but also developing innovative products and applications must be done within a strict budget.
So what is there left to do? At first sight, reorienting teams to focus on ROI, risk management, reducing costs and reaching the business’ goals might seem like the best solution, but many industry studies have shown that aligning projects to achieve quantified ROI and mitigation risk is not a well-established discipline, with two thirds of managers making decisions based on their “gut feel” rather than verifiable information. That in most cases results in a poor decision-making process, which as well results in a large percent of lost revenue.
Things such as productivity and ROI may seem impossible to measure considering the level of complexity involved in software development projects, since in order to measure productivity, one needs to monitor all the inputs which go into the business process of software delivery and at the same time, determine a way to measure the outputs of the process.
Simply collecting measurement for its own sake will not result in value for an organization, but adapting the performance management process to fit within the established team and tool constraints will.
The main challenges in measuring and managing software projects usually spring up when separate teams focus on numerous tasks, such as the development, build, testing and deployment steps, each having its separate bulk of processes. Moreover, it gets even more complicated when we talk about large organization, because we need to take into consideration the geographical/regional distribution of team members, crossing organizational boundaries, and also the multiple, heterogeneous team infrastructures.
A very careful approach is needed when deciding how to measure a developer’s performance, given the fact that traditional methods like lines of code, number of check-ins and so forth are proven to be subjective with today’s software engineering concepts. Rather than measuring individual KPIs in a project, we need to have a team-oriented performance approach. However, when working in a commercial development environment it’s important to keep track of and a close look at a few factors for individual developers:
- Willingness to take over complex tasks and the amount of effort involved in delivering them – different people work on different parts of the code and on different levels of the problem, making absolute measurements misleading at best.
- Test coverage and completeness – the amount of work that will be covered by an individual needs to be decided upfront, and when a developer often fails to meet it, it has to be taken care of.
- Code review comments – on each project, there is a specific number of code reviews that need to be conducted for a given time period. This helps assess the coding standard improvement for each developer, based on the code reviews feedback, as well as detect recurring issues and bring them to light.
- Technical mastery – assessing the mastery level of each developer individually is crucial when it comes to delegating tasks among your team.
However, keep in mind that when reviewing a developer, it is very important to not only assess the quality of their work, but also define “good work” in the context of your organizational needs and that of the specific projects and positions he will take over in the organization.
Remember, at the end of the day, every project is unique and even though the measurements of the development team and the expected performance levels are decided based on the final release, there are different aspects and requirements that each team member should be aware of when it comes to expected performance.