A Project Needs a Compass

15th November 2020

Imagine the scene. A project has been running for a few months, and a discussion is being held over the priority of a particular feature. There’s vast disagreement amongst the stakeholder community, with some stating that it’s absolutely crucial, and others actively opposing the feature being developed at all. There’s a question over whether the new feature is even in scope at all, and the solution architect explains that it’s going to be very expensive and difficult to accommodate. There are discussions and battles over budget, scope, priority and by the time the meeting ends there is less certainty than when it began.  People are confused, frustrated and potentially even fed up too (particularly those who feel so strongly about the issue).

I’m sure we’ve all experienced situations like this. Whether the project is being delivered using an agile, hybrid or waterfall approach, discussions and wrangling over scope and prioritisation are not unusual. On complex projects, a product owner is likely to need to take the views of a range of stakeholders into consideration when making a decision, and decisions can be delayed when disagreement is rife.

So what causes disagreements like this? There are many potential reasons, but one is a lack of shared understanding of the purpose and boundaries of the initiative. This is often a sign of a lack of pre-project problem analysis; when organisations ‘jump straight in’ to a piece of work without carrying out a short but valuable piece of work to articulate exactly what they are trying to achieve.

Paradoxically, this can happen even if there’s a shared understanding of the goal. Imagine there was a high-level outcome statement that read something like this:

“Our goal is to build a method of transport to cross the Atlantic safely”

Clearly this in itself is not well-written (we’d want to interrogate it to understand why this aim was important), but it’s probably more than many teams have to work from. Imagine a team went straight from this statement into defining ‘features’ or stories. Different stakeholders would have very different views on what type of ‘transport’ is seen as desirable. You might find you are on track to build a product that has wings, a set of sails, jet engines, an outboard motor and tunnel-drilling equipment.  Here we have a reasonably clear view on why we’re defining and designing something, but no clear view on what we’re building. This will manifest itself as incoherence in a product backlog.

Of course, in our worlds it’s unlikely to be quite as severe as this example, but it can lead to the death of a viable product through a thousand unnecessary distractions.  What could have once been a beautiful, easy to use product, ends up being a bloated confusing nightmare because there was a lack of focus.  You’ve probably used products and services that felt bloated and frustrating yourself in the past…

Bring on the Compass

In situations like this, it’s useful to have a ‘project compass’ to keep us on track.  In order for a compass to be useful, we need to have defined (at least at an initial, concise, level) where we want to get to. This quick but crucial pre-project problem analysis is important irrespective of the project methodology we end up using. It boils down to answering a range of questions, including the why, what and how of the initiative. There are a whole range of techniques that we might use, including those shown below:


Possible techniques include


●      Problem Statement/Opportunity Statement

●      Balanced Scorecard

●      Critical Success Factors & Key Performance Indicators



●      High level scope diagram (e.g. context model, business use case diagram)



●      List of possible solution options (refined to a final option once agreed)


Of course these aren’t the only techniques, nor are they the only questions that we’d ask pre-project.  However, imagine if you had just a problem statement, a set of critical success factors and a high level scoping diagram. This would likely fit on a single page, you could carry it around to meetings. When somebody uttered those four inspired but sometimes disruptive words “I’ve had an idea” it’s easy to see whether that idea fits with this initiative. If it doesn’t, that might mean it can be added to another initiative elsewhere. Or it might mean that the external world has changed and therefore our initiative needs to change direction.  That isn’t unusual, but changes of direction are best done consciously, and even though we add or change scope it might well involve removing other elements of scope too.

In summary: a short, focussed effort spent pre-project defining ‘just enough’ of the why, what and how will pay dividends in the long run.  It saves wrangling and debate later in the initiative, and helps ensure that people are on the same page from the very beginning.


by Adrian Reed, Business Analysis Expert