Success as a project
Treating your business goals as projects gives them a much better chance of being achieved. Dr Mike Ashby explains. I’ve been thinking a lot about the wrestling that goes on between […]
Treating your business goals as projects gives them a much better chance of being achieved. Dr Mike Ashby explains. I’ve been thinking a lot about the wrestling that goes on between “in” and “on”, or as I described it in the last column, your job vs the business.
Another way of distinguishing these is between BAU (Business – or Busyness – as Usual) on the one hand and special effort on the other.
Busyness As Usual gives us the expected results for the usual input and activity. It’s all the stuff that gets generated by being in business – interactions with clients, prospects, staff, suppliers, etc. It comes at us at least as fast (often faster) than our ability to process and despatch it. A lot of it appears to be urgent, because someone else’s ability to remain in busy-ness depends on your response. Much of our Busyness As Usual is self-perpetuating.
And it’s not as if the line between the important and the rest is clear and unambiguous. We’re big fans of having just three MIGs (Most Important Goals). In our own business tightly focusing on our MIGs has enabled us to make that important/unimportant call more quickly and confidently. But even then, we have RIGs and QIGs (Relatively Important Goals and Quite Important Goals). We have to make the commitment to focus on the MIGs ahead of the RIGs and QIGs, otherwise the MIGs won’t happen.
This is where the rubber really hits the road: we don’t tend to waste a lot of time. We spend our time and effort on things that matter. The hard part is that we have to deliberately choose some things that matter more than other things, even though that choice has costs, especially in the short term. But here’s the thing: the long term pain of doing less important stuff ahead of the Most Important Goals is much higher – pain now or pain later.
Project thinking
There’s a way of thinking about goals that increase the likelihood of achieving them. When you look back on your accomplishments and achievements, you’re likely to find that they have some things in common:
- Deadline.
- Clear outcome.
- A plan of attack.
- Resources – committed time and effort.
All those things are characteristics of projects. Treating our goals as projects gives them a much better chance of being achieved than if we leave them as BAU, or have goals that are open-ended, not clear, or not organised.
For example, we might have a goal of achieving budget sales. There’s a certain amount of business that comes in anyway, a certain amount that’s likely to be on the table and a certain amount that drops into our laps. Taken together, we can create an expectable number.
But let’s say we wanted more than budget, let’s say we wanted a more than expectable number. If we put “exceed budget” as a goal, we might get above budget. If we do the work to identify that our biggest growth opportunity is in that product or this segment or that market, then we would specify a target in absolute dollar terms (not percentages) for that opportunity. We would put a timeframe on it and work out what the required key tasks are, with a special focus on the new.
The real difference between BAU and projects is that BAU is the repetition of standard tasks and processes, whereas projects are made up of new tasks and steps. BAU is maintenance, project is construction. Projects are over and above, BAU is below the line. Projects are change, BAU is stability.
I had a boss who disliked my tendency to turn things into projects. He felt that because I was in an operational management role, I should be looking at processes and people in deep detail and making sure it was all just ticking over. He was right that I was the wrong guy for BAU. I was not cut out to be an operational manager. But he was wrong about the projects: the reality was that while the business was run on standard tasks, we had to make so many changes that the only way to get them in was to run them as projects. It was only when the projects were complete that we could shift to BAU.