What are we trying to achieve?

Setting the objective for a programme or project is something that some managers and organisations give too little analysis. The instinct is to say “make me widget X” or “make this new organisation structure happen”.  That simply defines the solution that seems obvious at the time. For some projects that is enough but for many that is like saying “go to Plymouth” without say why or what you need to be ready to do when you get there.

For a project team to be successful, it helps to know what the end state needs to be and why you need that end.

With business change projects, this is even more important. The endpoint for change often can be achieved by a choice of methods. Some of these methods will support certain types of next steps, others will make other actions easier. Stakeholders engaged and expecting one direction for a project will need more support if the organisation suddenly takes a turn in a different direction after the project completes. So it makes sense to let the project team know the overall direction being taken to give stakeholders that support earlier in the process.

Before a project is started, the “business problem” or need must be defined in context. Sometimes this can be very complex or really simple: “our product range is showing declining sales in the southern states and needs refreshing for that market with a product suite of type A that will last in the market for 18 months, to be introduced between august and october next year at price point 97.99 with expected competitors EFG, RST, XYZ”

As for going to Plymouth: what is the purpose of the journey,which Plymouth (south-west England, New England, Montserrat, or somewhere else), who should we meet, what messages do we take to the people we meet, who should go with us, what equipment do we need (you’ll have to dig to reach Plymouth in Montserrat), how long are we staying, is there a dress code for any time during our stay, any travel restrictions, any safely protocols, what are we bringing back and what format must it be in, when are we needed back at base? All of these things can change method and budget.

Most importantly, knowing the reasoning behind the objective means that if conditions change, the project can respond to change requests appropriately and not be sidetracked by them. If the budget must be reduced for business reasons part way through the project, knowing the messages you are trying to deliver can guide which parts of this project maybe cut, which are vital, or if the project cannot survive the cuts and must be cancelled.

For the organisation, knowing why a project exists can mean that when the organisation changes direction or market conditions change, it can see which projects it no longer needs and which new ones must be started urgently from those waiting in the portfolio. 

One organisation I worked with had a marketing window to launch a new product  but no-one explained that to the development team. It launched too late and never made a return on the investment. That is like going to Plymouth for a party but taking so long getting ready that you arrive as the hosts put the last of the trash out for collection.

Of course, simple things can change significantly projects too.  Imagine your project is to go to Plymouth, North Carolina USA to meet an expert in paper manufacture to understand their approach and bring back some innovations for your own business. She moves to Atlanta, Georgia USA and the paper company now has someone else leading the technical team at their Plymouth plan. Knowing the reason for the trip would mean that the team would be monitoring this and would be able to understand if they now needed to go to Atlanta instead or what changes need to be made for the new guy they expect to talk to. Understanding and stating the assumptions behind the objectives will mean these are monitored and change is handled with all the known choices identified.

Understanding the objective fully means one special thing: if the project changes it can still deliver.

Advertisement