When you have been managing projects for a while, you will start to notice that some things are always true. Each of these ‘Project Management Rules‘ reminds us of something important about Project Management, so I have been collecting them for nearly 20 years.
I am sure the list in my notebook is far from complete. so, please do add your own to the comments at the bottom of this article.
I am equally sure that some people will have good reason to disagree with the universality I am claiming for each of these (and I welcome your comments on that too).
And, of course, I know that you may have your own interpretation of some of these Project Management rules (which I also invite you to share below).
But, here’s the thing…
I think each of my Project Management rules offers a valuable insight into how to manage a project effectively. So I have decided to share twelve of the best with you. I hope you will comment on them below. I don’t know if any one of them will stop your project from failing, but I do know that following each one will make you a better Project Manager, who gets better results.
Mike’s Project Management Rules
None of my Project Management rules is more important than the others – although I don’t doubt that you will have favorites! So to organize them, I have followed my own sense of the story of a project. This doesn’t mean there is any compelling logic for the sequence – it just makes sense to me. Indeed, it is probably best to think of each one as a stand-alone rule. This is why, in the set of free posters you can download, the rules are not numbered, so you can print and use only the posters you like.
Are you a Watcher or a Reader?
I’ve summarized the content of this article in a short video…
Save your Arguments about what a Project is for the Coffee Shop.
Focus on the Characteristics of What Needs to be Done.
Project Managers are justly proud of our calling. So we’ll defend it at any time. When I finally started managing my first project, I remember being told by a colleague (in a patronizing kind of way):
‘Well Mike, that isn’t really a project. It’s just an initiative’.
Later in my career, when I was indisputably managing a project, another colleague said to me (with a straight face):
‘You see Mike, you’re managing a project, and I’m managing a program’.
Of course, there are definitions of what a Project is. And you can watch a short video of my description of what a Project is, too. But why would you waste time arguing about it? What matters is what you need to get done. And the more something looks and feels like a Project, the more of your Project Management toolset you will need to deploy.
The same is true, by the way, of Programs and Program Management. Save your philosophical arguments for the coffee shop, where they belong. The first of my Project Management rules reminds you to be practical, and focus on the job at hand.
Rule 1: Save your arguments about what a #Project is for the coffee shop. Share on XThe One Thing a Project Manager Craves, above all else, is Control
Projects exist on the edge of chaos. They need to deliver something specific in an environment of uncertainty. And they need to do so within deadlines, using a constrained budget and resource pool. And of course, you will have multiple team members and stakeholders to co-ordinate and please.
So, Project Management is fundamentally about creating a controlled environment within which you, as the Project Manager, can feel a sense of control. It is no coincidence that the developers of the UK Government’s Project Management methodology, PRINCE (now, PRINCE2), chose the acronym they did, for their new methodology. PRINCE stands for PRojects IN Controlled Environments. PRINCE2 was updated in 2007, by the way.
A large part of what you will do as a Project Manager will be about creating control. And many of the Project Management tools and techniques, and systems and processes that we use are designed to help you.
Rule 2: The one thing a #Project Manager craves, above all else, is Control. Share on XScoping is the Most Difficult Part of Project Management
Scoping your project is a process of negotiating with a range of stakeholders. All of them will have different wants and needs. And your job is to balance those wants and needs and come up with a set of design features that best meets the collective needs, with a balance that properly reflects priorities. And, as if that is not hard enough, your final scope must also reconcile with your available budget and resources. If not, you nee to go back and do some more negotiating.
Rule 3: Scoping is the most difficult part of #Project Management. Share on XIt is no coincidence that more of my Project Management rules are about stakeholders than about any other aspect of Project Management. Indeed, I have also collected a set of rules about stakeholders and Stakeholder engagement, but let’s save those for another day. The perfect tool to finalize your scope and make sure you document all the detail is a Work Breakdown Structure. This is a tool to make into your friend.
Creating a Robust Project Definition
To help you with scoping – and all other aspects of Project definition, take a look at our Project Manager’s Project Definition Kit – an innovative course and resource kit, so you can take a jumble of ideas, needs, and requests and turn it into a well-defined project.
You can Please all of your Stakeholders some of the Time, and Some of your Stakeholders all of the Time. But you Can’t Please All of your Stakeholders all of the Time
In my mind, this rule is the primary reason for the previous rule. As soon as you manage to please some of your stakeholders, you will inevitably start to upset others, with contradictory expectations or aspirations.
I don’t particularly claim originality for any of my Project Management rules, but this one will certainly sound familiar to you. Whether the credit should go to Lincoln, Barnum, or Lydgate is something I’ll leave to the scholars. It seems to me that these multiply-attributed quotes and their variants do always contain an important truth.
Rule 4: You can’t please all of your #Stakeholders all of the time. Share on XWe have a whole bunch of articles about stakeholder engagement:
- What is Stakeholder Management? | Video
- Good Customer Service: How to Keep Your Client and Stakeholders Happy
- Do You Know the Top 20 Techniques for Stakeholder Analysis?
- How to Plan Your Stakeholder Engagement Campaign
- This Set of Stakeholder Engagement Strategies will Power You up
- 4 Steps to Engage Difficult Stakeholders
- There’s also a Kindle Exclusive eBook that collates articles these and more
Projects would be Easy, if it weren’t for the People
We often think of Project Management as a technocratic, process-driven discipline. If it were, things would be a lot more predictable and, well… easy. But people are not easy. They have opinions, agendas, aspirations and, well, foibles. Getting the best out of your team, and keeping your stakeholders happy are the real hard work of Project Management. And this part is far from easy.
Rule 5: #Projects would be easy, if it weren’t for the people. Share on XStakeholders will Determine the Success, or Not, of your Project
If there is one of my Project Management rules I tend to over-use in training courses and seminars, this is it. But it is so true. It doesn’t matter how well you define your project, the rigor of your planning, or the excellence of your execution. If your stakeholders don’t like or accept what you have delivered, you have failed. Because your stakeholders will be the ones who turn your deliverables into outcomes.
While it may suit you to assess your performance on the quality and functionality of your deliverables, and on the time and cost of your implementation, your stakeholder will evaluate your project on its outcomes. And it is your stakeholders who will turn deliverables into outcomes.
To paraphrase a familiar saying (also of widely disputed origin): ‘Keep your team close, but your stakeholders closer still.’
Rule 6: Stakeholders will determine the success, or not, of your #Project. Share on XFailing to Plan is the same as Planning to Fail
This is not one of my Project Management rules. But this is an often quoted prediction, which is a modern form of a saying attributed to Benjamin Franklin.
It is at the heart of what most Project Managers believe is the essential secret of success: robust project planning.
Failing to plan is the same as #planning to fail Share on XI cannot come up with a better paraphrase of this to form my own rule, but there is another quote, which I find myself using more often…
‘In preparing for battle I have always found that plans are useless, but planning is indispensable.’
This is attributed to President Dwight Eisenhower – formerly a senior US general during the Second World War. It is another of those great quotes I find myself repeating again and again – even though it is not truly one of my Project Management rules. For me, it holds an important truth about why we plan. We don’t plan because we believe that our plans will come true: no experienced Project Manager would be that naive.
We plan because the process of planning helps us understand what we need to do, and sharpens our senses to recognise the conditions and events that will warn us of problems. A plan is something to vary in the light of change; not something to stick to rigidly, regardless of circumstance. We also published an article on 12 Project Planning mistakes that can let you down – and how to fix them.
'Plans are useless, but #planning is indispensable' - Eisenhower. Share on XMilestones are your Best Friends
When you use milestones to plan, you create distinct points where you will be able to check progress. And the delightful thing about a milestone is that you have either reached it or you have not.
There is no ‘sort of’ or ‘maybe’ about a milestone. And that means that, like your best friends, a milestone will always tell you the truth. It will always give you a single fact that you can rely upon. And for that reason, on a Project, milestones are your best friends.
Rule 7: Milestones are your best friends Share on XShift Happens! Things Change
I once told the story of how my book on Risk Management, ‘Risk Happens!‘ came by its title. Essentially, it was going to be called Shift Happens! and the cover design had already been done, when I was threatened with legal action if I used the name. A bogus threat I am sure.
But any risk manager knows that risk is a combination of likelihood and impact. Although I was confident that the likelihood of a successful prosecution was extraordinarily remote; the potential impact on my life of such action (even if it failed), let alone the cost of any successful claim, was enormous. Ho hum. Shift happens. Things change.
Rule 8: Shift Happens! Things #change. Share on XWe’ve written a lot of articles about Risk Management:
- What is Project Risk Management? | Video
- How Project Risk Management will Make You a Better PM
- Indispensable Guide to the Sources of Project Risk
- The Project Manager’s Guide to Simple Risk Analysis
- Risk Response Strategies: Full Roundup
- How to Build a Robust Project Risk Culture [8 Steps]
- There’s also a Kindle Exclusive eBook that collates articles these and more
Fizzing bombs will explode if you don’t deal with them
This is one of my Project Management rules that people frequently misinterpret. They think, for obvious reasons, it is about risks, and how we need to engage in active risk management, to avert any threats to our projects. This is true, of course. But it is not the principal interpretation I have for this rule. I think of it at a far more mundane level.
For me, this rule links best to the one that says: ‘Project Management would be easy, if it weren’t for the people.’
All sorts of little issues will crop up during the life of your projects. But you will be tempted to ignore them as a minor irritant, and focus on the project itself. A lot of these things are about people: conflicts and disputes, under-performance, behaviors… Another strategy you’ll be tempted to use is to pass on the issue to someone else. A bit like Tom and Jerry passing a lit bomb to each other.
The fact is, though, that if you don’t deal with these things properly, they tend to go off in your face. And that can mean singed whiskers for you, just as it does for Tom in the cartoons. The sooner you pinch ff these kinds of issues; the less pain they will inflict.
Rule 9: Fizzing bombs will explode if you don’t deal with them Share on XNo Plan Survives Contact with the Enemy
Here is another direct quote, which is therefore not one of my own Project Management rules. It was said by the Prussian/German General, Helmuth von Moltke. What it signifies is that, as soon as you start implementing your plan, the real world will step in and get in the way. Shift will happen and pretty soon your plan will be out of date.
Von Moltke, like Nelson before him, had the concept that Nelson referred to as ‘Commander’s intent’. These are general directives, rather than direct orders.
As a Project Manager, you will have the definition of your project, an understanding of your stakeholders, and a framework of governance. Within these constraints, you need to be able to sense deviations from your plan and adapt accordingly. You will need to keep your plan under constant review, and update it in the light of changes to your situation.
'No #plan survives contact with the enemy' - Helmuth von Moltke Share on XAn Absentee Project Manager is a Contradiction in Terms
If you accept that Shift Happens and that your plan will rapidly become out of date, then the tenth of my Project Management rules must follow logically.
If you aren’t there, you can’t manage your project.
This doesn’t mean you are indispensable. It means that if you need to step away from your project, you need to appoint a locum Project Manager to stand in for you, and to give them the authority to do what it takes to deal with the shift. If nobody is present to manage your project, it can very quickly spiral out of control.
Rule 10: An absentee #Project Manager is a contradiction in terms. Share on XIf it isn’t Right, it isn’t Finished
Notice what this rule does not say. It does not say: ‘If it isn’t perfect, it isn’t finished.’ Perfection is not the measure of completeness, or very little would ever get finished.
Right from the outset, you need to work with your stakeholders to define what ‘right’ looks like. Once you have that definition locked and documented, your job is simple: deliver ‘right’.
This is the endpoint, and stopping anywhere short of it will be to cheat your stakeholders. And guess what:
‘Your Stakeholders will determine the success, or not, of your Project.’
Rule 11: If it isn’t right, it isn’t finished. Share on XThe Level of Attention to Details can often Make the Difference between Success and Failure
One of the paradoxes of Project Management is summed up by the last of my twelve Project Management rules.
On the one hand, you need to be able to take a wide perspective and see how all the different parts of your project fit together into a larger whole. But on the other hand, you also need to be able to zoom in and get each of the details right.
Notice that this rule does not specify what the ‘right’ level of attention to detail is. That will vary from project to project. So it is your job, as Project Manager, to determine this anew for each of your projects. But it is an important thing to get right, so give it careful thought.
Rule 12: Details can often make the difference between #project success or failure. Share on XWhat are Your Own Project Management Rules?
Please do tell us what rules you have discovered from your own Project Management experience, using the comments below.
Many PMs believe that there is a right or best way to manage projects. They recognise a number of hard-learned principles or fundamental truths to be observed. While conscientiously adhering to such principles will not guarantee success, they are ignored at our peril. Listed here in no particular order, the following ten most frequently identified guiding practices, derived through the analysis of both successful and unsuccessful projects, provide a foundation for the successful management of our projects:
1. Establish and regularly reappraise the justification for our project.
2. Have a sponsor who gives us clear direction and effective support.
3. Agree and unambiguously define project roles and responsibilities.
4. Identify and communicate with users and other stakeholders early and often.
5. Apply a disciplined approach from project conception to benefit realisation.
6. Pre-empt problems, including HSWA hazards, and address issues promptly.
7. Check progress regularly and take timely corrective action to keep on track.
8. Manage change to ensure effective product adoption.
9. Recognise that project success occurs when business case benefits are realised.
10. Capture lessons as the project proceeds and learn from each project.
Having mentioned these principles, it wouldn’t be right to hold them in obstinate blindness since they’re inclined to evolve. For example, it’s only in recent years that stakeholder engagement, change management and benefit realisation have been formally recognised as important PM practices.
Jim, this is a great list, thank you very much.
The only one I worry about is No. 2 – this is not under your control. But it’s certainly an important success factor.
But what really strikes me is your last comment. It’s absolutely right that we need to constantly review even our most-cherished ‘rules’. And, funny you should mention benefits management. Program Managers were using this in the 1990s, but it is new to Project Managers. And I’ll be saying a lot more about it soon!