Murphy Was an Optimist
If you are running a project, and things go wrong, who is to blame?
I know, we should not go around placing blame. Things happen. The rains come early. Heavy snow falls in October. The spring floods wash out the tracks. There are acts of God that happen to mess up any project.
Still, if you are the project manager for a project, and something goes wrong, who has to deal with the problem?
I have run many projects in my career: Analysis projects big and small. Strategy development projects. Transportation system projects. Software implementation projects. Property development projects. Distribution Center construction projects. Equipment installation projects. I have planned and managed the movement of offices, warehouses, factories, and assembly yards. I even ran a program that developed temporary distribution points for lumber; this program only operated for six months, and then disappeared.
About half of my projects involved picking up the pieces of a disaster, a train wreck that was FUBAR (Found Upside-down, Beyond All Recognition is the polite translation), over budget, and behind schedule, with morale so low that all the sad-sacks involved were shuffling about like zombies, or worse, running around like beheaded chickens. I get called to fix the wrecks, to get the projects back on track, and get them done as close to on time and on budget as possible.
So, I have run more than a few projects. I have run enough projects to have a fair idea of what works, what to pay attention to, and then what to do next.
What does it take to get a project right?
I think there are three elements that you have to make sure you have completely figured out and nailed into place before any of the real work starts, and then one ongoing activity at which you never let up.
The elements are:
The Plan
Dwight Eisenhower said in a speech during his last year as President of the US that plans are worthless, but planning is everything. This was for a man who planned, and planned, and planned some more. Most of Ike’s plans suffered the fate that Helmuth von Moltke the Elder had predicted 75 years before: “No plan survives first contact with the enemy, but Ike understood that the activity of planning helped prepare for variables and unknowns.
Planning is not just the effort of developing a single plan. That is just the first step. Once you have a plan, you have to pick it apart, look for the flaws, and assume that everything can and will go wrong. If something goes wrong, what options do you have to fix it? The true art of planning is the act of destroying your original plan to figure out what is wrong with it.
If you are not destroying your plan to make it stronger, you will have a failure on your hands.
The Budget
All projects cost money. The money is important. Not only do you have to figure out how much money you need to get the project done, but also how much money when. I have never had a project for which all the funds were available at the start. The timing of the delivery of the funds and the uninterrupted flow of the money are vital.
I recently worked on a project whose primary contractor was simply inept at making the money flow. The sub-contractors submitted pay applications and waited for the approval. It could take weeks to get approval, and then the 30 days on the invoice started. The subs never figured they would have to carry 60 – 90 days of payroll for hundreds of people, so they ran short on cash to pay the labor. Did the project finish on time? No. Perhaps the sub-contractors should have had a better line of credit to cover the load. Then again, perhaps the prime contractor should have been a bit more timely with the paperwork processing.
We hear of budget overruns on projects all the time, especially on government and public works contracts. We don’t hear about the budget overruns on the private sector jobs. Do private sector projects overrun their budgets? Of course they do, sometimes more spectacularly than government projects.
Money is the lubricant that makes the project run smoothly.
The People
I can’t stress how the right people can make the project almost a dream and how the wrong people will ensure that the project is a nightmare. When I get that rare privilege of being the HMFIC (Head Manager Firmly in Charge is the polite translation), I spend a great deal of time considering who I am going to fight to have on my project. Oh, all sorts of OK people will end up on the project, people I have little to no choice about. But when I am the dude who is Large and In Charge, I make it a point to pick key people I want on the team.
On several key projects for which I hired companies to provide conveyors, shelving systems, or high levels of automation, I made it a point to extensively interview the person the contractor wanted to manage their part of the work. If I did not think the guy or gal was up to the task, I told the contractor that I rejected their choice, and to present me a better candidate within a week, or I was going to cancel the contract and award the work to a different supplier.
Oh yeah, I do that kind of stuff. I even do it on projects that I inherit, the projects that have gone off the tracks and are in jeopardy. I have been known to take players from the field, to let them rest on the sidelines, rest in a remote location, or rest permanently away from the ball field. I don’t like to fire people, but I will if it is necessary for the project to succeed.
Getting the right people on the project is critical. Getting the wrong ones off the job is just as critical.
That Murphy Guy
You keep Mr. Murphy occupied with someone else. You know Murphy, the guy a bunch of laws are named after. If it can go wrong, it will. That is the Murphy I am talking about.
On every big project I remind the people I am leading that Murphy will arrive on the job site and will set up a shack as his base of operations. I tell my crews that our job is to keep Murphy in his shack. I don’t want to see evidence of him anywhere on the site.
The best way to keep Murphy at bay is to make sure that you have a contingency for everything. Assume that Murphy is an optimist; that he expects to find all sorts of ways to mess up the project. Your job is to make sure that he is profoundly disappointed because you did such a solid job with your planning that you figured out every place he could make mischief, and you removed his opportunities.
That won’t stop Murphy. He will keep at it. So you work with your people to look for the solutions to problems before the problems manifest. You make sure that you have alternate sources for the hardware that goes missing, or the motors that the truck driver dropped off the back of the trailer and broke. You make sure you have a way to get somebody in the home office to find a missing invoice and get a check cut today to make sure the labor stays on the job.
Our job, as project managers, is to keep that bastard Murphy in his little shack, bored, with nothing to do.
Keep the bastard in the shack.
More Articles on Project Management
To Err is Human. You Need a Computer to Really Mess it Up
The headline of this article is from a photocopy of a photocopy pinned above my old mainframe CRT back in 1986. Right next to it was the poster of the duck swinging a sledgehammer into the computer with the caption, "Hit Any Key to Continue."
The IT department that backs up operations at the Practitioners have struggled for the past week to recover a malcontent server. As of Friday the score was Bad Server 2, Developers 1. Our site was down for almost a full day while the techs executed an unplanned move to a new server system after the other one failed.
Here is some of the play by play:
@ 10:08 AM Friday:
We encountered some issues with the server when fixing the RDP issue, we are actively working with Amazon support to get the site back up as quickly as possible.
@ 4:43 PM:
Well, the site is back up, but without an SSL certificate at this point. Today was like a Lemony Snicket novel with your server. Here is some footage from our development department today:
Long story short, your dedicated server instance was corrupted. It kept throwing a BSOD on reboot, even the boys at our beloved Amazon were baffled. So we had move the site to a completely new and fresh server instance, which obviously took some doing. We had two guys on it most of the day.
NOTE: We were unable to transfer the SSL certificate over, so we’re going to have to ask you to get it reissued from your provider. I have attached the CSR from the new server that you will need in order to get the reissued certificate.
Long story … long: here is a rundown of what happened today:
- Attempted to run EC2Savior against root volume.
- Ec2Savior successfully ran, but when the system would not boot back up …
- Contacted Amazon support.
- Amazon support monitored the instance and found that it was blue screening.
- Attached root volume to a different instance and ran chkdisk against it. Errors were found and corrected.
- ChkDsk took several hours to run.
- After DhkDsk finished, volume was reattached to instance. BSOD was still happening.
- Amazon suggested either using their dev team to investigate — which could take an unknown amount of time — or spinning up a new box. Since we had the data, I chose to spin up a new box.
- Configuration of the new box took most of the afternoon.
Again, I apologize for the downtime today. The decision was on me to go for it without a planned maintenance window … lesson learned. Whenever can get the SSL certificate to us, we’ll get it installed as soon as we can.
Whew!
On a Friday, leading into the long weekend. Sodd's law was in full effect. We still have issues, and things are not running quite right on the back end. In fact, this post is one test I am conducting to see if we can even post. I called down to engineering to ask Mr. Scott if he could do anything. The report I got back was interesting:
Snotty: Sir, the warp drive mechanisms are generating excess
anti-matter. The pods are overloading. If it continues at this
rate, I cannot be responsible for the safety of the ship!
Jerk: Don't have a SPAZ Snotty!
Snotty: AH! But the whole ship's gonna blow isself to pieces
Jim!
Jerk: I WANT ANSWERS MISTER!
Snotty: Well, I tried shoving a weiner in the warp drive, but it dinnt do a bit o' good...
By-the-by, would you happen to have a wee bit of mustard up on
the bridge?
Jerk: Mr. Schlock?
Schlock: No mustard, Captain.
Jerk: Analysis Schlock?
Schlock: It would appear that Lieutenant Snot is about to eat a weiner
without mustard.
H/T to
Bobby Picket
Worst Possible Set of Circumstances
Last year I had the privilege of working on a project on which every day another set of undesired outcomes appeared. This was a hell of a project. Over budget and behind schedule, it was easy to identify the symptoms of what did go wrong. The root causes were harder to identify.
Staffing was not a problem. There was an abundance of people working on the project. At some points, over 250 people were toiling in the 250,000 square feet of space. There was ample management and supervision, with over 26 managers and supervisors from seven different companies. There were ample detailed drawings. There was a project schedule, which was also quite detailed.
Still, despite all these resources, this was a project on which Murphy’s Law ruled the day.
Asked to describe the project by a fellow member of the Association of Professional Material Handing Consultants (APMHC), I said “After Murphy decided to set up camp on the site, he sent for the entire Murphy clan to come and visit, including his cousin Sod from the UK.”
Sod’s law?
Murphy’s Law: Anything that can go wrong, will go wrong.
Sod’s law: If something can go wrong, it will, at the worst possible time.
The actual Edward Murphy did not even coin the phrase we know today. To be sure, Sod is not optimistic either.
There are many stories behind Murphy’s Law, and enough documentation to support the story that there really was a Murphy. The truth, however, is that Murphy never really recorded the law; it was other engineers working on Project MX981 who recorded what Murphy actually said when he placed the blame for a failed strap transducer on a junior technician; he said that if there were a way for the guy to do something wrong, that is the way he would do it.
The engineering team testing the rocket sleds at the then Muroc Army Air Force Base in 1947 remembered what Murphy had said. Murphy was there for only a few days, and after he left, testing continued as the Project MX981 team attempted to learn about how much G force the human body could withstand. Murphy was miffed that the sensors had been installed wrong, but the rest of the team took it as just another lesson. When something went wrong, the team distributed their findings to everyone else in the program. At the line traveled, it morphed from a line of blame into a line of knowledge, from “if there’s any way they can do it wrong, they will’ into the more demonstrative “if anything can go wrong, it will.”
The idea became a law with a quip by the Project MX981 leader, John Paul Stapp. In a press conference after the initial tests, Stapp attempted to explain his research in clinical terms. When a reporter asked, “How is it that no one has been severely injured, or worse?” Stapp, replied nonchalantly, “We do all of our work in consideration of Murphy’s Law.” When asked for clarification, Stapp explained that you had to think through all possibilities before doing a test, in order to avoid disaster.
Last week I said that Murphy was an optimist. He wasn’t. Murphy looked at the glass as always half empty. Actually, Dr. John Paul Stapp was the optimist. He was also the fastest man on earth for a while, and a test dummy. In order to be willing to sit in the seat of the rocket sled and put his body through the incredible forces of sudden acceleration and deceleration, Stapp had to be an optimist. He was not a blind optimist, however; he and his team worked to ensure that they kept fatal failure a remote possibility.
Sooner or later, the worst possible set of circumstances is bound to occur
Years ago, when the data did not provide the answers that an executive of the company wanted to see, he told us to collect more data, and to keep collecting data until we found proof that he could use. Thankfully, my boss intervened, using the Law of Truly Large Numbers to highlight that while it was statistically possible for us to find a shred of evidence that supported the executive’s idea, that we would find thousands of examples that proved the idea was wrong.
I like to call it the Blind Squirrel Rule: Eventually, the blind squirrel does find the nut.
Finding the nut is a positive thing, if you are the blind squirrel. However, in project management, you don’t want the squirrel to find the nut. Hell, you don’t want the squirrel to even have the most remote opportunity to finding anything.
Diligent project managers, create The Plan, define The Budget, and work to get the Right People on the project. Following that process, they engage the team to look for the failures—the probable, possible, and remote opportunities for failure to happen. Effective project managers are not afraid of failure; they work hard to control the impact failure has on the project.
Ineffective
Even good people can be rendered ineffective. I have seen talented leaders lose control of a situation and fail. When the right combination of unplanned and unexpected circumstances comes together, even the best can get nailed.
There is such a thing as innocent failure. But like the nut the blind squirrel finds, the innocent failure is a rare event.
Call Us! 877-674-7495 info@dksco1.com