According to Innotas Project and Portfolio Management Survey conducted in 2016, around 55 percent of software development projects launched in the first quarter of 2015 failed. In most cases, the blame lies not with the developers’ poor technical skills but with improper management of software development projects. This is often caused by bad project management and project supervision, as well as insufficient involvement of the customer in the project flow.

The reality is that the customer’s role in a software development project is not limited to describing requirements and waiting for the product to be delivered. To mitigate risks of project failure, both the customer’s and the vendor’s representatives should take part in project management. On the vendor side, it is a project manager (PM), who prepares and executes project-related plans, monitors the project team work, addresses the issues of cost, budget, time, resources, quality and customer satisfaction, and acts as the customer’s reliable point of contact. On the customer side, it is a project sponsor (PS), who is responsible for the project’s success, ensuring that it delivers the agreed business value. To do this, the project sponsor should regularly supervise the work of the project manager.

Project health checks
A project sponsor follows the status of the project: what is going well and what needs to be improved. Supervising the project flow on a regular basis, he or she assesses the maturity of project organization and processes, management culture, and the commitment of the project team to deliver the product in accordance with the customer’s needs, on time and budget. These monitoring activities are commonly known as project health checks.

Project health checks may be conducted at agreed intervals as a planned project review process or as a response to emergency issues. In most businesses, the cost of correcting an issue is many times the cost of preventing it. This way, conducting regular health checks a PS can predict project failure and take urgent measures to avert it.

Key health markers
The most frequent manifestations of software development projects failure are late deliveries, cost overruns and poor product quality. That is why the PS should include the following health markers on the agenda.

  1. Timing

This health marker indicates how well a PM can organize the project team work to meet deadlines. The two main reasons why a project can go over time limits are unforeseen problems and scope creep.

Unforeseen problems are especially damaging in the case of the waterfall software development model. As the development process here follows the specification written at the project onset, the necessary changes can be brought to light only at the end of the development process. Project modifications are time-consuming, which leads to late project delivery. That is why the PS should make sure that the PM allocates enough time for project redoing caused by unforeseen problems emergence. Otherwise, Agile software development model should be chosen. This model allows making changes at any project stage.

The second big problem that affects project timing is scope creep. This usually happens when the customer adds too many requirements on the go. As vendors often apply the T&M (Time and Materials) pricing model where they are paid for the time spent on the project, they may be interested in the longer project flow. An unreliable software development company or suspicious freelancers won’t miss an opportunity to take advantage of the situation. Without enough control, the customer risks seeing the terms of their project inflated. In the case of Agile, this can be prevented by clearly stating the amount of work to be done during each iteration. This way, it is easier to control the project team’s adherence to the plan and their progress in developing the product.

2. Reasonable efforts

Effort per feature is the main project cost driver. With a T&M contract, overestimated efforts lead to attracting more members into the project team, which increases development costs. The opposite problem is resource overuse when the specialists are assigned too many tasks. Both issues may slow down the project’s flow.

The PS should find out how the PM created the estimates. This way, the PS can check if the resources are allocated and deallocated on reasonable and objective grounds. If the PM overestimates or overuses the resources to implement the required features in more than 30% of cases, it’s an indicator that he or she cannot or don’t want to manage this aspect.

3. Managing quality

A PS should also inquire about the existence of a quality assurance plan. How is quality assurance organized? Does the plan allocate time for bug fixing? How much and at which stage? These are just some of the questions to the PM.

It’s crucial to make sure that the quality assurance is not neglected for the sake of lower project costs. A lack of attention to QA will probably result in developing a product that does not meet the specified requirements. Insufficient testing results in late project delivery due to the time spent on bug fixing. However, excessive testing may also extend the project.

So, where’s the fine line? A good test coverage focuses on ensuring acceptable product quality rather than on trying to make it completely bug free, which is hardly possible.

Additional health markers
There are some additional health markers a project sponsor can use to assess how the management of software development project goes.

1. Managing resources

The PM should be able to assess and allocate the right resources necessary to complete the tasks on time and budget. As people are usually the most important of all the resources required to develop software, allocation of incompetent specialists to the project may seriously hamper its flow, causing late project delivery and low quality of the final product.

Let’s analyze an example of a project failure applying the 5 why technique. This technique is used to explore the cause-and-effect relations between issues by repeating the question ‘Why.’ Each answer forms the base for the next question. Often this scheme leads to discovering improperly organized processes as the root cause of the project failure.

Suppose, you are disappointed with the results of a health app project carried out by a software development company. So, you start asking yourself questions and finding the answers to them:

  1. Why am I dissatisfied with the project’s outcome? The reason is late product delivery.
  2. Why did the project stall? The delay was caused by too much of project redoing.
  3. Why did developers spend so much time on project redoing? They had to fix too many critical and major bugs found during the final acceptance testing.
  4. Why didn’t testing engineers find most of the severe bugs earlier? They didn’t have enough time for it.
  5. Why didn’t the testing engineers have enough time for it? As the testing team lacked domain knowledge, they spent 1/3 of the time to understand the business logic and study the regulations.

So, the root cause of the project failure is improper resource management. If the PM had attracted specialists with sufficient domain knowledge, they would probably have found all the major and critical bugs on time.

2. Managing risks

The PM should identify the risks and their triggers, classify and prioritize them. After that, he or she should create a plan to mitigate each risk. Monitor risk triggers during the project flow, the PM should take preventive measures in case such a trigger occurs. Besides, he or she should inform the PS about the project risk status throughout the whole software development process.

Wrapping it up

To be successful, a software development project should be managed both on the vendor and on the customer side. While it is clear with the responsibilities of the project manager who controls the project team’s effort, the role of the project sponsor is often underestimated. By taking time to supervise the PM’s actions, the PS can help the customer timely notice that the project goes wrong and prevent its failure. This can be done by examining project health with a focus on the five health markers we suggested.

The PM’s ability to make the project team meet project deadlines, allocate reasonable efforts, and cater for quality assurance should be systematically controlled. Besides, the PS should address the PM’s ability to attract the right resources and ensure proper risk prediction and elimination measures.