By: Meri Williams

June 13th, 2007

Reader Rating: 9

"Project Management" has always been a term more likely to elicit a groan than a smile. Nevertheless, the use of project management skills is often what distinguishes an easy, successful project from a painful and unsatisfactory one. In a world where clients and business partners increasingly want a full solution, rather than just the component pieces of design and code, having basic project management skills, at least, is quickly becoming a requirement for web professionals.

In this article I'll talk about what project management (PM) is and what it isn't, introduce you to the basics of the project lifecycle, and provide you with an arsenal of tools that you can use to make your projects run smoother, faster, and easier, starting from today. I also include some handy documents you can download for use in your own projects in zip file format [1].

So, what IS Project Management?

The Project Management Institute's definition of PM is: "... the application of knowledge, skills, tools, and techniques to project activities to meet project requirements."(PMBOK Guide, 3rd Edition, Project Management Institute Inc., Pennsylvania, 2004.)

A less abstract version of this definition is that PM is what you need to make a project happen on time, within budget, with required scope, and quality.

My personal definition is that PM is the simplest way to look like a superhero without requiring the involvement of any radioactive spiders or questionable parentage.

There are also lots of things that PM isn't, the most notable being a replacement for personal productivity. Whether you use a simple todo.txt file, a hipster PDA, or a full GTD (that stands for Getting Things Done [2]) system to keep yourself organized, you're still going to need to use PM tactics. PM is all about making the project happen -- how you complete the work that you need to do for the project is up to you. Mixing up personal productivity and PM is one of the main reasons for those groaning reactions I mentioned earlier: if you make your PM tools double up as your to-do list, then you're obviously going to end up with a lot more detail than anyone else in the project (including the client!) needs to see. It's a very common mistake seen with smaller projects, where realistically the project manager is also doing a lot of the project work, if not all. It can be a lot easier to keep the distinction in large-scale projects with dedicated project managers, but even there you see evidence of the mistake, with project plans starting to look more like personal brainstorms rather than a path to a future that involves getting home in time to see your kids.

Now that we've talked a little about what PM is and isn't, let's move on to looking at the project lifecycle.

The Generic Project Lifecycle

The generic project lifecycle is fairly simple -- first you begin the project (Initiation), then you go on to actually do the project (Planning, Executing, and Controlling, which form a loop, since expecting things to go right first time is rather unrealistic) and finally you finish by making everyone happy and, with any luck, receiving payment (Closure). This process is illustrated in Figure 1.

Figure 1. The project lifecycle (see larger image in new window [3])

Since typically most time and effort is spent in the Executing (completing tasks) and Controlling (keeping everything on track) phases, many people think these are the most important. It is true that these should be where you spend most of your time -- after all, nothing would be completed if you didn't! -- but they are not the most important.

The most important project phases are Initiation, Planning, and Closure. Let's take a closer look at these three phases to see why.

Initiation

I often argue that the most important project phase is that of initiation. It's where you make the contract (or agreement, if you are doing projects internal to an organization) with your clients, work out why the project is happening, what you're trying to achieve, and what defines the project's success.

Projects that are set up correctly are much more likely to succeed than those that aren't. This means that making clear what the expectations and objectives are from the outset is important. It also means that defining what success looks like is essential. At this stage it's also useful to look at assumptions (for example, the company's branding might be expected to stay the same for the duration of the project) and the constraints (such as the people who need to approve the design might be away on holiday for the whole of September).

Planning

-- Eisenhower

Planning is very important, but often not for the reasons that people assume. There are a few reasons to plan, including:

• forming a better understanding of what needs to be achieved
• identifying dependencies (such as the design needing to be completed before it can be coded)
• communicating with the client
• collaborating with your team members, so that everyone understands the big picture and the implications if delays are experienced

You'll notice that I don't list "so you can follow it slavishly" as a reason for planning. Much as you may be able to plan tomorrow's work in detail, it's impossible to plan an entire project in lots of detail at the outset. It's also unnecessary: yes, you need to know the key milestones that need to be delivered, the dependencies, and rough timelines, but trying to plan down to the day, hour, or minute at the outset of the project is futile. Nothing stays the same for long enough for that approach to make sense.

Also of great importance to the planning stage is identifying who is going to be involved with the project, both on your side (who's going to be in your team?) and on the client's side (who will you be dealing with and receiving input from?) The term stakeholder refers to anyone who has some interest in your project; this may include the marketing people who want to use the web site you're developing as a marketing tool, the admins who will be asked to add new content, and the salespeople who may want to make sure the web site doesn't say too much and that they still have plenty of negotiation room.

It's important when identifying stakeholders to remember that hierarchy doesn't define importance where your project is concerned -- if the admin team find it too hard to update, their lack of support can be just as damaging as when the CEO doesn't like the color scheme.

Closure

Web projects don't end when the site goes live. If you've ever tried to just send a site live and then held out your hand for the check, you'll have experienced what I term the "undead stakeholder" phenomenon: people who had a stake in the project returning again and again with more requests or improvements or even just support queries. The reality is that your project isn't finished until the key stakeholders agree that it's finished, which is another reason why defining the success of the project in the initiation phase is so important.

So what do you need to do in the closure phase? Firstly, you need to demonstrate that you have met the success criteria. Secondly, you need to obtain the stakeholders' agreement that you have met the success criteria. Thirdly, you need to make sure that the future of the product you developed (whether it be an application or a web site) is assured.

Typically, this last will mean putting in place some sort of support structure. If you're going to deal with the ongoing support and maintenance yourself, then you need a Service Level Agreement, as we'll see shortly. If you're handing over to another team, then you need to make sure they have the training and documentation that they need.

So what's So Hard about That?

When you look at the project lifecycle this way, it all seems like common sense. So why do so many projects suffer from delays, overrun budgets, or fail to deliver the desired features and quality? The reality is that paying attention to the different phases of a project isn't hard and doesn't even require much time. Unfortunately, however, there are two perceptions that mean people seldom give PM the attention it needs.

The first is the perception that PM distracts from the "real work," whether it be designing, coding, or some other facet of web work. The unfortunate reality, however, is that without appropriate PM the "real work" expended can all be for nothing -- what you build might be beautiful, but if it doesn't help if it's the wrong thing.

The second perception is that PM takes a huge amount of time. This can certainly be true: if you try to do everything that traditional PM demands it can definitely turn into a full-time job. There's a balancing act between the "science" of PM (what you're told you should do) and the "art" of project management (what you actually need to do). Let's focus a little more on the minimalist side of the art.

Essential Tools for Getting it Right

I've asserted that being successful at PM isn't hard, and now I'm going to introduce you to a set of essential tools for the arsenal of every web project manager. Each tool has its own strengths and weaknesses, from those that are best for communication, for gaining a better understanding of what needs to be achieved, for collaborating with your team, to those that help you keep in control of your project. It's important to understand a given tool's strengths in order to ensure that you are using it appropriately.

Initiation Document

The most important tool for the initiation phase is very simple: it's a project initiation document that briefly summarizes why the project is happening. This document complements (but is quite separate from) the contract that you would normally sign with your client. (If your project is internal, this document complements the steps that occur within your organization before the project commences.) An initiation document helps to ensure that everyone is aligned on the purpose of the project from the start, and is much shorter than a typical project contract.

The project initiation document needs to summarize:

• the objective for the project (what you are trying to achieve)
• the key deliverables (how you are going to achieve the objective)
• the overall rationale for the project (why you are doing it at all)

Other things that should be included in the initiation document are key assumptions and constraints, as well as success criteria. This document should be a maximum of two pages in length.

The other important point about an initiation document is that you shouldn't just write it and then forget about it. It should be agreed upon with the key stakeholders in your project upfront (including the overall sponsor or primary client contact) and referred to on an ongoing basis. When you are making the difficult decisions about what changes to scope or design should be accepted, referring to the original objectives and success criteria of the project can be invaluable.

You can download a sample initiation document [4] (zip file format).

Project Plan

Your project plan can (and probably should) take different forms depending on where you are in the project. Initially a simple text document describing the main deliverables, big dependencies, high-level timeline, and the key resources required for the project might suffice. Later on, though, you may decide that you need a proper schedule, probably in the form of a Gantt chart, which shows key deliverables (listed as rows) represented as bars across a timeline (typically with weeks in columns), as shown in Figures 2 and 3:

Figure 2. A simple Gantt chart, implemented in Microsoft Excel

Figure 3. A more detailed Gantt chart, implemented using Microsoft Project (see larger image in new window [5])

Important guidelines for planning include:

• Plan milestones, not tasks: It's very hard to measure how complete a task is, whereas a milestone is binary: it's either done or it's not.
• Break your milestones into small enough deliverables that you can track well: Aim to have mini-milestones small enough that one can be delivered every two to three days, without breaking down into nonsensically small portions.
• Assign each mini-milestone to one (and only one) person: Clear responsibility makes it easier to get stuff done, and your team will appreciate that you show your trust in them.
• Reflect the authority level of your plan in the format: Sometimes people create full plans and schedules without doing the work behind them. You've probably been in a situation where you're presented with a plan that is telling you that you need to complete all design or coding in 13.5 days, without ever having been asked how long it will take you. Make sure that your plan format reflects the best information you have at the moment, and no more. If that means only sharing a flowchart or list of milestones with key members, rather than a full schedule or Gantt chart, then do so.

Risk Management Plan

There are risks to any endeavor, and web projects are no exception. In order to manage your risks, you need to first identify what they are, then rank them by likelihood and severity. It's up to you to decide where your threshold lies: you'll probably want to create a plan for dealing with those risks that are both likely and severe. You also want to determine how you'll be identifying whether a risk is becoming an issue, so that you know when to trigger your contingency plans.

Along with the project plan, your risk management plan is something you should definitely share with your client and key stakeholders. They need to understand what might go wrong and what you plan to do if these eventualities occur -- they might even have better ideas for how to deal with certain contingencies!

Issue List

An issue list is very different from the bug lists you're probably using already. Bug lists are about the technical defects you've found in the product; issue lists are about problems in the project itself. It's therefore worth keeping the two lists separate -- after all, the best person to fix the CSS padding bug is unlikely to also be the best person to negotiate a compromise between the marketing and admin departments so that the design can be finalized.

An issue list can have as many or as few fields as you need. You'll want to keep it lean so it's not a drag to keep updated, but still contains information to make it useful. Typically, I use an Excel spreadsheet kept where anyone can update it, with the following fields:

• date entered
• description
• owner
• status (open, in progress, closed)?solution
• date resolved

You can download a sample issue list [6] (zip file format).

Balance Quadrant

The balance quadrant is a very useful tool when you're dealing with a number of requests to change the scope of your project -- adding extra functionality, for instance. There are four factors that are balanced in any project:

• time
• cost
• quality
• scope

The relationship between these factors is illustrated in Figure 4.

Figure 4. The balance quadrant

The key message of the balance quadrant is that changing any one factor impacts the other three. For instance, if you want to cut the time in half, you'll need to spend more money (increase cost), reduce the amount to be done (reduce scope), or make sacrifices in quality (reduce quality). This is demonstrated in Figure 5, although you shouldn't take this metaphor too literally -- it just shows that a change to one part of the quadrant impacts on the other three.

Figure 5. An increase in one quadrant results in an increase or decrease in the remaining quadrants

Realistically, it's impossible to prevent changes in your project. What you can do, however, is help the client and stakeholders understand the impact of those changes. If it means the web application will be delivered two months later, is the latest whiz-bang feature request really worth it? They should be the ones deciding, but you are responsible for helping them to make a well-informed decision.

Stakeholder Reviews

Stakeholder reviews are a mechanism for identifying and exploring differences of opinion. However much you and your team might feel that everything is going to plan, the project's stakeholders may disagree, whether it's the design they don't like, a key requirement they feel has been misinterpreted, or a missing feature.

By holding reviews with the key stakeholders, you can identify these issues early and decide whether or not a change in direction is needed. You can't realistically expect to achieve consensus all the time, but you can get the issues documented and the route forward agreed upon. Keep these reviews short and focused and hold them face-to-face whenever possible.

Progress Updates

Whereas stakeholder reviews are useful for making sure that those who have an opinion about the product you are developing are heard, progress updates are more to keep people informed of progress in the overall project. Keep this short and to the point: a good format has overall status at the top, sometimes using traffic lighting (red for severe issues, yellow for off-track, and green for on-track) if you are showing the status of several stages or milestones, with a more in-depth discussion of the specific achievements and issues following.

This means that those who just want to know how the project is going can just read the overall update at the top and can decide for themselves whether they want to continue reading to get the detail.

The other thing to consider is whether you are going to deliver progress updates over email, in a document, or in person. Discuss this with your client or internal customers, along with the frequency desired. You may find that only a monthly update is needed when things are going fine, but when issues are being encountered more frequent updates might be desirable.

An example progress update report is shown in Figure 6.

Figure 6. A progress update report

You can download a sample progress update report [7] (zip file format).

This is the last of the handy tools to use when you are actually doing the main work of your project. Realistically, most of your time will be spent doing the work (executing), keeping things on track (controlling), and re-planning as needed. Once all that work is completed and you're ready to go live, then you need to think about the next stage: closure.

Close-out Meeting

A close-out meeting is important to ensure that the project is finished to everyone's satisfaction. It should center around the original project initiation document, reviewing the milestones that have been delivered and evaluating whether the success criteria have been met. If decisions were made along the way (during issue resolution or stakeholder reviews, for example) that have resulted in a departure from the original deliverables and success criteria, then these should also be reviewed.

The outcome of a successful close-out meeting is that everyone is satisfied that the project is finished and that provision has been made for the future. Depending on the circumstances of your particular project, the latter will either center around a Service Level Agreement (SLA) or a training plan.

Service Level Agreements

If you are going to provide the ongoing support and changes for the web site or product, then you will need to have an SLA in place. This document sets out the expectations for changes and support, including how quickly you are expected to respond to different types of issues; for instance, if the web site is unreachable or unusable, a faster response time would be expected than if there were simply a new page to be added.

You need to ensure that you cover all the different types of work that you or your client might expect you to do; you also need to think about pricing. If this ongoing work was not covered in your initial contract, you need to consider whether a new contract and fee agreement is needed.

Typically an SLA will describe the different levels of incident. Sample levels that you might specify are critical (nothing works!), major (something important is broken), minor (less urgent, but still broken), and request (nice to have). You should also agree upon the expectation for how quickly each will be fixed (for instance, critical tickets are normally dealt with within hours, major days, and minor weeks). The SLA should also detail who should be contacted, whether there are different contacts for different types of issues (hosting versus content versus design) and what modes of communication should be used (email versus telephone versus opening a ticket via an eform).

Training Plans

If you are handing over the ongoing support and maintenance to another group, you need to arrange to give appropriate training for the team taking over the work. It's usually also worth providing documentation, so that inevitable personnel changes don't result in the new team members coming to you with questions months or even years later.

You should document everything that will need to happen in future for the site, from making content updates through to changing the design. You might also be expected to detail how the product was initially developed, what the underlying technical design looks like, and the design themes that should guide future updates. Again, this is an area where it's important to discuss expectations with your client; you might feel you've fulfilled all your obligations, but learn that they view the project as a failure because every incremental change renders your design less and less elegant, since those who inherited the site don't understand the overall themes.

A Note on Software:
You'll notice that the tools I described above were more focused around the business process than on specific software. Of course, there are a myriad of software packages designed specifically for PM processes. Many of them are very rigid, enforcing processes that might not be useful for your own projects.

I recommend using the most lightweight tool you can -- pick whatever will be useful and used by your team. It's better to have an Excel spreadsheet stored centrally that everyone can update than an all-singing, all-dancing Web 2.0 AJAXified application that no one except you bothers to log in to. Sometimes adoption is more important than features!

Summary

In this article, we looked at what PM is (and what it isn't). We discovered the key parts of the project lifecycle and saw why Initiation, Planning, and Closure are the phases that are most important but also most often overlooked. Then we considered the essential tools that every web project manager should have in the toolkit, including initiation documents, project plans, risk plans, issue lists, the balance quadrant, stakeholder reviews, progress updates, close-out meetings, and SLAs and training plans.

This was really just a taste of PM, but I hope it will give you an understanding of the key processes and some tools that you can apply immediately. There are, of course, more complex situations that may require more finesse, but before adding any extra process, please do make sure that it will really address the problem. Many project problems are best resolved by improving communication rather than adding more detail to the schedule or more categories to the issue list.

The best way to get to grips with PM is to apply it! Look at your current projects -- which stages did you do well or skip completely? Will some of the tools discussed help your current projects to run smoothly? Or do you want to ensure that you get a proper initiation document written for your next project?

PM requires a very different skill-set from designing and developing web sites. This can mean that it seems both strange and unusual when you first start using the tools and processes we've talked about here. PM is not something that requires innate talent, however -- with a little determination and focus, anyone can become an efficient project manager!

[1] http://www.sitepoint.com/examples/projectmanagement/projectmanagement.zip
[2] http://www.davidco.com/
[3] http://i2.sitepoint.com/graphics/guerilla_project_cycle_red.png
[4] http://www.sitepoint.com/examples/projectmanagement/projectmanagement.zip
[5] http://i2.sitepoint.com/graphics/guerilla_traditional-gantt.png
[6] http://www.sitepoint.com/examples/projectmanagement/projectmanagement.zip
[7] http://www.sitepoint.com/examples/projectmanagement/projectmanagement.zip