Effective Project Management for Web Geeks

Effective Project Management for Web Geeks

By Meri Williams June 13th 2007

Meri Williams

Meri spends her days managing projects at a large multinational, and
her evenings writing and developing web sites. She writes at Geek | Manager, as well as on her personal blog, and recently started Make Me A Speaker!

Illustration by:

Alex Walker

"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.

So, what IS Project Management?

SitePoint Feature Article

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)
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)

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

In preparing for battle, I have always found that plans are useless, but planning is indispensable

— 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.

>BackTrack

Leave a Reply