« Scrum Architect Role and Responsibilities
Breaking into Project Management »

Project Success Principles

February 4, 2009 | Author: PM Hut | Filed under: Project Management Best Practices

Project Success Principles
By Rino Jose

Last week, I gave a 2-day workshop on project management. I focused on what I call the Five Principles for Project Success. It’s been my experience that when any of these principles are violated, a project is headed for trouble. Conversely, if a project is in trouble, reviewing these principles is critical for recovery.

1. Purpose

Everyone involved in a project at every level should always know the project purpose: who cares about a project and why is it important. People should know the project drivers (e.g., cost, quality, target date, feature set, stability, usability, performance, flexibility, accessibility, …) and how the drivers are ranked. This is the only way to rationally make tradeoffs within and across projects.

The project purpose is frequently overlooked because we tend to focus on the work that needs to be done and often get started on it without asking why. When this happens, we tend to work on tasks we want to work on, not necessarily what’s most important for the client/customer and stakeholders. We don’t move the project in the right direction, if in any direction at all. There’ll be plenty of motion, but not much progress. At some point (when the budget or schedule gets tight), we’ll have an emergency meeting to figure out what should be done and finally the project purpose will be recollected or even spelled out for the first time. Great, but too late. There won’t be room to recover.

The project purpose should be defined up front, and, again, everyone should know it. The purpose should be captured in something like a “Project Charter”.

2. Planning

The most famous quote on planning is probably from Eisenhower: “Plans are worthless, but planning is everything”. Ike said it in the midst of the Cold War, but it’s a timeless observation. When engaged in planning, we’re considering options. We think through risks and how we might address them. We lay things out, we make assumptions, we make choices. At the end of this we have a plan. However, no matter how thorough our plan or how much thought we’ve put into it, the plan can only reflect what we know at a given point in time. Things change. We may run into a set of unanticipated problems or perhaps the risks we did consider didn’t really have the impact we feared. When this happens, we should adjust the plan. We should re-plan.

Without planning, projects will be left to chance. Risks will come as a surprise and quickly derail a project. People will be constantly shooting from the hip, making decisions based on urgency instead of value, reacting to events instead of anticipating them.

Planning is something we should do throughout a project. When a plan is no longer useful, we should draft a new one. The plan itself is only a snapshot of what we knew at a point in time.

3. Tracking

To make rational decisions about projects, you need to track project data. Period. This isn’t something you get from chatting with someone. When you ask “How are things going?”, you’ll get a response like “Pretty good. I think we’re going to be done with this next phase soon”. What does that mean? What does that tell you? When someone says something like that, I hear “We’re not done yet”. You need a finer level of status than that. You should be able to answer questions like this at any point during a project:

  • Is the project running late? By how much?
  • Is the project over budget? By how much?
  • Which tasks can be started now? Are any of them late off the bat?
  • Is the project resource-bound? Where are the bottlenecks
  • What are people working on?

If you don’t have tracking, you won’t know if your projects are in trouble until the end. Key decisions will be delayed. Teams will miss important dates. The sense of urgency that should have come earlier in the project will come too late.

Tracking project data can be straightforward and easy if you have the right tools. If you set up your projects efficiently, tracking them basically boils down to logging effort left and effort spent. It can be that simple.

4. Demos

Demos are the real measure of progress. If you can show something working, then you’ve actually done something. If you can’t demo anything, then you really don’t have anything of value. Demos are great because they expose assumptions. They ensure that details are looked after. They get everyone on the same page, something especially important when there are several teams involved.

If you don’t do demos, teams that can work separately will — and they’ll work in isolation. Work won’t be integrated until the very end of the project. Everyone will feel their part is on track when, in reality, much of the work is yet to come. When integration finally does arrive, it will take much longer than everyone expects. There will be unanticipated rework, cost, and stress.

Demos are something we should always plan for in our projects. They can be fun. They give people a sneak peek at something that no one else has ever seen. It’s a time for teams to get together and show off, when executives get to drop by and see progress, a time to re-sync before moving forward again.

5. Consistency

Consistency is about predictable execution. It’s about dispatching work efficiently and having clean handoffs across teams. When you have consistency, your organization runs like a well-oiled machine. This can only happen when roles and responsibilities are clear, when processes are well-defined, and when people have the skillsets to play their roles.

If you don’t have consistency, you’ll waste a lot of time reinventing process on the fly. Tasks will be dropped, especially across team boundaries. There will be gaps in process, gaps in task assignments, and gaps in skillsets. Execution will stall and be unpredictable.

To become consistent you need to think through your processes and capture them in some form. Swimlane charts are a good tool to use here because they force you to think not only about what needs to be done, but also who should be responsible for it and what sequence the work should follow. It can be an interesting exercise to get people together to sketch out a process because it will quickly become obvious that everyone had a slightly different view of the roles and responsibilities. Getting clarity around this early-on improves consistency of execution.
More?

These are the project success principles that I’ve found to be crucial for project success. Time and time again, these are what I point to when projects go wrong. Of course, there are other principles “embedded” in these five (e.g., communication runs through everything above).

Rino Jose is a web application developer with solid background in engineering management and operations research. He is currently focused on helping mid-size organizations get their product priorities straight using novel techniques such as “value-based scheduling”. Rino runs, Portlander’s Progress, a blog where he writes on Project Management (among other topics).

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Wednesday, February 4th, 2009 and is filed under Project Management Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

Well said Rino! I couldn’t agree more, and most often see projects, large or small, failing because of what I call strategy (but purpose works!) and measurement (or tracking). It is incredible that the project management field has “matured” to such an extent, and yet there are still projects that do not follow these core steps.

On the demo front, I would say that there are (unfortunately) projects where you may not be able to demo until late in the game. If that is the case, still meet with stakeholders to review development towards functionality (even if it is via diagrams, HTML dummy pages, or stick figures on the paper). Because, as you pointed out, this gives everyone the opportunity to ensure that the project is moving in the right direction and that wrong assumptions are not being made.

Thanks for the post! Good review of great basics, that are often forgotten.

Kristina

Kristina Podnar wrote on February 4, 2009 - 6:44 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories