Change and Risk Management in Software Engineering – Ballard Chalmers

Change and risk management in software engineering is vital. Knowing how to spot, understand and mitigate risks ensures a successful project outcome.

Risks are inherent in custom software engineering, as without risk, you are unlikely to be creating something worth customising. With an increasing amount of useful off-the-shelf products available, you will have turned to custom software in the pursuit of something excellent and bespoke. However, using technological advancements and the in-depth skills of expert engineers does open the door to risk.

Types of Risks in Software Engineering

Most risks in software engineering can be classified within these groups:

• Technology Risks – those inherited from the choice of the technology and its provider.
• Tools Risks – those inherited through the choice of tools and architecture.
• Requirement Risks – features, specifications, deliverables or expectations changing or being added mid-development.
• Organisational Risks – management errors, mis-estimations on time or budget, people errors, etc.

These can be looked at broadly in two ways: your initial choices and later changes.

Risks at the Start of a Software Engineering Project

The best risk management is always prevention and that’s why the beginning of development is so vital. Early decisions include whether you will be developing in-house, or not, finding the right partner (as needed) and choosing your technology platform.

Clear specifications based on a defined need, the choice of tools, budget, timeline and deliverables will all be the basis of the rest of your project – and whether or not you spend your project fighting fires or enjoying the development.

Don’t skimp on any of these stages. Ensure all stakeholders are on board, sufficient surveys have been carried out and you have the right partner on board, and you will be off to a good start.

Change During your Software Engineering Project

Other risks come about during a project and come from changes being inserted mid-development. Hence the term commonly being called change and risk management.

Despite all good intentions and plans at the beginning of the project, it is not unusual for new features to be asked for where additional needs have been isolated. This can come about from a PoC, testing or further user surveys.

Additionally, if stakeholders have not been clear, benchmarks, usability and expectations can change. This is particularly true of long projects that may span a year or more.

Whether developing in-house or with an outsourced technology partner, changes mean risking project timelines and budgets. Having in place pre-agreed change and risk management policies means there is a procedure in place for dealing with changes that come up, no unnecessary stress is added and stakeholders can remain in control of the budget and project deadlines.

Recommended Process for Change and Risk Management in Software Engineering

In software development projects, we recommend that the budget is managed on the basis that all times are estimates only and do not constitute a fixed-price quotation. The scoping effort would be provided based on the current understanding of the requirements, the existing environment and expected functional behaviour.

Change Management Process

Estimates should include a contingency time to allow for unforeseen additional work. This contingency may not be sufficient to cover all unexpected requirements. Alternately, the contingency time may not be required to complete the delivery, resulting in a lower cost for the project.

The use of a standard Change Control process to track and approve changes to the scope is vital. This includes unforeseen (by the development partner and/or client) requirements which will materially impact the time and cost estimates during the development process.

These can be either approved, to increase the scope of deliverable (and resultant cost), or not approved, and the scope of deliverable decreased accordingly to maintain the current estimated time and costs.

This is vital as the internal project manager and stakeholders maintain control over budget and are fully aware of what they will be receiving for it.

Change Management in Large Enterprise-level Development Projects

For larger enterprise development projects, it’s better to break it down even further:

1st Stage: Estimate the development at a fairly high level with the initial information available.

2nd Stage: Detailed scoping, POC and design, and more accurate time and cost estimates in partnership with the client. Done until all parties are comfortable to start the main development.

3rd Stage: Main application development.

Here a Ballard Chalmers we also provide a burndown rate metric in the project reporting, to share transparently the burndown rate and progress against target. This way any negative indications are caught early and dealt with effectively.

Why Fixed Price Projects are Non-Optimum for Change Management

While many partners do work on a fixed-price basis, we consider this to be non-optimum. It is not the best choice for either clients or vendors in enterprise software application development projects.

With a fixed price, the risk is passed fully to the vendor, who is then obliged to aim to cover all risks commercially and try to cover all eventualities. This leads to a higher cost project from the start. Additionally, it often causes a lot of friction on scope and budgets between the client and vendor.

Enterprise application development projects of large scale inevitably need to be undertaken on a pragmatic and partnership basis to ensure a successful outcome.

The recommendations given here for change management come directly from our extensive experience. It is the most effective in delivering the end result, on time, and in budget.

Has your Custom Software Development Project Gone Astray?

Our Project Recovery Service may be just what you are looking for – our team is expert at untangling and uncomplicating projects speedily, moving you in the right delivery direction again.

Whether you need a few days of consultancy to get things back on track or you are looking for a new technical partner to take over the development project, we are happy to be of service. Get in touch.

Looking for a Technology Partner with a Sound Change and Risk Management Policy?

All recommendations given here are the change and risk management policies we use for development projects at Ballard Chalmers. They are a tried-and-true method of mitigating risks. Additionally, it creates a smooth relationship between vendor and client, one that creates long-term successful and happy partnerships.

Get in touch or call us on 01342 410223 to discuss your requirements.