I know you’re out there. I know that you’re afraid of change. I don’t know the future. I didn’t come here to tell you how this is going to end. I came here to tell you how it’s going to begin.– Neo, The Matrix
Bright Wolf designs and builds industrial IoT systems for Fortune 500 companies, and over the past decade we have collaborated with clients on all kinds of projects. Most have met or exceeded their intended goals, and provided their desired outcomes.
But there’s a particular style of project that we will no longer engage on. We’ve come to call it the “$3 Million Spreadsheet” and we’re sad to admit we ever built a single one. Now, we want to share what we learned with you.
A fatal pact
Here’s the setup. It happens every day hundreds of times across the world, and it goes something like this… The client believes they have a great idea for a new system, and they desperately want to make it real. The project owners put together some ROI projections and obtain permission to proceed, usually through a formal stage gate and budget approval process. Next, they approach a consulting firm to assist with development. As part of their evaluation, the consultants ask probing questions about the business value of the proposed solution. They want to understand the problem more fully, and learn how priorities have been assessed.
The project owners quickly remind them the corporate stage gate is complete, the “voice of the customer” exercise has been completed, and the project is approved as specified. It’s time to build. The tone of the client has an air of, “mind your own business, we’re the experts here.” Eager to begin, and with each party believing their ‘process’ has been dutifully followed, everybody agrees to proceed.
We had begun other projects under similar terms, and they had all worked out well. Some were quite amazing. However, we’ve all seen the data on the dismal overall success rate of enterprise software projects, and eventually, the statistics caught up with us. This is the story of what went wrong, what we did about it, and what you can learn from it.
A lesson to learn
From the beginning, our client (we’ll call them “Acme Industries”) is pleased with our rapid delivery of page after page of specified features, along with their regular stream of new change requests. Following a year of development, the system is successfully installed at several pilot sites. Technically, it works great, gathering data and doing analytics, connecting to other systems and providing mobile and web-based alerts and diagnostics… everything is going according to plan.
Here’s the catch. The solution was specified entirely by Acme engineers. Features were defined and prioritized using their waterfall tollgate methodology. Unfortunately, it turned out that actual customer input on their specification was minimal. One year after the pilots are installed, it is painfully clear that the value perceived by their end users remains low. Soon, they cancel the entire project. Software and hardware recalled from the field. Systems are shut down. Done. Over.
Of course, somebody has to take the fall for this. It becomes obvious that it will be us… and one day we receive the formal letter. We’re out. Years of relationship and technology development down the drain.
Immediately, we’re plunged deep in thought and debate about what caused the failure. Where did we go wrong? What could or should we have done, and when? Could we have made Acme’s field trials more successful? We started breaking down timelines of the entire relationship, looking for clues and doing a complete tear-down of the relationship and the project.
At the beginning of the project, our lead technologist had commented how much of the value in the spec might be delivered more simply, and tested for customer results, with a spreadsheet. But Acme had insisted their process stage was approved and the next deliverable must be a software solution.
We start cross-checking against our other projects to add to the data we’re gathering. We analyze and codify the information into categories, rules, and techniques over several months. We deconstruct every project we had ever done looking for common themes, for markers signaling long-term success or failure.
Forming the DSP
We discern several underlying truths of our world, developing a framework for ensuring project success going forward. We call it the Digital Success Plan, or DSP, and are excited to implement its 7 core elements with both new and existing clients.
The DSP captures best practices around central success requirements such as: the vision and goals for the project, the methodology, the “iron triangle” of time, scope, and budget, and well-defined roles and responsibilities. It provides a core set of guidelines and principles, identifies the key attributes of a successful project.
Surviving first contact
At this point, we’re excited to put the DSP into action. Soon, it becomes clear that another client (we’ll call them “Cyberdyne Systems”) has an ongoing project bearing a striking resemblance to the Acme undertaking. Adamant to avoid delivering a second $3 million spreadsheet, we set about saving them with the DSP.
It’s a train wreck. The project owners have no interest in rehashing why the project exists, or redirecting it toward market value. At first, they humor us with discussions. But when it’s clear that we’re proposing change, they dig in, becoming defensive and almost angry. “We have the requirements!” (They really didn’t.) “We have our process!” (True, but it’s for incrementally improving hardware offerings, not for disrupting an industry.) And finally, “We’re past the ROI tollgate and we have the budget!” (Yes, but we could deliver a more impactful solution for less!)
Through our probing, we learn that in fact nobody at Cyberdyne can truly justify the business value of the initiative. The entire project is in jeopardy. In an effort to save it, we meet with their executive team to share our concerns, along with learnings and ideas from the experience with Acme and our larger historical project analysis. When we finish, the CEO looks at us in evident distress and says softly “Why didn’t you tell me sooner? Why didn’t you sound the alarm?” We know what we have to do.
A new hope
Meanwhile, we continue to attract new clients, and these project owners prove willing to engage with us at a planning, strategy, and design level ahead of writing any code. But then a new prospect (we’ll call them “Globex”) contacts us, moving the conversation quickly toward dates and deliverables. Usually that’s good news. But with growing dread, we recognize that Globex’s initial interactions with us looking very much like both the Acme project and the troubled Cyberdyne engagement. They have a large requirements document and the budget to match. They’re ready to go. All they want now is our development proposal and we’ll be off to the races.
It’s time to put our hard-won lessons into action. Rather than sending the requested proposal to build the software, we instead offer to spend a day together to discuss the project more deeply with them. We want to learn more about their company and their vision, as well as their unique motivations and constraints. Not just “What,” but more critically, “Why?” We’re expecting to hear “no thanks, we have it all figured out, and if you don’t want to build it we’ll just work with somebody else.” Instead, Globex accepts our suggestion, and sets a date to meet, just four days away.
We need a montage
We knew the Digital Success Plan was technically correct. Yet the Cyberdyne project owners had rejected its application to their struggling project. So we set to work again to figure out why. Soon, we realize the DSP is first and foremost a set of great questions. However, it lacks both action and empathy. It is “right,” but not compelling. At its core, however, we discover the inspiration that had been buried out of sight by the process.
We’re definitely on to something, but are unsure how to express these universal truths in a way that meets our clients where they are today, and helps guide their journey to a new place. How do we prevent anybody else from ever building another $3 million spreadsheet?
We gather our team together for another round of intensive discovery. We build on foundational work from some of heroes. Steve Blank’s Four Steps to the Epiphany; the Agile movement; Geoffrey Moore’s thoughts on Disruptive vs Sustaining Innovation; our own deep convictions about the importance of design, continuous improvement, and simplicity.
Finally, after deconstructing everything again, the core of Zero Waste Engineering emerges.
Have fun storming the castle
Our team members for the Globex meeting head out toward the client’s HQ in another part of the country. We know what needs doing, but the presentation still lacks the clarity we seek. We can feel what Zero Waste Engineering (“ZeroWE” for short) means, but aren’t yet satisfied with our ability to share it with others. The meeting is tomorrow.
Our team members are still wrestling with the need to simplify the approach, to distill it. Finally, in a moment of clarity that can only come from months of intense discovery and failures, the principles of Zero Waste Engineering appear. In the end, it’s not about requirements or ROI at all. Nor is the focus on products or the project. At its core, ZeroWE is all about the people.
Principles of ZeroWE
1. Design for learning
Every activity should either validate an assumption or generate data to aid in future decision-making. Design each aspect of your initiative for learning, and harvest those learnings for continuous improvement.
2. Conspire with your customers
Steve Blank speaks of customer discovery. We prefer to think of it as value discovery. Bringing your customers into the conspiracy to create value early ensures that you’re on the right track.
3. Build a coalition
Change is hard. This isn’t just the next version of your product or a bolt-on thing for your market. This is the first step in a fundamental shift. You’ll need a committed internal group representing engineering, product management, IT, finance, and sales.
4. Align effort to value
No more $3 million spreadsheets! What’s the smallest amount of work that can be done to validate the value hypothesis? Can we do it with a clipboard and a calculator? Do we need software yet? Don’t cost-reduce the solution until you’ve proven that people will not just use it, but pay for it as well.
The next day, the team meets with Globex project owners and stakeholders, and explains the principles of ZeroWE. Furthermore, they encourage the team to remain flexible about the implementation details as long as these principles are upheld. Globex agrees, and the rest is history.
The future is now
Over the course of time since we adopted ZeroWE, we’ve seen tremendous results. Our fantastic clients continue to extend domination of their markets through this disruptive period. Their stories are still being written, and I can’t tell you how they’re going to end. What I can tell you, however, is how yours should begin.
Begin with ZeroWE.