Project Management Basics for a Short Project

About a month ago, I was tagged on a tweet replying to a professor looking for good articles about project management to share with a class that would be doing a consulting project as part of their course work. For those who aren’t familiar with this sort of class, it involves the students working in a team to do a specific project for a client: it is like a short internship combined with a class. I’ve seen people I know work with these classes, and it seems like a great way to give students some hands on experience while also allowing companies to explore new areas or complete projects that are worthwhile but not the priorities they need their employees to work on.

Anyway, the friend who tagged me in the reply was hoping I’d know of some good introduction to project management articles to share. It turns out, I don’t. Most of the resources I point people to are about larger projects or are aimed at bigger teams. I’ve written some things that might be useful, but didn’t have those things organized in a “how to” guide for someone just starting out. So I decided to write one.

Here’s what I would tell someone starting out on a fairly short and focused project about how to keep that project on track and make it a success:

First, I’d make a case for not underestimating the importance of the mundane issues of executing on a project. Great ideas only take you so far: you also have to know how to make your ideas reality.

Once I’ve made my point that the project management is just as important as the technical work, I’d recommend spending a little time making sure you understand what, exactly, you are expected to produce. The classic method for doing this is to write a statement of scope and get the people you’re doing the work for to sign off on it, but in some cases, that will be too formal. However you do this, though, make sure everyone involved in the project agrees on what the project is supposed to produce.

Next, list out all of the high level tasks that you’ll need to complete to finish the project. Don’t forget the preparatory steps like assembling data sets and getting them cleaned up and in a standard form. Also don’t forget to include testing your work and fixing any issues that are found.

Look at your list of tasks and ask yourself which ones will help you track your progress on the project. These tasks are your milestones, and you’ll want to use them to make sure you’re on track to finish on time. For instance, in a software development project, some milestones might be:

• User sign off on the user interface
• Test plan written and test data assembled
• Feature complete (all required features present, but not necessarily tested)
• Beta release (a “pre-release” where a limited number of users try out the software)

The longer and more complex the project, the more milestones you’ll need. You should estimate how long it will take you to produce each milestone and make a project schedule. If you find you’re not meeting the milestones, you’ll have time to adjust your plans accordingly, and won’t have a big, unpleasant surprise at the end of the project. Most people can handle a schedule slip, if they know in time to change their plans to accommodate it. If you track your project milestones, you can usually see a schedule slip coming early enough to make a good backup plan.

Once you’ve identified your milestones, think about how all of your tasks inter-relate. This is called analyzing dependencies. Understanding your dependencies will help you respond more strategically when things go wrong (and something will always go wrong). To think about your dependencies, just ask yourself whether all tasks need to be done sequentially. Tasks that must be done sequentially depend on each other. Also think about which tasks need input from other people, and be sure to allow time for getting that input. For instance, if I have a task to produce a final design for a user interface, that depends on getting sign off on the design from the users (or a representative for the users). I need to plan to allow enough time to get that feedback: these people have other work to do, and won’t drop everything to look at my design as soon as I have it.

It is also important to spend a little time thinking about risk. People often want to ignore risk, because it is no fun to think about what might go wrong on your project. But if you spend a little time thinking about it, you can often come up with ways to manage the risk, and make it less likely that something going wrong will derail your entire project. Ask yourself what part of your project is most likely to fail? If there is a risk of a technical failure, consider pulling that work earlier in your plan. If you can do that, you will have more time to find another solution if your first one does not work out.

One often overlooked risk is around communication. Miscommunication within your team can lead you to have to spend time reworking things to make the various parts that everyone worked on fit together properly. Make sure you have a plan for how your team will stay in sync! It is also important to have a plan for how you will communicate with the people for whom you are doing the work. How do they want to be kept up to date? How will you let them know if progress on the project is blocked by something they control (e.g., you’re waiting for feedback)? Remember, these people have other things going on, and may not always remember what your project needs. How will you make sure you get what you need and that they don’t get any surprises? There are many options. Don’t be afraid to consider the tried and true option of status reports. They are often the best way to communicate with busy people.

As you get more experienced with project management, there is more you can consider doing, but the above steps will get you started and probably take you through most projects. This may seem like adding “extra” work, but don’t give in to the temptation to ignore these tasks and just focus on the technical work. A little time spent on planning can have a big pay off in terms of helping you complete your work on time… without needing to pull really long hours at the end of the project.