When you stop for a moment to think about how many projects or other one-off work tasks you are connected to in a typical year at work, it's probably a phenomenal volume of stuff.
I remember when I was working in large universities, I would be discover 5-10 such initiatives per week which were occurring elsewhere in the organisation that could affect how I was running my department. At the same time, I was also driving a balance of about 10 projects of my own that would affect the way other people work. Altogether that's something like 200-600 projects I was supposed to care about!
Now think about the proportion of projects or one-off tasks which are ultimately ignored, or abandoned, or suffer delays so long that you lost interest in them.
What percentage do you think went off-track and/or failed? I have never measured this but I estimate that, of all the ones I was aware of, it must have been at least 30%. And for projects I had championed, I think the end product was something significantly different to what I initially imagined (and communicated to my stakeholders) about 30% of the time as well.
Another way of looking at this is that it seems to be really, really difficult to keep projects on-track — especially when the project is not your main job, when you are in a large organisation, and when you don't have much power.
Because my staff were almost always in this position, and because I really wanted them to be able to succeed, I created the following I created the following metaphor and mnemonic device called 'the R.O.P.E.' to give them a better chance of keeping their project on-task
Scaling the R.O.P.E
Suspend your prior beliefs for a moment and imagine that you can only think of a project at one of four different levels of detail. I like to picture these levels as different heights on a piece of climbing rope — you know the ones at gyms which have knots on them so you can easily move up and down to the different levels? You might have seen them before, they look something like this:
Image source: Dorno
If a project feels like it is getting stuck or going nowhere, there's a good chance you and the rest of the project team are thinking and talking about the project at the wrong level of rope/detail. You should try moving move up or down a level to see if it makes a difference.
So what are the four levels? These are:
|
Let's look at each of these in a little more detail.
Reasons for doing the project:
Involves thinking and discussion about questions like:
Why are you even doing project? What was the point of it? Why bother? What impact is it going to have? Why was this project a priority? Why are you working on this instead of all the other things you could do?
Outcomes of the project:
Involves thinking and discussion about questions like:
How will you know when you've reached the end? How will you know if the end product is going to have the desired impact? What criteria determines if the end product is acceptable?
Plans to complete the project:
Involves thinking and discussion about questions like:
What are you actually going to do? In what sequence? Within what timeframe? Who will do the different tasks? And how will you communicate with each other and to stakeholders?
Execution
This level is not about the project, it means you are doing the project. it consists entirely of actions. This level involves physically carrying out the tasks that make up the plans in the level above.
So what? Thinking about a project should filter through different levels. That's not exactly a massive revelation, right? And doesn't every decent project plan set out the purpose and criteria for success right next to the plan? So why not just have the plan and then execute?
Because the R.O.P.E. is, fundamentally, a tool to help you self-correct when the traditional tools of project management aren't working for whatever reason. Those traditional tools generally don't contemplate that they are wrong, so you need another tool that helps you understand if the first tool is properly calibrated or not. That's exactly what the R.O.P.E. is for, it's something to revert to when a project feels stuck. You use it to diagnose what level of detail you are working at, and then go to a different level to see if it's more effective.
When a project is off-track, change the level.
Generally speaking, if the project feels busy-but-ineffective, you should go UP a level and if the project feels thoughtful-but-ineffective you should to go DOWN a level. Here are some examples of how consciously switching levels can unblock a project:
For example, if the project team members are engaged in flurry of activity where everyone is working hard and doing stuff, but it feels like you aren't making meaningful progress, you are at the execution level and may benefit from making better plans to redirect everyone's energy into more promising tasks. If that doesn't work, you may not be clear enough about the outcomes you are actually aiming for, and would benefit from spending some time clarifying these so you are confident the plans will lead to those outcomes. If clarifying the outcomes feels difficult, you may need to revisit the reasons for doing the project in the first place.
Alternatively, if the project team has enjoyed lots of high-level discussion about ideas and intentions, but it feels like you aren't making meaningful progress, you might be simply admiring the reasons for doing the project without actually doing it. If you haven't already, you should define the outcomes so that the talkfest can come to an end. This makes it much easier to develop plans which represent agreements about who is doing what during the execution. It's possible to move down these levels quite quickly when there is good conceptual agreement about reasons and outcomes.
Of course, it's very normal (and most common) to bounce back and forth between two levels. For instance, the reasons are usually given by the big bosses upstairs when the project is first initiated and the outcomes, once agreed upon, tend to be stable. Projects most often feel stuck when the attempts at execution are not living up to the plans. Getting the project unstuck rarely means just doubling down on execution. Instead, it often involves revising the plans to in some way that rescues the project. When doing this, the outcomes provide guidance about what revisions to the plans are going to be desirable and acceptable. And then once the plans are updated, everyone goes back to execution until either (i) the plans need to be revised again; or until the group thinks execution finished, at which point the end product needs to be checked against the outcomes to validate it has fulfilled the reasons for doing the project.
In summary, getting projects completed on-time and to the satisfaction of your bosses and stakeholders is not easy. But it is easy to remember what you could do to identify when a project is off-track and what you can do to put it back on-track when you have a helpful little mnemonic device like the R.O.P.E.
Cover photo by Pixaby.
Comments