Lessons learned: Delivering software programs (part 1)

When defining goals it is easy to say something vague yet unarguably positive, for example, “Increase revenues on platform X”, “Diversify portfolio” or “move to cloud”. But this is unhelpful as it does not give enough information to inform decision making.

Articulating the why

Articulating the “why” is important to achieve your objectives; if this is unclear in your program then it is going to cause problems.

Often these generalisations occur to avoid difficult conversations at the start of a program when different stakeholders can have different concerns, which often results in more general “keep everyone happy” outcomes. Therefore it is better to iron out those differences early rather than after investing too much time, money and effort.

Once agreed, all the key stakeholders need to get behind those outcomes. If stakeholders, sponsors and participants are interpreting the goal differently it is like building a tunnel from either end but each end going in a slightly different direction, with obvious consequences.

Example: Moving to the cloud

Take as an example a paradigm often found in the industry; moving to the cloud. If the outcome is defined crudely as “move to the cloud” it will likely risk cost overruns and have teams doing more than is strictly necessary because there are so many different ways to move to the cloud.

This generic target doesn’t specify how the program will help the business achieve what it wants to because the goals aren’t clear. What needs to move? To what cloud? Why even do it at all? How does one expect to benefit from using the cloud?

There are a huge number of decisions that will need to be made before achieving the outcome of ‘moving to the cloud’. As it is, the goal gives no assistance in decision making when it should act as a guide to steer the choices made.

Better would be to articulate the benefits the business hopes to gain from the move, outlining the “why?” of the program.

In this cloud example, the why could be, for example, to “deliver cost savings through elasticity of usage”. This extra information explains the intended outcome and allows the team to optimise the way they do the job to achieve a successful result. In this case they can make localised decisions that optimise for cost savings, helping the business achieve its outcomes.

Getting that shared outcome clearly articulated is a key component of successful delivery. Try asking the question of “why?” independently of the participants in your program, if you get a large variation in responses then I recommend you do something to correct.