First Things First

I’m in the early stages of a new project. This provides me with an excellent opportunity to pay closer attention to what I’m doing and why… and then write about it. I am hoping to turn this into a serious of blog posts about how I run a project. The idea isn’t to focus on specific processes, but on the reasons behind them. The specific processes I use are determined by the needs of the team, and since I am currently working as a contractor, are often dictated by what my client wants. But there are some fundamental needs that are constant, regardless of the process the project team uses. I want to focus on those.

So, let’s start at the beginning. The very first thing to do when starting a new project is figure out what, exactly, you’re trying to accomplish. This might sound trite. You know what you’re trying to accomplish! It is probably even the name of the project, unless your work somewhere that is fond of giving projects code names.

But what you really know at the start of a project is a very high level, superficial version of what you need to accomplish. You have the broad strokes. You need to fill in the details, and in my experience, the more details you can fill in upfront, the better. Obviously, you can’t know everything at the beginning of the project, and things you think you know are likely to change. It is easy to fall into the dreaded “analysis paralysis” and spend far too much time analyzing things that are just going to change. But the other extreme is no better: rushing to start doing things when you don’t know what you really need to do is likely to produce a lot of wasted work.

As with many of these “Goldilocks” type situations, finding the amount of analysis that is “just right” is a bit of an art, something you learn from experience and that resists hard and fast rules. What works best for me is to have something I’m trying to produce, some tangible thing that represents my understanding of what the project needs to do, and that I can use to communicate that understanding to everyone else on the team. I know I’ve done enough analysis when I have my tangible thing completed.

Note that this thing is not the project plan. This is work I do before I start writing a plan (or writing stories, if we’re going to do a completely agile process). What my tangible thing is varies by project. Here are some examples:

• If my project involves producing software to automate or support some scientific or business process, I create a workflow showing that process.
• It is common in the drug discovery and development industry to write a “Target Product Profile” when a project crosses from discovery to development, or somewhere near that time. The TPP documents the “acceptance criteria” the drug candidate needs to meet in order to progress to the next stage.
• Some research scientists I know sketch out the figures they want to produce to put in their next paper before starting their experiments. Obviously, they don’t know what the figures will look like until they do the research. But in some types of research, it is possible to think about what figures you need to produce in order to have a meaninful story to tell in a paper.
• Another way to think about how to structure your research project is to develop a decision tree. This helps you think about your end goal, the various ways you might get to that goal, and how much effort it makes sense to expend on each line of inquiry.
• If you can’t think of anything else to produce, you can always fall back on writing a statement of scope. This is usually a paragraph or possibly two, stating the goal of the project and explicitly identifying which aspects of the larger context are in the scope of the project and which are not.

Whatever tangible thing you decide to produce, don’t skip this step and don’t decide you don’t actually have to make it tangible. I have fallen prey to the idea that since I’m just producing this thing for myself, I don’t actually have to produce it. It never ends well. The act of making the thing forces you to ask questions, challenge assumptions, and really understand what the project team needs to accomplish.

However, that doesn’t mean you need to make a big production out of doing this work. It might require a few meetings with the people who know the answers to your questions, but those meetings can be small and informal. Once you’ve produced your tangible thing, you can (and probably should) share it with the wider team, but don’t be surprised if they shrug and don’t see the value. It is not detailed enough to direct their daily work. That is not its job. Its job is to provide a mental framework onto which you can hang all the details as they start to come in, and that can guide you in making the decisions you need to make as the project gets going.

Once I have my tangible proof that I understand what we’re trying to do, I move on to developing a plan for how we’ll do it. I’ll leave that for another day.

In the meantime, feel free to suggest additional ideas for the tangible thing that proves you understand the goal of your proejct in the comments.