A few days ago, we had a discussion with one of my colleagues, Vera. We’ve discussed managing projects, and it started a few thoughts in me that I hope might be useful for you as well. Most of the time I focus on software development projects, but what I’m going to explain is quite general. So I hope this will be interesting for you even if you don’t feel you have anything to do with IT.

What is a project? I use a very simple definition I got from GTD. Everything that you can’t complete in a single step is a project. I’m not talking about anything complicated here: in this sense, even baking a few muffins is a project. It needs a bunch of smaller steps, doesn’t it? You need to look up that nice recipe from last time. You have to buy the materials. You need to put the batter together. You need to warm up the oven. And so on. So it’s a project. 😄

The more complex a project is, the less likely that you will be able to complete it alone. I would even say, in many cases, it doesn’t make sense to complete something alone even if you could. (For example, because it would be important for others to practice, so you would like to delegate tasks. Or because doing things alone would be too stressful or boring.) I don’t think it’s a surprise for you that in our work, we depend on many other people, tools, the work of others, and so on. Making sure that a project will be completed is very often about managing those dependencies.

A project as a network of uncertainties

I’ve started to write this post mostly because I wanted to talk about the uncertainties coming up during a project. When a project starts, there are a lot of invisible things. Uncertainties. Hidden assumptions. Difficulties that you don’t even know about. In some way, completing a project is about systematically discovering, handling, and resolving those uncertainties.

This is going to be familiar if you ever had to do any larger projects. Most of the time, when we start a project, we have to split the large, difficult, hard-to-handle project into more tangible tasks that we know how to deal with. (Look, renovating a bathroom is such a big job that I can’t even estimate how many subtasks it consists of. But looking for someone who will tile the floor, or finding a good-looking floor tile - I think I could deal with those.) Those smaller tasks, as they depend on each other, make a network, along with the uncertainties. Hence the title of this post.

The confidence level

Every single task has its own confidence level. This is essentially your answer to the question: how likely it is that you will be able to complete the task? If it’s about something trivial that you could finish with your eyes closed, it’s going to be quite high, let’s say, 90%. But if you have never done anything like that - maybe you don’t even know how to start -, this is going to be much lower, perhaps even close to zero. (I seriously hope it’s not going to be zero though, because that would mean that you can’t even imagine completing the task!) The following thought is going to be a bit abstract, but please bear with me for a moment. 😄 I think that as long as a task is not done, its confidence level can’t be 100%. Why? Because at any point, something unexpected can happen. Making a cup of tea is super simple, right? But if there’s a sudden loss of electricity in the flat, and you can’t use your electric kettle anymore, things are going to get more complicated… So if you consider this, 100% confidence can be reached only by actually completing the task.

When you’re working on a task, the confidence level is changing continuously in some direction. For example, you might run into an unexpected difficulty which might cause it to drop. In other cases, you realize that the task is simpler than expected, so it grows. Obviously, we prefer cases when the confidence level is growing continuously. 😎

Hidden assumptions

I’ve mentioned hidden assumptions above for a bit. Now, there’re a lot of methods with nice sounding names like prototyping, making a proof-of-concept, building minimum viable products, etc. which are essentially all about giving you a method to discover and confirm your assumptions without having to work too much unnecessarily. There’s a reason why people talk about them a lot: discovering the hidden assumptions in a project is critically important, and it can decide whether the project is going to be successful. In our daily lives, we carry tons of assumptions in our heads without ever thinking about them. And once those start to fail, we often interpret them as tragedies, and it can easily happen that we need to re-plan everything. (For example, a lot of us did assume that we can leave our homes at any moment to take a walk. Then suddenly COVID came, and we’ve all learned that this is not that obvious at all…)

Really, my work in Prezi with my teams is all about those assumptions.

• *We come up with a lot of assumptions about how we could improve the business.
• We come up with ways to try validating those.
• We try to implement the simplest solution which is enough for testing the concept.
• We measure whether our assumptions were right.
• Then, we try to figure out what we can learn from what we’ve seen.

Then the entire thing begins again.

When are we done? We need a testing plan

When we discuss uncertainties and assumptions, something very important comes up. How do we even know if we’re done with a task? What does it even mean that something is done? This can often be a massive source of confusion if you work in a team, not to mention the cases when you have to work with subcontractors. There’s a good practice that we use to avoid such issues: writing a definition with the team about when we accept something as a completed piece of work. Part of this definition is very obvious: is it even working? To answer this, you have to test, and to be able to test things, you need a testing plan. At a minimum, you have to know what are the steps to check if everything is working well, and you have to know who will check those. In its simplest form, this can be a dumb checklist. The point is to have it written down in a way that is simple and specific enough. In my team, it helps a lot that we try to formulate those testing plans as soon as we can. If you know what to check in advance, you can test your work as you’re working on it. This means you can avoid having to rework things from scratch, which is one of the most irritating things in the world, so having those test plans is going to be good for your sanity as well 😆

If you don’t have a testing plan, you can take it for granted that things will go sideways. Why? Because the lack of such a plan also means that you haven’t settled on a lot of things with the team - there are agreements missing, and the roles in the team are not defined that well either. This can lead to chaos at any point in time. (This thought above is a version of a more general principle of mine, which sounds like this: if you don’t know that things are going well, you must assume that they are not! We can call this the Principle of Not Fooling Yourself.)

By the way, if the uncertainty about a given task is so high that you can’t even put a testing plan together for it, that’s a quite strong signal that you don’t even know how big the given task is. When this happens, talking about estimates doesn’t make much sense, as you likely don’t know all the risks that you will need to manage during the project.

Obviously, I’m not suggesting that it’s always solely your task to check everything every single time. (If you would want to do this, you would fall into the trap of micromanagement, which would lead to hating each other with mostly everyone you work with. 😂 ) But as a project leader, it’s your task to find the right person for every task. And the right people will definitely need to check all those things that are required to make the project a success. If you can pay attention to all those uncertainties and assumptions I wrote about before, and you can handle them right, I’m sure you will have an easier time.