If we don’t know why we are doing a project, then maybe we shouldn’t be doing it. But on many projects, if you ask the team “what will be different when we finish?” they look confused and start talking about the tasks they are performing.

But the tasks being performed should be moving toward some goal, which should be based on making something different to the way it is now (or would be without the project). Otherwise, to quote my grandmother:

How do you know you are not mistaking activity for progress? 

In a recent post I decided to categorise projects according to two dimensions (tactical versus strategic and Operational Excellence versus Innovation).  This gave me four kinds of projects to look at:

1. Parity projects are large projects that are designed to help the organisation play the same game better. The project might need to be done to stay in the industry, meet compliance requirements or maintain competitiveness. Example might include replacing a legacy computer system or re-engineering existing processes.
2. Continuous improvement projects reduce costs, simplify the business or lead to process improvements but are quicker to do than Parity projects and have a tactical impact.
3. Differentiation projects change the rules of the game.  This might include launching a new product, creating a new service or altering the way the organisation competes.
4. Opportunity projects are aimed at a short term gain that is visible to the outside world (increased revenue, better brand recognition) but do not aim to re-engineer the organisation or the product line.

So the world now has a new matrix. But how can I use it to make better decisions about projects? And would it actually be useful in identifying the value we are creating (or accidentally destroying)?

Are we consolidating or innovating?

If we are consolidating then it makes sense to assume that people in the organisation have the background to understand the value that we can create (or destroy?) on our project. Which means that at the end of the project we should therefore be able to show that life is easier, our systems or that we have met our compliance obligations.

It also makes sense that we should be able to predict much of the impact of the project through up front analysis and through talking to the right people internally.

If we are innovating then it is likely that we will be in charted territory, at least to some extent. So it makes sense that we might need outside support or we might need to do some research up front.

We might also need to experiment a bit, make some mistakes and learn as we go. Which in turn means that we will want to test our hypotheses as we progress. This suggests to me that we might use a more agile approach to the project.

If we are innovating then it also makes sense that the world should be different when we are finished. So we should be able to predict how the world will be different. We might be uncertain about the full impact of what we are doing, but the more uncertain we are, the higher the risk that the project will result in consequences we don’t really want. Thus the clearer we are on our initial hypothesis, the more effective we will be at testing whether the outcome is unfolding the way we hoped, or whether there are new threats and opportunities emerging.

Is this strategic or tactical?

Many tactical projects have been tied down by unwanted scope increases where someone in the organisation said “if we are doing x, why don’t we do y at the same time?” or “If we are touching the customer service interface, we should see if anyone wants to order coffee while we are there?”. As a result many sales opportunities are missed while we attach more and more peripheral ideas to our original one.

On the other hand, many strategic projects have been unsuccessful because the organisation stops paying attention to them even as the project begins. IT development teams attempting to do a system upgrade are distracted by multiple small requests or a new brand campaign is diluted by a series of local sales initiatives that all made money but distracted customers and internal teams from the new intended direction.

So it makes sense that a tactical solution should be kept short and sharp and be delegated to the local team who can implement it. But there is a risk that it will be undermining a strategic initiative so we need to ensure that this is taken into account.

It also makes sense that we need real focus and stamina for a strategic project to succeed. So we need widespread communication and executive support. But there is a risk that we will hold back smaller initiatives that would have added value, or get tangled in political issues as some managers worry about the shift in power that the project represents.

So what?

While some questions apply equally to all projects (why are we doing this? Who is paying for it?) the questions we might want to ask different questions for different types of projects. But rather than just telling the business analyst to “ask different questions as needed” I think it might be useful to come up with a rough starting point for different types of projects. And I think the four categories shown here might help to give business analysts and project managers a better starting point.

So my next post will be about the types of questions we could use as a starting point for each type of project.

But in the meantime, even asking whether we are innovating or consolidating and whether we see this as strategic or tactical might help start the conversation.