Smashing The Rules of Project Management

Quite a while ago someone emailed me a document titled ’50 Rules of Project Management’. The ‘rules’ are all tongue-in-cheek and consist mainly of analogies and sarcasm. As the years go by, I gladly share these rules with both aspiring and experienced project managers. However, the more I do this (and the more project management experience I get), I have begun to wonder how many of these ‘rules’ are actually true, rather than the views of disillusioned project managers. Or the views of people managed by incompetent project managers.

So here are some of these ‘rules’ to hopefully understand if there really is truth in jest.

Rule 1: ‘It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women’.

While there is an element of truth in this one — well okay, it’s totally true — we could have 18 babies born in nine months if 18 women are involved. This point illustrates that some project problems are not solved by throwing resources at them, however, it does highlight a valuable tool for project managers, that of resource levelling. This allows the project manager to allocate the necessary amount of resources to ensure the project timelines are met, while at the same time making sure that a project is not over-resourced, with non-productive resources consuming project budget.

Rule 2: ‘A little risk management saves a lot of fan cleaning’.

Project management is so much more than just creating a Gantt chart and tracking progress against it. In fact, the Gantt chart is only one of the tools at the disposal of the project manager. Along with all the ‘other stuff’ goes risk management which is so often overlooked by project managers. An old adage states that if something can go wrong, it will and a robust risk management strategy will increase the chances of a successful project outcome. It should specify what will be done to prevent the risk becoming a reality as well as what will be done should the risk become a reality. Should the risk become a reality, it’s also important to understand what it would cost both in terms of time and money so that an appropriate budget be set aside.

Rule 3: ‘The sooner you get behind schedule, the more time you have to make it up’.

This is not to say that tardy delivery should be condoned and tolerated, but it does go hand-in-hand with rule 2. While as many as possible risks should be identified upfront, it’s important that risk management remain an on-going activity. Additional risks and issues (i.e. risks that have materialised) should be identified as soon as possible in order that mitigating actions can be performed and contingencies made.

Rule 4: ‘Nothing is impossible for the person who doesn’t have to do it’.

There is a famous Pink Floyd lyric that talks about how army Generals lead from the back (it’s on Dark Side of the Moon if anyone is interested) and it’s very true of both project managers and managers in general. You should not expect your team to do something that you are unwilling to do yourself. This may include working weekends or even saying ‘no’ to customers.

It also highlights the importance of the project manager understanding the subject matter at hand. It’s no good to be an expert in a project management methodology and know nothing about the project and content that you have signed up to deliver.

Rule 5: ‘The sooner you begin coding the later you finish’.

While this rule has a taste of software development to it, it is applicable across a number of industries and project types. When kicking off a project the temptation is always rife to get ‘hands-on’ as quickly as possible, whether it’s developing a new website or building the new garden shed. This can be a fatal mistake. The project team needs to properly understand the deliverables as well as carefully plan and understand the approach to create those deliverables.

Although it sounds obvious, understanding the sequence of events and project dependencies is also key. I am still perplexed by the amount of software development projects that start building things before any user requirements are gathered or the amount of restructuring projects that kick-off with no impact analysis or change management in place. The point is that time invested up front does have a good payback later on in the project lifecycle.

Rule 6: ‘A user will tell you anything you ask about, but nothing more’.

The previous rule spoke briefly about gathering user requirements as a predecessor to developing any solutions. As a task in itself, business analysis may not be directly applicable to a project manager’s responsibilities, but will, however, play a large role in determining the overall success of a project. Poor or non-existent business analysis has been the cause of many project failures and continues to be something that many projects consider an optional extra.

Even projects that do incorporate an element of business analysis are still at risk, often because business analysts don’t understand the subject matter (e.g. ERP, Process Optimisation, Business Intelligence, Organisational Design) or have little or no knowledge of the industry vertical. It is therefore critical when asking the customer questions that a business analyst discovers and elicits as much as possible — not only what the customer tells them. A business analyst needs to be so much more than a scribe for a wish list. This topic is so vital that it will be addressed in its own article.

Rule 7: ‘What is not on paper has not been said’. 

Although many of us believe the art of chivalry is still alive and well and that a person’s word is their honour, it’s still prudent that your project has proper documentation and controls. This is important for all aspects of the project and covers planned documentation such as a business case, project initiation documentation, and regular status reports. Of equal importance is the ad-hoc documentation such as exception reports and change requests.

Nobody likes to say ‘no’ to a customer, so we need to become comfortable saying ‘yes…but’. This means accommodating a customer’s request but letting them know that there are implications, such as increased costs and timelines. It may sound harsh, but if you let a customer get away with something (like a scope increase) once, they are going to continue taking advantage, and you as the project manager will have created a nice stick for your own back.

Project documentation is important. Signed-off project documentation is critical.

Rule 8: ‘The project would not have been started if the truth had been told about the cost and timescale’.

 Closely related to the rule above and more specifically, to having a signed-off business case, this rule should be gospel for both project managers and their customers. However, this is not to say that high-costs and large time scales should be a deterrent to either approving or undertaking a project. A more accurate measure of project viability should be the return on investment. A well-prepared business case should clearly articulate this and be based on solid financial information.

While most project owners would like to see their projects receive funding, it’s very important that the return on investment (and supporting business case) is realistic rather than overly optimistic. A project that does not deliver on this promise is a failure.

It’s also very important that this business case is regularly reviewed throughout the project lifecycle to understand if the project is still viable and will deliver what was initially promised. The business case needs to be a ‘living document’ rather than a once off item.

Rule 9: ‘Fast — cheap — good — you can have any two’.

Often referred to as the triple-constraint or iron triangle, this implies that if a project sponsor or owner want gains in one of the areas, a compromise is needed in one or both of the remaining areas. This would appear to be true, but it does contrast with NASA’s concept of ‘faster, better, cheaper’ that was coined during the 1990’s by Dan Goldin the then NASA Administrator, implying that one can have all three of these.

While many successful space missions were delivered under this banner, there were a number of failed missions including the catastrophic Columbia accident, resulting in the death of seven astronauts.

So what is the lesson from this? Well, it’s important that more than ‘fast, cheap, and good’ are considered when making project tradeoffs. Other things, such as risk and longer-term objectives need to be considered. The project manager needs to have as much of this information to hand as possible as the project owner will need this information when making decisions and therefore ultimately deciding where the project trade-offs will be.

Rule 10: ‘There are no good project managers — only lucky ones’.

 Anyone who has played golf will know that it’s an incredibly challenging sport. Not so much physically, but mentally, and it was Gary Player — one of the greatest ever golfers — who said ‘the more I practice, the luckier I get’.

Project Management is the same. As a project manager, you may consider yourself lucky when a project finishes on time, specification, and budget (or in fact any one of those!) but this is in large, due to the practice that you put in rather than any sort of luck.

It’s about the principles that you have applied and continue to apply, as well as the experience from previous projects that you leverage.

While no project will ever be risk-free, the risk can be substantially decreased and chances of success increased by simply applying the previous point.

Rule 11: ‘The more you plan the luckier you get’. 

This is very closely related to rule 10 and focuses in more detail on the importance of planning and other associated activities that a project manager should be doing. This includes risk management, budgetary controls, and managing customer expectations. The more time you spend on these, the better the project outcome.

More precisely — the more tools, techniques, and project controls that a project manager has at their disposal, combined with the understanding of whether or not these are required and why a conscious decision has been made either way — will ensure greater project success.

If a project manager really is lucky with the project achieving its objectives, he or she should probably question their value-add on the project anyway. What difference did they bring?

Rule 12: ‘Everyone asks for a strong project manager — when they get them they don’t want them’.

This is a highly debatable rule. Some people like working in a highly structured environment while others prefer to be left alone to get on with what they need to do. Unfortunately with freedom comes responsibility, and project team members that want the freedom without responsibility have a negative impact on both the project and balance of the project team. Often, these sorts of team members are a challenge to manage, and this requires a strong project manager.

Sometimes, however, it’s also the client that is difficult to manage. They insist on a strong project manager to ensure that the project objectives are met, yet at the same time are the biggest culprits when it comes to flying in the face of project governance. ‘Change requests — what change requests? Can’t you just squeeze this little bit extra in?’ There is an art here to turn a ‘No’ into a ‘yes — but’.