Things Don’t Stay Organized on Their Own, Part II

Back in February, I wrote about my personal time management system and the effort that I put into maintaining it. I promised to also write about my project management system, and the effort that goes into maintaining that. I’m going to make good on my promise… sort of.

I can’t write a post detailing my personal project management system, because that system is different on every project I manage. I do that on purpose. I think project management is most effective when it is tailored to the project team and the environment in which they work. I usually have a general project management system I use at any given company, but (1) that is always evolving as I better understand what works and what doesn’t at that company, and (2) I always tailor the details to the specific project’s goals and the specific project team.

There are some things I consider essential to a project management system:

• There must be some way to analyze and document what tasks need to be done and how they interrelate.
• There must be some way to know whether or not the team is on track.
• There must be some method by which communication flows, and that people recognize as “the official communication channel” (i.e., it can’t all be informal, because then people have a hard time knowing what is gossip that can be ignored and what is vetted information that must be acted upon).
• There must be some way to acknowledge risks, and decide how to handle them.

Each of those essential things can be implemented in a wide variety of ways, and there are a lot of generally non-essential things that are actually essential in certain environments or with certain teams. This is why I think the project management system always needs to be tailored.

Still, I promised a detailed post about how I manage projects, and I will deliver one! Rather than try to give very specific details, I will try to break down the steps I follow, regardless of the process details I use to follow them. Please just keep in mind that this is one snapshot of how I manage projects, and if you decide to take any of this system for your own use, you should expect to need to tailor it. Heck, if I took this system into a new environment, I’d expect to tailor it.

So… to the details.

Step 1: Define the scope

The first thing I do when I’m starting a project is define the scope. In some environments, this means I write a scope document (jargon for a bunch of words that describe that I think we’re going to do in this project). In other environments, it just means that I verbally restate what I think I’ve been asked to accomplish, and look to see the person assigning the work nod. Scope creep will happen, and sometimes that is even a good thing (for instance, if the tool you’re building will be useless unless you also streamline the process that provides the data for your tool). But I firmly believe that the team should always know when it is accepting new scope. For one thing, this is how you’ll know why the work seems to be taking longer than you thought it should!

Step 2: Identify the high level tasks

Your scope is your goal. The high level tasks are what you think you need to do to accomplish this goal. Sometimes, things are so poorly defined that your initial high level task list just consists of items like “figure out how to accomplish X” and “accomplish X.” That’s OK. You can leave “accomplish X” vague until you have more information, and expect to come back and replan things once you have that information.

Usually, I have enough information to be a bit more specific. For instance, I do a lot of book publishing these days, and when I start work on a new title, I know that I have these main tasks: editing, cover art, print production, ebook production, and promotion.

Identifying the high level tasks is a lot easier if you’ve done this general type of project before, but even the first time around, you can often get the high level tasks close to right if you stop and think about what needs to get done.

Step 3 (option a): Break the high level tasks down into actual tasks

This is where my process gets really different in different situations. If it is a project on which I’m doing all the work (yes, I plan those… I find it helpful, particularly if I’m juggling multiple projects), then I can break the high level tasks down into actual tasks. For instance, under the “cover art” section of a book publishing project plan, I have the tasks: contract with designer, review initial concepts, approve final art.

Sometimes, I do this in a tool like MS Project or Project Libre, and make a work breakdown structure. Sometimes, I do this in a tool like Trello, and organize the information into boards, cards, and lists in the cards. If I need to make a schedule, I like to use a work breakdown structure, because then I can add the dependencies among the tasks and time estimates to produce a schedule. More on that in a bit.

Step 3 (option b): Identify who “owns” each high level task

If I’m working on a bigger team in which the work is broken down such that different people (or sub teams!) own each high level task, then my next step is to identify who owns each high level task. I then work with those people to do step 3, option a. Or, if it is a software project running under an Agile process, we probably all do it together in a big meeting. But that sort of detail is beyond the scope I set for this blog post.

Step 4: Identify dependencies among tasks

What tasks can’t be done until some other task is done? Which need to be worked on in parallel? These are important questions, and if you don’t think about them up front, you increase your chances of hitting a point in the project at which someone is stuck waiting for someone else to finish. A little bit of downtime is not a bad thing—it can give people space to try out new ideas, for instance. However, if these sorts of blocks occur a lot, your project will take longer than people think it should, and your team is likely to get frustrated.

If I’m working in an Agile process, there usually isn’t a lot of dependency analysis upfront. It tends to happen in the medium term planning meetings (e.g., the “sprint transitions”). However, I still like to try to think about dependencies at the start of the project, and I think it is essential if I have a lot of things I need to get accomplished in a constrained amount of time. I wouldn’t want to spend all of my work life under such pressure, but it does happen from time to time. In this situation, I think it is essential to include dependencies among tasks in my planning, because I do not have time to absorb slack caused by one task waiting for another task to finish.

I have never found a better way to track dependencies than in a work breakdown structure. If you have a different method you favor, tell me about it. I’d love to have dependency tracking options to suggest to people who hate work breakdown structures.

Step 5: Think about risks

I rarely follow a formal risk analysis process unless I’m working in an environment that requires one. To be honest, I don’t find most formal risk analysis processes to be all that useful… except in that they make you stop and think about your risks. I can do that without a formal process!

I try to at least identify my main technical risks and any other risks I think are somewhat likely (e.g., I suspect that one of my key team members is thinking of quitting, I suspect that one of my other team members might get pulled off of my project to help another team that is behind schedule, things like that).

Then I think about what reasonable things I can do to mitigate the risks. For technical risks, it is often useful to try to address them early in the project, by starting some piece of work earlier than strictly necessary. For staffing risks, cross-training is a good mitigation.

Step 6: Make the plan

This is a very vague step, because how I make the plan really depends on the specifics of the project. If I’m trying to balance multiple projects with the same group of people, I’ll usually go ahead and fill out the details on a work breakdown structure. I’ll put the tasks and dependecies in (steps 3 and 4), and then add time estimates, think about the risks I identified and any mitigations I want to try to apply, and try out different solutions until I get an overall plan I think has some utility. It won’t be correct—no plan ever is. But it can be accurate enough to help me montior progress and see if we’re on track, and to help me work through the consequences to project B of a decision on project A.

If I’m less constrained by schedule, I might instead plan the project out on a Trello board (or something similar).

The main thing I want out of this step is something I can refer to when things change, to help me think through my options and how those options might play out. If I’ve done my planning well, when something happens and I’m forced to make a trade off, I’ll at least know what I’m trading off.  There’s also a better chance that I’ll see what all my options are and respond to change more intelligently. For instance, let’s say that key team member I was worried about in step 5 does quit. Without a plan, I might just assume that the only response is to delay the project. With a plan, I might notice that I could instead delay one aspect of the project and bring the rest in on time. Which is the right response? It depends. But it is always good to know what all of the options are.

Step 7: Communicate the plan

Everyone on the team deserves to know what the overall plan is, because people are not robots, and they should not be treated like cogs in a machine. Furthermore, sharing the plan makes it better. The rest of the people on the team will usually see the things I’ve missed and help me improve my plan.

As an added bonus: if everyone on my team knows the plan, they are better able to make decisions on their own, which means I spend less time in the details of work that I’m not doing, and also that the team members feel more independent and can plan their work around their life more effectively. Everyone is happier this way!

Step 8: Adjust the plan as needed

The plan is obsolete almost as soon as I make it. And that is OK. I’m not making the plan to say how things will go. I’m making the plan to capture what I know about how tasks interrelate, what people are available to do work at which times, and how things might go. When something changes, I turn to my plan to help me think through how to respond. If the change is big enough that it makes the plan useless for that purpose going forward, I redo the plan. This takes time and effort, but the pay off is that I make better decisions, and my projects run more smoothly.

That is the basic process I use for running projects. I didn’t talk about how to communicate, partly because this post is already long, and partly because that really depends on the culture in which I’m working. I have written about communication in the past, though. I’ve written about different ways to communicate as a manager and about the benefits of transparency for Chronicle Vitae, and I’ve written here in defense of status reports and about how meetings don’t have to suck. I don’t think I’ve ever written about how I structure communication on teams, so perhaps I’ll come back to that topic in the future.

In the meantime, let me know if there is any other aspect of my project planning process that you’d like to see me discuss in more detail, either in the comments below or by email.