3 Universal Principles of Project Management

Note: Several years ago I did a guest post for a project management software provider. They asked a series of questions and I provided my thoughts. The original psot is no longer available, but as I feel it provides some good ideas I’m reproducing it here. 

 

What are the universal steps that comprise an ideal project management process?

That’s easy: Plan, Do, Check, Act. Nobody’s been able to improve on Deming’s formula, and I doubt anyone ever will.

For a more in-depth answer, I was at first tempted to list the processes or steps more traditionally thought of when discussing project management—planning, estimating, documenting, etc. The problem with this is that while they could apply to all projects, the varying degrees to which they’re used make them less than “universal.” Not all projects need planning in the same way, or the same degree of estimation (cost or duration). Much like “the only constant in life is change,” the only similarity in project management is that projects are different.

So how do you list “universal” phases of project management if there are no universal projects? You start with the principles of project management: what, why and how.

1. What

First universal principle: know what Done looks like.

What are we trying to accomplish? What is the end result of the project supposed to look like? What is it supposed to do? Or to put it another way, what does “Done” look like?

This is a universal principle with all methodologies of project management. How do we know when we’re done? More traditional project management defines this within a Project Charter, while Agile and Scrum practitioners start with the Definition of Done, and PRINCE2 uses Project Product Description, and so on. The key is to define up front what we’re trying to accomplish (even it it’s just a within a Sprint). Without that, we’re just wandering aimlessly.

 

2. Why

Second universal principle: know why you’re trying to get to Done.

Why are we doing this project? What are the expected benefits, or as Agile asks, what value is this producing?

Every project needs to have a “why,” a reason for being. If it doesn’t, then there’s no need for the project. A project without a reason is the very definition of waste. We need to know the why, so that we can evaluate progress and performance of the project against that “why” as we go along. All projects should have a continual feedback loop where the current progress is being evaluated against the intended or expected outcomes. Are we on the right track? Does the project still make sense?

Knowing the why, and measuring against that will allow for necessary changes to be made early, or even for projects to be cancelled if necessary.

 

3. How

Third ‘universal’ principle: know how you’re going to get to Done.

How are we going to manage this project? What methodology will we use?

The “how” is about more than a specific methodology (actually the methodology comes last). This is where we define the steps we’re going to follow to go from an idea or concept to a finished product. What are the specific steps we need to follow? Do we need a feasibility study, a prototype, testing, etc.? Would a traditional or Agile approach be more appropriate? Will we need to track progress against cost (Earned Value)? The “how” is where we define the specific steps, stages or phases we’re going to need to go through to complete our project.

 

Why is it important for project managers (whether specially trained or not) to know these universal phases?

Much like the “triple constraints” provide valuable information regarding your project in terms of scope, cost, and schedule, the “what, why and how” principles provide the most important information necessary for ensuring a successful project. Projects are done for a reason, to achieve a goal or specific outcome, and project managers are there to ensure the project achieves that goal or outcome. Without knowing and understanding the three principles, the project manager has no way of knowing what goal they’re trying to achieve, why they’re trying to achieve it, or how they intend to achieve it.

 

Which of these steps do you think are most often skipped or ignored, whether intentionally or accidentally? Why?

I don’t think it’s intentional, but the most often missed step, or principle, is the “how.” All too often we see projects started with project managers moving right from what are we doing and why are we doing it, into executing the first steps they think need to be done, without looking at the overall project.

All projects, whether traditional or using other methodologies, need some level of planning—BDUP, or planning User Stories and Backlog. Unfortunately, we see far too many examples of projects that were started with little to no planning involved. It’s like driving from New York to California.

I know the what (a cross-country trip), and I know the why (to visit family). Now, I can just hop in the car and start driving west, or I can look at a map and plan my route. Only one will be efficient and effective, and ensure I will reach my destination. I may be able to get there by just driving, but there’s no guarantee, and it will take much longer and cost more.

As for why this step is missed, I think there are a number of reasons, including pressure to get started by management (who don’t understand the value of planning), or not knowing how to plan. Another reason I’ve seen given is the fear that a plan somehow ties you into a specific path and doesn’t allow for changes or alterations. This is a common misunderstanding, and not true of good project management. A plan is a great guide, but a poor master.

Using the cross-country trip example, having a plan means that I know where I’m going and the route I’m taking. This allows me to make some scenic detours for sight-seeing, knowing I can return to my guide to make sure I’m still on track after the change in plans.

 

What can go wrong if certain steps in the process are ignored?

The short answer is project failure.

The “what, why and how” principles are similar in nature to the ‘”triple constraints” (where hitting two out of three is acceptable and you can still achieve success) but far more restrictive. With these principles, if you miss one, your project is going to fail.

• Don’t know what you’re doing? Well, it’s kind of hard to do a project then.
• Don’t know why you’re doing it? Again, kind of hard to know whether you’re doing the right thing (project) or not.
• Don’t know how you’re going to get there? Settle in for a long road filled with re-work, pain and suffering.

These are the only three steps in the project management process that can’t be ignored.

 

How can today’s online project management tools help project managers follow these steps more effectively than in the past?

Online project management tools are useful to project managers if they provide a way to introduce, document, and reference these three principles. Too many project management tools jump from ‘insert project name’ into establishing teams, assigning resources, identifying tasks, or building a schedule. Even more so, many of today’s project management suites focus on the collaborative aspect of project management, at the expense (or in some cases exclusion) of equally important aspects such as estimating, budgeting, documentation, risk management, etc. All too often, these other aspects of project management (risk identification & management, cost and budget development and tracking, materials procurement, etc.) must be done outside the project management suite.

 

Do you use or recommend to your clients any particular online project management solutions?

I tend not to recommend or be in favor of any particular project management software. This isn’t because I like or dislike them, but rather, because my focus is on the principles. Tools are supposed to be aids to project managers, to help them do their jobs. Unfortunately, too often the tool is confused with the practice. A good project manager must be able to manage the project without any tools. They must know how to build a schedule and verify the logic, how to estimate task durations, how to build, track and maintain budgets, how to communicate with their team (in whatever medium is appropriate), how to work with stakeholders, and how to keep an eye on the project as a whole.

I would be inclined to recommend an online tool that focused on facilitating project management in a generic context, that incorporated ways to include ‘generally accepted’ practices, rather than attempting to define or teach project management according to how ‘they’ felt it should be done. As an example, I was recently in a training meeting for an online project management suite, where the trainer told me that A) there are multiple definitions of a milestone, and B) projects should have no more than four milestones. Both of these statements are incorrect, but these faulty principles have now been transferred to another group of novice project managers.

A project management suite that seeks to be an aid across all aspects of project management—as opposed to either restricting itself to what the developers feel is important or re-defining processes and terms—would gain my recommendation.