My Project is Killing Me – 7 Rules of Thumb for The Savvy Project Manager

Philip Henslowe: The natural condition is one of the insurmountable obstacles on the road to imminent disaster.

Hugh Fennyman: So, what do we do?
Philip Henslowe: Nothing.

I suspect that project management is considered by many a respected and cozy profession backed by formal training and which sells executives the idea of projects as a predictable, controllable, manageable aspect of company life. However, this sounds to me like a gray and boring view of a profession which is instead exciting, engaging and risk-prone but is rewarding for those that can sort out challenges with great achievements. Project managers are not clerks wearing a tie while using Excel and giggling for their certification plaque on the wall. They are rather pirates trying to board the ship of opportunities by doing something that nobody in the company had dared to do beforehand.

I started some time ago writing few rules of thumbs for my sake; then I realized that I am too modest and too science minded to claim them as rules. Let’s call them conjectures or lesson learned. During my career, I have been appointed as an engineer, scientist, task leader, work package leader, project leader, program head. Since the beginning, I was more interested in building new stuff rather than keeping well-lubricated wheels running. This brought me into the exciting and sometimes disadvantaged business of projects.

1. A Project Must Deal with No More Than One Serious Challenge

Only dealing with one serious challenge to the project at a time comes from common sense, but it also has a mathematical foundation. A project must focus on a tangible, measurable, and potentially achievable objective. Not two, no more than one. Let’s see why. If we have a plan with many unrelated challenges which don’t depend on one another, then our project is not a project, but rather it is a set of independent projects. Those simply executed projects are in parallel by separate workforces, or maybe with some workforce overlapping, and run merely as siblings inside a program. On the other extreme, if a risky work package is gated by another running in parallel we should ask why we want to run such a huge risk: one failure kills all. A project cannot afford more than one category of risk. If you think you can invent something, then implement it and finally sell it in the same project, you are running too many risks. Stop, restart from the foundations, secure one outcome and propose a follow up if the business justification is strong.

2. A Project is Behind the Schedule the Very Moment It Starts

Time zero and we are already late? Yes, it seems an exaggeration, but it is not. Every project must entail a quirk of uncertainty that makes every single second left behind potentially a source of devastating nonlinear impact on the schedule. We have a plan, but it sounds meaningless, it is good just for the proposal time not for the staff that must do things. There are so many missing parts. Do our partners share the same vision? If you feel this pressure, in the beginning, it is because you are a good project manager. A good 90% of the work done on a project is in the first 50% of the project time. It is quite likely that the remaining 10% of the work that takes infinite time. However, remember, good is better than perfect. Sell your results when they are decent.

3. A Project Manager Is Not a Manager.

He is not the guy sitting in the leather chair acquainted with the C-level executives. He is not the one who envisions the strategy, hires the staff, sends the commands and collects the results. A project manager is a person that feels the pressure on his shoulders because must get the things done. Don’t be surprised if the star engineer in the team earns much more than you and does not seem to be to too concerned a lot of the time. Higher pay does not equate to more worried.

4. The Value of a Project is Inversely Proportional to the Length of Reporting

This is a bit biased from my previous experiences. I have seen great stuff produced with very low paperwork around. On the other end of the spectrum, the very little value buried in thousands of Microsoft Word pages. When a project team has little or no value in their hands, it tends to put a rigorous and heavyweight process in place. Nobody cares if you used the wrong template if the impact of your work is great.

5. A Project with No Major Deviations is Lying Somewhere

A project is a venture towards objectives never achieved before in a company. It is just unrealistic that a project can go as planned from start to end. This means that nobody is checking the value produced, or the project is not a project, but it is rather business as usual. Our plans are based on assumptions. Our assumptions are based on models, but although models are useful, they are not always accurate.

6. Complex ≠ Complicated.

Despite what the dictionary says, you can make predictions on the complicated part but not on the complex one. Often, I hear about “complexity” management or about engineering as the art of manage complexity. However, I think we should rewrite the concept of complexity borrowing from complex system theory and separate what is complex from what is complicated.

Complications are always there even in no challenging tasks. Complicated project deliverables divided into less complicated project deliverables results in easily managing the complication. The time associated with any small part is known, the risk predictable and the contingency plan effective. Complex things are different. They impact each other in a chain reaction, and no part can be managed separated from the whole. They are complex because they are interrelated, and often, but not always, they come from the human factors in a project. One failure causes nonlinear effects, and the risk cannot be calculated beforehand, and contingency plans are meaningless. So, the only thing to do is being prepared to manage complexity with a human touch and prompt reaction. Negotiation, psychology, business acumen and ability to read the reality are the skills needed to cope with that. Here is where the project manager will shine (or sink).

7. Project Lead ≠ Project Proponent Leads to Uhm – Disaster

Some readers will question this point. I know there are many companies who work this way. Specialized staff interprets the company strategy and generates project proposals, and another team is charged with the work of getting things done. Unfortunately, there is a dispersion of vision and motivation in this separation that makes things going horribly wrong. In my experience, the best projects are proposed and run by the same team with the full endorsement of C-level executives from the beginning.