Managing software development - turning failure into success

In my job I'm lucky to deal with a wide and varied group of stakeholders from a multitude of backgrounds, which means there are a lot of interesting projects to work on.

Not many of my stakeholders come from software backgrounds, but when it comes to software development projects, they all have the following in common:

  1.   Scope: they want the software to do a lot. 

  2.   Budget: they want the software to be inexpensive. 

  3.   Timescales: they want the software quickly. 

These three also form the basic project management cornerstones of success: you need all three to balance. 


If you don't have the time or the budget or if the scope is too big for either, then failure threatens. 

So, how do you appease stakeholders who want their software quickly, within budget, with a big scope and they want you to be flexible on all three of these i.e. to react to their changing needs throughout the lifecycle of the project?

Simply put: you need to manage your stakeholders through these three cornerstones of scope, budget and timescales. Every time anything changes within a project (either on purpose or unexpectedly) one of the project cornerstones has to flex. This concept needs to be communicated to stakeholders so that they fully understand and anticipate the implications of any changes they request. If this isn't explained effectivelty, your stakeholders will perceive any delays or shortfalls as failure. However, if they do understand then they will see success in an ever-changing environment.

In the beginning, inform.

In any new project, the stakeholders are finding out what is possible. They have a scope in mind, but can it be done in time and can they afford it?

If you can agree on all three cornerstones, the project will be set. Now is the time to make sure that your stakeholders know that if anything changes (and we mean ANYTHING), it adds risk to one or more of these cornerstones.

Managing risk      

If your project has a fixed budget, fixed timescales, fixed scope or a combination of these factors then you need to manage risk so that any mitagations you need to make do not affect all of the elements. 

If you have a fixed budget, timescale AND scope, then risk management needs to communicated to stakeholders, so that they understand that the limited 'wiggle room' puts constraints on the project.

In any case, don't take on the risk; always have migitating actions ready. These should be agreed by the stakeholders from the outset of the project. 

Risk and Mitigation Action

A mitigation action is what to do when that risk is realised. A risk can be anything that affects a can't list out every eventuality, but you can group them:

  • A risk that affects scope, e.g. a request for additional functionality. 
    Mitigation action: stakeholder approval for additional budget and timescales. 
  • A risk that affects timescales, e.g. a change in resource availability.
    Mitigation action: stakeholder approval for additional timescales pf reduction in scope. 
  • A risk that affects budget, e.g. an underestimated task or cost. 
    Mitigation action: stakeholder approval for additional budget, timescales or reduction in scope. 

Each risk will need to be reviewed for the individual effects on the project, but there should always be a choice given to stakeholders. A simple example to give options, e.g. for additional elements to be added to a project could be:

  • Approve the change request and allow for additional time and budget


  • Don't approve the change request and keep the project on budget and on time. 

Don't hide from risk, it happens. If the project's stakeholders cannot accept that something has to give in the face of risk, then the project's potential for success has taken a hard hit. 

If stakeholders agree to a simple process of risk management, then everything is clear, they call the shots and they decide how to handle risk (even if they don't like the outcome, it's their choice). The Project might be cancelled, the project might go on to completion, but stakeholders have been given the options when risk has been realised, and so, the project management of risk has been a success either way. 

Enjoy what you're reading? Then you'll love our blog

Let's reimagine learning together

Start a conversation today