Rally the “Project Diamond” to the Rescue!
by Adele Sommers
Have you ever wished you could wave a magic wand to make your project sponsors, clients, managers, and team members agree on truly workable project criteria? Sometimes, the mix of high expectations, low budgets, and unattainable schedules makes it seem necessary to pull a rabbit out of a hat.
On too many occasions, we struggle silently to produce an illusion of success, too intimidated to raise red flags while feeling under extreme pressure to produce. In the worst case scenarios — which happen with increasing frequency in today’s complex world — Murphy’s Law strikes and disasters occur!
The story below illustrates just how difficult it is to handle several conspiring pitfalls at once. It’s a fictitious tale based on a real-world fiasco that could have been avoided with the help of the “project diamond.”
Read on, and then find out how to apply the project diamond in your situation to avert outcomes like these!
“So, How Hard Could It Be?”
 The eleventh of April registers as an infamous day in the life of Purple Star Software. It’s the day that Purple Star’s principal, Barbara M., reluctantly realizes that she and her primary client (her former employer, Ralph R., CEO of Halfdome Engineering) are both in deep trouble.
Barbara and Ralph have long been suffering from a ever-increasing case of scope creep.
Every week, Barbara had been asked to make changes and implement features in the software she was designing that were never spelled out in her contract.
Likewise, due to nonstop pressures from his own clients, Ralph made far too many promises that he and his team had no way of keeping. Always worried about losing the work, Ralph had agreed to include several complicated features to the product without:
1) Realistically estimating the complexity
2) Updating the contract with the latest requirements
3) Planning to develop the features over a feasible timeframe, or
4) Rigorously testing and delivering the components in stages.
The result? The clients finally shut down the project after seeing that Ralph and his crew couldn’t get the features to work.
At this point, Ralph’s clients are unlikely to pay for most of the effort to date. Poor Barbara, as Halfdome’s subcontractor, is caught in the middle of this big mess. She’s hoping the situation will be resolved soon so that she can recoup at least some of her outstanding invoices.
 Here’s what happened...
Ralph’s clients had truly believed that their project (a Web site for collecting and processing their products’ fabrication data) would be a piece of cake. They had never commissioned anything like it before, but simply thought that any halfway competent Web design group ought to be able to complete it quickly and easily.
After all, it looked simple. (How complicated could a Web site be?)
For his part, Ralph had agreed to take on a seemingly mundane project (but one that surfaced many complex features), at a high level of quality, for a rock-bottom price, on a very short timeline.
Little did Ralph and Barbara realize that it would be many times more complex than it seemed on the surface. After all, his team was skilled in designing and developing flashy marketing Web sites. But this particular site would need to:
- Interact with users
- Collect user data
- Verify the accuracy of the data
- Enter it into an elaborate database that his team would develop
- Process the data, and (this ultimately turned out to be the kicker...)
- Seamlessly send that data back into the clients’ ancient ordering system.
On the Web page itself, all anyone would ever see is just a simple-looking form. Underneath, however, there would need to be sophisticated rules and algorithms, plus a way to integrate the system with the clients’ byzantine order-fulfillment database.
It ultimately turned out to be impossible to do. In fact, the new system still was not working correctly when, months later, the frustrated clients called it to a halt.
The bottom line? Ralph had failed to do the following: collect enough information going in, realistically constrain his estimates, recognize and mitigate the risks, and simply decline an unachievable objective if he couldn’t fulfill it.
Whose fault was it?
 It would be very easy to blame one party or the other. But there was plenty of culpability to go around. Here’s why:
- The clients didn’t understand what they were asking for.
- They also insisted on a short schedule and a small budget that reflected their unrealistic view of the effort.
- They didn’t communicate an essential requirement — the integration with their ordering database — until well after the start of the project.
Ralph, on the other hand, had perceived this as a “must-win” project, even though it was clearly a poor fit for his in-house talents. This attitude blinded him to the trouble ahead. He scurried to find people who said they could do the work. But several collaborators he hired were complete unknowns and turned out to be total flakes.
Except for Barbara, the collaborators stretched the truth about their capabilities, and also were difficult to communicate with. Their handoff process showed early signs of trouble and set the stage for failure. The surprise requirements and underestimated difficulty quickly overcame the project.
What a painful series of lessons to learn!
How could the “project diamond” have helped?
The project diamond refers to four types of criteria that exist on every project — some of which
may have been implied on Ralph’s project rather than stated:
* Time (the speed or schedule for doing the
work)
* Cost (in terms of the funding, the resources,
or a combination)
* Quality (how well, and how robustly, the effort needed to be done)
* Features (how many components or deliverables
there were, and how complex)
It’s not unusual for project
sponsors or clients to ask for:
 1)
Low cost and
2) Fast completion and
3) High quality and
4) Many features in the final project deliverables.
Although
it’s understandable to want the greatest value
for the money, it’s usually possible to
achieve only two or three out of four of these
goals on a typical project.
For example, if both the budget and schedule are fixed, the tradeoffs will need to limit the quality, constrain
the features, or both.
So, how could the project diamond have helped to save Ralph’s project?
If Ralph had engaged his clients in a discussion about the project diamond early on, it could have helped him tackle the illusory assumptions with tough, pragmatic realism, before he allowed himself to be swallowed by hubris and overconfident denial.
The moral of this story...
If your sponsors or clients ask for everything under the sun, and you agree to deliver it without weighing the options, your project is at risk! Next time, try introducing the project diamond to your stakeholders, and invite a firm, candid discussion about how to apply the tradeoffs to accomplish your goals.
This story was adapted from a case study in “Business @ the Speed of Stupid” by Dan Burke and Alan Morrison. (See more below.)
Copyright 2022 Adele Sommers |
If there’s one thing we all should remind ourselves of at the start of a new project, it’s a need to thoroughly — even exhaustively — research the requirements on which we intend to embark.
That means that at one time or another, we are all struck by “Murphy’s Law,” a maxim that implies that whatever can go wrong will go wrong — especially on complex projects. 
