How to Give Your Project A Fighting Chance (Part 1)

by Advo Team on

“What we learn from lessons learned is that we don’t learn from lessons learned.”
– T. Block

So you are about to kickoff a project. You have a budget, a deadline, and a deliverable: an awesome website launch. As you already know, there are 3 criteria by which you’ll measure your project’s success: on time, on budget, and at intended quality. Exciting stuff, congrats, and best of luck. Unfortunately, I am here to tell you are probably going to fail on at least one of those criteria. And why. And how to give yourself a shot at not failing.

Ready for Takeoff'

Danger, Will Robinson

The data on IT project success rates vary. But what the studies all agree on is the numbers are not good:

Pretty daunting, pretty depressing. Getting approval is actually the easy part; bringing the project to the finish line is exponentially harder. Project management is not for wimps. Before you scoff, think about these jobs:

When these PMs mess up, lives and even countries are at stake. Fortunately for you and I, we are here to talk about managing web projects and the worst that can happen is we get fired and/or bankrupt our company (I won’t mention names). But the fact of the matter is that all projects that fail make the same classic mistakes, whether you are working in construction or technology or banking.

The reasons are all well documented. They are maddeningly easy to spot from outside and incredibly difficult to avoid from within. They happen again and again and again and again. Sometimes they start as wishful thinking, magical budgeting and hallucinatory scheduling built into the start of the project, preordaining failure from the gate. Sometimes they accumulate like strands of hair in a sink – small shortcuts, slipped deadlines, and minor, poor decisions slowly choking the drain until the pipe is blocked and a huge mess backs out on the floor.

But…the good news is a successful web project launch is not impossible. The warning signs and mistakes that lead to failure can be overcome if anticipated and addressed proactively.

This blog is going to to be the first in a series discussing why and how failure happens and offering up some best practices and strategies for giving your project a fighting chance at success.

Are you sure this is the way'

I Want To Be A PM When I Grow Up

I was already doing project management in my first job out of college for a couple of years when I came to the terrifying conclusion that managing projects is hard. Or rather, managing projects is easy, successfully managing projects is hard.

With the help of this exploding thing called the World Wide Web, I discovered an amazingly well-kept secret. Project management is a profession, a discipline. People actually get certified at it. And there are established processes, best practices, tools – a lot of them. Some organizations actually have entire departments setting standards for project management.

I’ll try not to bore you to tears but it’s useful to summarize some of this stuff because they are the containers for dozens of decisions that impact project failure or success.

The 4 Phases of a Project

  1. Planning
  2. Designing
  3. Implementing
  4. Operating (Supporting)

Note that these four phases happen to map nicely to common web development phases. Also note that if you aren’t budgeting and scheduling one of these phases appropriately, you are going to meet trouble in the rest of them. (Much more later in this series on that).

The 5 Processes of a Project

  1. Initiation
  2. Planning
  3. Executing
  4. Controlling (Quality Control)
  5. Closing

Note that each of these processes apply to your project as well as each of your phases. In other words, you’ve got to 1. start, 2. plan, 3. do, 4. monitor, and 5. finish, each of 1. planning and 2. design and 3. implementation and 4. operating. Take shortcuts at your peril – “Well, we carefully planned out development timelines and budget but had no established process for design…I think final comps are sitting on Frank’s desk, waiting for approval. So, yeah, we are already 2 months behind our original development schedule.”

If executing those processes within those phases is not challenging enough for you, don’t fret. Allow me to introduce the 3 project constraints, aka as the bane of your existence.

  1. Time – “But we’ve already promoted the launch date…”
  2. Money – “We’ve got a really tight budget but I am sure we can save some money in a few places…”
  3. Scope – “The VP of Finance says we need to just add this little thing…”

Ok, so those are your phases, processes and mortal enemies – what exactly is your job as a project manager? Answer: pretty much everything.

Continuous Management Responsibilities

  1. Time Management: make sure it’s on schedule and going to stay on schedule
  2. Cost Management: make sure it’s on budget and going to stay that way
  3. Quality Management: make sure it doesn’t suck
  4. Scope Management: preventing stakeholders from turning your website into a video game
  5. Communications Management: everyone on the same page at all times
  6. Resource Management: people produce projects and even with the best team, you’re going to need carrots, sticks and a bag of psychological tricks
  7. Risk Management: What you are doing to prevent and address problems on any of the above
  8. Integration Management: your plans and processes around this whole thing
  9. Procurement Management: hiring the right vendors and making sure they deliver

Other Key Terms

  • Stakeholders. All decision makers and people vested in the outcome of the project or a project phase need to be involved from the start and signed up for the plan. (Easier said then done).
  • Dependency. We can’t do that until this is done first. Really.
  • Critical Path. If you line up all the dependencies with duration on a calendar, this is the fastest the project can be done.
  • Milestone. A significant marker in the project status that tells you where you are at – ie design completed, alpha version released.
  • Contingency. Things are going to go wrong and your contingency plan is what you turn to when they do.
  • Sponsor. This is not someone you talk to about craving a drink, this is the person or entity footing the bill and likely to fire you if you fail.
  • Project manager. This is a person leading the project who has been empowered to make certain critical decisions on the project, knows what those decisions are, what they are not, and has direct access to someone who can answer the nots for them (expeditiously). If you don’t have authority to make critical decisions and adjustments on a project, you are not a project manager and should fire yourself before your boss fires you (see above).

Ready for Takeoff'

It’s Going to Get Messy

To frame our discussion going forward, in this blog series we are talking primarily about vendor-client projects (vs internal projects) where there is a client and vendor(s) that have contracted to produce a deliverable or deliverables. We are also talking specifically about web development projects (though the principles and scenarios apply to all projects).

There are a few reasons why the basic PM concepts should be important to you, whether you are the client or the vendor (and I have sat in both seats):

  • Just because you have a budget and can hire a firm to build a site doesn’t make you a project manager
  • Just because you’ve hired a firm with a really good project manager, doesn’t mean you won’t need to do project management
  • Just because you’ve been hired by a client with a lot of money and smart people, doesn’t mean the project won’t fail

In other words, the success of your web launch, as a client, rides as much on your performance, your leadership, and your decisions as it does on the vendor you’ve hired to build it. And if you are a vendor, your ability to pull off what you’ve promised hinges not only on your process but on that of your client. It seems unfair but it’s not – it’s shared responsibility and there is simply no way around it.

As a client, you’re paying a big chunk of money and yet you are still going to have to work your rear off to make the project work. As a vendor, you can do everything right on your end but dysfunctional organizational politics or basic incompetence from your client can easily destroy your performance and product.

Let’s go back to the three project constraints: time, money and scope. All projects that fail, or are troubled, can trace their problems back to fatal flaws in one or more of these three constraints. Not enough time, not enough money or poorly defined scope. Failure in one of these constraints will usually trigger failure in another. Not enough money caused the project to be under-resourced and stall. Not enough time caused the project to launch without key features. Changing requirements caused the project to go over budget and past schedule.

To make matters worse, we are working and living in a period of extreme financial pressures. When dealing with tightened budgets and reduced resources the natural tendency is to look for shortcuts. On projects, this translates to one or all of the following shortcuts: underestimating, overbooking, and/or underplanning. Notice how these shortcuts align nicely with the trifecta of constraints. Yes, incredibly, the three most critical measurements of a project’s success – cost, time, and quality – are exactly the ones that are most commonly tinkered with when shortcuts are applied.

There is light at the end of the tunnel

So there you have it, our stage has been ominously set and the challenge has been issued. However, don’t despair, there is hope on the way. But first, in my part 2 of this series, I’ll examine the shortcuts in detail, how and why they happen, their impacts, and how they map to the project phases, processes and constraints. Because, before you can solve and prevent failure, you must recognize its root causes, which are both simple and complex. Finally, in Part 3 I’ll provide you with helpful ways to solve these conundrums, adding years to your life and making your projects more successful.

References

Baker, Sunny & Baker, Kim. (2000). The Complete Idiot’s Guide to Project Management. Indianapolis, IN:             Alpha Books.
McConnell, Steve. (1996). Rapid Development. Redmond, WA: Microsoft Press.
Project Management Institute. (2000). A Guide to the Project Management Body of Knowledge. Newton                 Square, PA: Project Management Institute, Inc.
Schwalbe, Kathy. (2004). Information Technology Project Management. Canada: Course Technology.