Our CEO: His Name Is Murphy
As the thrill of finally finding a promising solution to our project management problems, reality rears its ugly head. Its form took the shape of our CEO. He burst into my office like the blast of wind before a storm. Eyes bulging. Gary, Jim and I stare into his wild eyes.
He says, “Gentlemen, sorry for the interruptions, but I need your help. I’ve got us into a bind and I need your help to find a way out.”
We say nothing, only stare. I notice he uses the word us.
He continues and says, “one of our once, biggest customers needs a system installed by Labor Day. That’s in about four weeks. They have a major event planned and need a lot of our advanced technology installed and running by then. As you know, they left us for a competitor a long time ago and this could be our way back in. You’ll have to work with R&D since some of the features we promised aren’t out the lab yet.”
Now, he’s using the word we. “That sounds like a good opportunity, we’ll give it our best shot,” I say. This is an impossible request. Demand, really.
“I’m sorry, but your best shot won’t be good enough. I hate to say this in front of the others, but our ability to keep our promises hasn’t been very good over the years. Pull out all the stops on this one. I’ll email you the contract we signed with this customer and I expect you to make it happen,” the CEO said.
With that, he turned and the air in the room followed him out. We continued to stare in stunned silence wondering when the air in the room would come back.
I apologized to Gary for the interruption. Jim wasn’t surprised, but I nodded his way anyway. But, our CEO made a promise and we’ve got to deliver, somehow. Part of my problem is agreeing to something before I know enough about it. But, promises had to be made to get the work, agree to the Labor Day weekend deadline, all at a price the customer was willing to pay. If I know our CEO, the margins will be razor thin.
The Situation
When I turned to look at my Inbox, there was a new email from our salesperson responsible for our once, biggest customer. Today was a good day to practice staring and I did some of it as I reached for my mouse. The weight sitting on my chest pressed down and forced me to breath. The click filled the room and I scanned the document which appeared.
We are indeed in deep trouble. The CEO made so many promises. So many pieces of hardware. Two prototype elements from R&D. New computer code. Standard hardware. All for delivery before the Labor Day weekend starts. Earlier than promised. I read out the highlights for Gary and Jim.
On the plus side, the selling price was good. It would help us make our quarterly target. But, the margin was not big enough to pay for overtime or expedited services. Later that day, I would find out how deep the hole we were in was.
The Minimum Project Pre-Planning Elements
As I turn to my side desk, I realize Gary is still here. He looks concerned and says, “I assume you are going to be very busy getting this project underway. But, I want to offer a quick, dirty and painless way to get this project up and running as soon as you can. It’s the perfect situation to show you another unique aspect of our critical chain approach. Depending on the scope of the project, I’m willing to bet we can have this project up and running in a few days. I’m willing to make a go of it if you are. What do you think?”
“Are you telling us you can gather this project’s requirements, plan the project, and launch it within a few days?” I ask.
“Not only that, the generic process that I have in mind can be tested in your environment. If this process helps, it can then be applied to the other projects you have in your portfolio. Two birds with one stone. The CEO may have brought you an opportunity, too, not a fire drill.”
When I walked into the office this morning, I was ready for the usual chaos. The time we spent with Gary helped us see a better way to manage projects. And, the CEO came in and pulled the run out from under us. Deflated. Again. I can’t help but take Gary up on his offer. It may be my only chance. Anyway, what do I have to lose. Things can get much worse.
“OK, let’s do it! What do you need?”
The Final Objective
“Before the formal project planning, we need to extract five things from your CEO’s project,” Gary says, “the pre-planning elements.” I’ll list them out, one by one, and you review the contract and let me know what you find. I’ll keep track on your white board. The first pre-planning element we need is the one, final goal this project is intended to achieve.”
As I scan through the document, I take a deep breath and zoom in on the scope section of the proposal. I tell Gary, write this down, “the vendor will buy 180 Model Z-10 surveillance cameras, two servers, video software and intermediate disk storage to support video streaming for the City of Dallas.”
Gary writes, but then turns and asks,”what benefits do they get once this system is installed?”
What does he mean benefits. We install custom surveillance systems, that’s what we are known for. I assume there are benefits, but that’s not our job. It’s the job of the customer to use our systems and get the benefits that want.
Gary says, “true, they are paying you for the hardware and software you provide. That comes at a cost. But, what is the cost of not having your hardware and software when they need it?”
Thinking for a minute, I say, “Good question. Like other cities we work with, they want to serve and protect the public and their officers, prevent law suits, and improve their reputation as a safe city. A safe city encourages home buying, jobs, and paying of taxes.”
“Do you think there is a difference between the price they pay for your system versus the price of not having your system?”
“Yes, there is a difference. The price of our system usually dwarfs the benefits that they get.”
“So, isn’t that the ultimate goal of these kind of projects? If so, we can make a conscious effort to include tasks in our project plan which support this worthy, but lofty, goal.”
Who Are the Customers
“The second pre-planning element we need is to list the specific internal and external customers of this project. These should include the folks who’s issues get resolved by installing the project.”
“Our immediate customer it the project manager for the City. But, right behind them is the police chief, the chief technology office for the City, and the representatives of the various community groups.”
Tangible Outputs
Gary writes some more on my white board and says, “Good, the third piece of pre-planning information we need are the tangible deliverables of the project. The key project outputs.”
I scan the contract and say, “the tangible deliverable is viewable video from 180 overt and covert cameras, hardware rack space, electrical power and network connectivity for the servers and storage devices, a failover link from City Hall to the Police Station, engineering drawings and documentation, and coordinated training of customer department monitoring staff. Oh, and we also have to deliver the data management strategy for 14 days of data storage.”
Major Inputs
“Oh, is that all,” Gary says through his grin, “but, let’s look a what we need for the fourth pre-planning element. What major inputs do you need for this project?”
“We need the network design parameters, bill of materials, status of in-stock parts, hardware build and delivery schedules, and signed outside contractor agreements.”
Planning for Risk Mitigation
Gary writes some more on the few places left on my white board and asks, “The last pre-planning element we need is to make some predictions about risk. The three main areas of risk we look into usually falling to the technical, schedule and budget risks. What about those? What could we do to mitigate them?”
“The reason I’m asking now is so we can enter tasks into the project plan to mitigate them. You know how Murphy works, if we put in mitigating tasks, there might not be a need for them. But, if we don’t put in mitigating tasks, we will, for sure, need them and then it will be too late.”
I chuckle at his wisdom. Murphy has taken up residence in our building and does have a habit of appearing when we least expect it. I say, “the technology risks lives in R&D and the two pieces of specialized hardware they need to provide. The budget risks are the usual ones about not going over budget and maintaining our margins. But, it’s the schedule risk, meeting the Labor Day weekend due date, that I’m worried about the most.”
“Let’s summarize the few, key things we need before starting to plan any project:
-
- Scope, goal(s), and key milestones––describe the project and its intended goals, including those that are important and measurable to the customer. Include any mandatory customer reviews, contractual milestones, or invoicing milestones.
- Internal and external customers––list those entities who’s needs get met and the issues which get resolved when the goal is achieved.
- Tangible deliverables––list the project outputs and define the required functional requirements.
- Major items needed as inputs––determine when the items will arrive, from whom, and what specifications they must meet before use.
- Technical, schedule and budget risks–identify the limitations imposed for each risk type.
“OK, that’s all the pre-planning element we needed. Since this is an important project, I would have your assistant type up these white board notes. And, then have your assistant send the document to all the internal and external customers and ask for their feedback ASAP. In the meantime, we can be working in parallel setting up the software and preparing for the project planning session.”
Next Steps
Finally, we will get to see the software. We have taken a different path to get here, that’s for damn sure.
It’s time for a quick coffee and a short break to clear my head. I’m going to need as the focus and energy I can muster. Things are moving faster already.