by Nigel Holmes

Created on: June 05, 2008   Last Updated: February 19, 2009

I've been an engineer for more years than I care to count, and as engineering work is primarily project-based, I've supervised and worked on many projects. Along the way I've made a few mistakes - make that a lot of mistakes - so I think I'm qualified to offer some advice on how a project should be managed.

Let's start with how to recognize a project. Unlike routine or repetitive work, a project is typically a one-time endeavor with a clear end point. This means it's usually temporary; when the project is done the person or people doing the work move on to something new.

This leads to the importance of defining the project objective. Most business people have an action orientation, which can be fatal to a project. If you start "doing" before figuring out what you want the end result to look like, your project is destined to fail.

Begin by writing a clear description of what the project will achieve. For example, imagine you want to build a tunnel under the sea from England to France, (yes, I know it's been done!). How will you know you've been successful? When the first train goes through or when it goes into service? What about keeping to budget? Finishing on time? Avoiding leaks? For a hundred years? Defining a project is hard, but it must be done and done thoroughly.

It's very important that everyone involved with the project understands what it's about. Who is involved? Well there's the customer, but he might not be the same person as the user. (Who would be the customer in our tunnel example?) You could make formal presentations to all these people but usually the best way to get buy-in is to work with these groups in creating the project definition at the outset.

Now that you've defined your end-point it's time to figure out how to get there. In project management speak, this is the Work Breakdown Structure, or WBS for short. If your project is fairly small, perhaps with only you working on it, you might be able to list out all the tasks by yourself. More typically though, it helps to get some experts involved. At this point you're going to start forming a team.

Selecting the right people for the project is critical. First, figure out what technical skills you need. For example, if you're going to tunnel under the English Channel, it might make sense to have a geologist on board to tell you what the drilling machine will encounter. Second, you need to get people with the right mix of personalities and work styles. One caution though: technical skill must take precedence over personality. If not, your team may work well but will ultimately fail.

Now the goal is defined and the team has developed the WBS, so what's next? Well the tasks have to be scheduled, and this is where a package like MS Project can help. There are lots of on-line resources that explain setting out a Gantt chart, determining the critical path and so on, but here's the key point: Let the team have input into the plan. That way they "own" the timescales and are more committed to achieving them.

And now, planning done, you're ready to execute. Fire the starting pistol, drop the flag, and away you go. From here on the job of the Project Manager is to monitor progress, avoid "scope creep," and apply corrections as early as possible. Oh, and act as coach, cheerleader, shoulder-to-cry-on, fundraiser and bearer-of-bad-news.

I'll finish with one last tip. A project is managed by talking to people, not by updating charts and emailing team members. Communication is absolutely the single most critical part of running a successful project. Get that right and everything else will fall in to place.

Learn more about this author, Nigel Holmes.
Click here to send this author comments or questions.