Allow Management to Dictate all Project Constraints
This may be the number two cause of project failures. (The number one cause is failure to properly define the problem being solved by the project.) There are many constraints on projects, but there are four primary ones. Three of them are the traditional triple constraints that everyone talks about: good, fast, and cheap. And we all know the rule, of the three, management can pick two but the third one will be dictated by the nature of the project itself.
When I began teaching project management seminars in the early 1980s, I recognized that there is a fourth constraint not mentioned, which is scope. In fact, scope creep is a significant cause of project overruns both in terms of budget and time. People keep adding “little things” to the project, not realizing that a lot of little things add up to a big change.
The best way to understand the constraints is with a triangle analogy, as shown in the figure. Time and Cost are clear. Performance is equivalent to “good,” using the common terms, or another way to understand it is that the project must achieve some kind of result, such as a bridge holding up a prescribed amount of weight, and if it won’t do that the performance target has not been met.
The one normally not included in the good, fast, cheap idea is Scope, which is a way of understanding the magnitude of the work to be done to complete the project. As things are added to the project, we say scope has creeped upward, as mentioned above.
Now imagine assigning values to all four of the variables. For example, we can dictate that the sides of the triangles have lengths of 3, 4, and 5. With height being 4 and the base being 3 units. The area of the triangle would be Scope, or ½ (3 x 4) or 6 units.
But management insists that the sides be 3, 4, and 5 units and the scope be 5. Well, it isn’t going to happen, no matter how much they may demand it, because it violates the rules for the relationship between the sides of a triangle and its area.
Schedule in More Detail Than You Can Manage
Before I explain this on, let me say that I’ve made most of these mistakes, which is one reason I’m qualified to tell you not to make them. And boy, did I get into trouble because of this one!
One of the projects I managed as an electrical engineer was the design of a high-frequency communications receiver. We were new to managing projects in a structured way, so we created a critical path schedule in increments of days. There were tasks that should take only a couple of days, but for many reasons we couldn’t get them done as scheduled. One reason is that we scheduled actual working time, which will almost always be shorter than throughput time. As an example, you may need to write a report that will take about two hours, but because of interruptions, needing to dig out some information for the report, and so on, it takes two days from start to completion of the report.
The problem is, your boss has looked at the schedule, which says it will take you two hours to do the task and she wonders why it took two days. Well, it didn’t take two days of working time, but it certainly did take two days of throughput time.
Which is what happened to me on the communications receiver project. We couldn’t control work to the nearest day, but our boss kept referring to the schedule and trashing us for being late.
I learned my lesson. I scheduled to the nearest day and published a schedule to the nearest week. That way I had a document that warned me that if I was going to meet a weekly schedule, I had to work hard on the small tasks that must be done during that week.
Try to Manage a Project and Simultaneously Do a Significant Part of the Work
This is commonly referred to as being a working project manager. It is the “kiss of death.” In any project the work always takes top priority, and managing the project comes in second. Unfortunately, on a large project this will get you into serious trouble, because failing to manage means you manage to fail, and at review time your boss is likely to say, “Your technical work was well done, but your management of the project was totally inadequate.”
Accept Scope, Performance, or Budget Changes without Requiring Approvals
First of all, changes to projects are a fact of life. People forget things. The world keeps on turning while you do the job, and things happening in the world require that changes be made to the project. For that reason, you can’t refuse to make changes, but you need to tell the client or sponsor what the impact will be to the project when those changes are incorporated. In that way, the client can make a decision to make the changes and accept the impact, not make the changes because the impact is unacceptable, or cancel the project because the changes are needed but the impact is unacceptable.
Without knowing the impact, that decision can’t be made, and at the end of the project, the client is going to be very unhappy, not to mention that the organization may suffer significant loss.
In addition, changes should be made only after approvals have been given under signature control. The reason for this is to protect all stakeholders to the project. For example, in a manufacturing organization, a change to a product design can cause a part kept in inventory to be obsolete or cause quantities purchased to change drastically, resulting in excess inventory that may have to be sold as scrap. Signature controls are absolutely essential to a well-managed project system.
Full-Speed Ahead, and Ignore the Risk
As Murphy’s Law says, “Whatever can go wrong will go wrong.” Things that can go wrong are called risks, and risk management is a very important component of a good project management system.
In assessing risks, we ask three questions:
1. What might go wrong (risk identification)
2. What is the probability that it might go wrong (probability assessment)
3. What will be the severity of the impact if the risk does happen (severity assessment)
4. What is our detection capability (before the risk occurs)
We generally assign a number from 1 to 10 for each of these, with the number designating the magnitude or probability, severity, or detection of each identified risk. In general, even when a risk has a very low probability of occurrence, if the impact will be very severe, the approach is to be cautious or even avoid the risk altogether.
A historic example of failing to follow this rule comes from the Challenger Space Shuttle disaster. The day of that launch the temperature dropped to around freezing, and there were seals in the rocket that had never been tested at such low temperatures. And while it was believed (by some of the team) that the probability of failure was low, the severity resulting from failure was to kill all of the astronauts, which is exactly what happened. Had the rule been followed, the launch would have been delayed until the environmental temperature was above the freezing mark. (There were a lot of reasons for this, which have been written about elsewhere.)
In Closing
There are definitely more than five things you shouldn’t do as a project manager, but these are so common that they may well rank near the top of the list.
Also, I am well aware that you may have to violate my rule because your boss tells you to go ahead and do one of them. If you do, take every step you can to protect yourself, have your resume updated just in case, and consider going to work for an organization that understands the reasons for not violating the rules.
Your boss may own your job, but you must own your career.
