Technology projects, in their many forms, are a tricky subject. I've been involved in thousands of these projects at many levels. Some with small companies looking to improve their digital footprint, others with fortune 500 companies with complex developments. In both scenarios I witnessed successes and failures and learned a lot from fantastic professionals in the process. Today I'm putting some time to write this on what I believe is one of the most common areas of failure for digital products. My hope is that it can help people and companies in the planning and execution of their projects.
I've seen many times people obsess about the how of their projects. It's easy to see why that happens. People get attached to their projects and hope to make it the best it can be to their own eyes. I have certainly been guilty of this many times myself. That's where it starts. "I need to build a new CRM that can do this and that". While this kind of momentum is vital, I've seen a lot more success when the project is driven by business objective rather than a list of features. In fact, it is very common for the list of features to change throughout the execution of the project to reflect changing business goals. This is one of the reasons agile development was created. But this article is not about agile.
When a project begins to experience friction, it is rarely due to a technical deficit. In most cases, it is a symptom of a poor process. The tool begins to dictate the strategy, rather than the strategy defining the tool. This scenario usually leads to unnecessary complexity in the solution being built. Through that, we can experience scope creep and gold platting that will impact cost and time in the execution as well as the effectiveness of the tool itself.
To avoid this try shifting the perspective. Viewing technology not as the solution, but as the vehicle for a specific business outcome.
I first heard about the double diamond when I went back to school form my graduate degree. I was surprised by how simple and effective the concept was. Through time I started applying it and seeing it in action. If you haven't used it and you are experiencing things like what I describe above, I suggest you give it a try.
Think of the project lifecycle as two distinct phases. The first one is about building the right thing. The second one is about building the thing right. The second phase is just as important as the first one, but the second one by itself can take you to build a perfectly good hammer when what you need is a screwdriver.
In that first diamond the goal is to get really clear on the difference between a Business Requirement and a Software Feature. This is where the most successful projects separate themselves from the ones that struggle. Think of the requirement as the business need: We need our field team to spend less time on paperwork so they can see more customers. The feature is the technical answer: The app needs an offline-first sync capability. When we jump straight to the feature, we lose sight of the goal. I’ve found that if you document the why first, you create somewhat of a North Star that will keep your project in track. It helps keeping team focused when a flashy new vendor demo tries to pull the project in a different direction.
Between these two diamonds there is a step that is just as important: the Gap Analysis. It sounds a bit academic, but it’s really just an analytical pause. Before we start building, we look at the distance between where the business is now and where that why says it needs to be. Sometimes, we realize we don't need a massive new platform. Maybe we just need to fix a broken integration. This pause saves a lot of heartache, time, and budget later on.
The second diamond: Building the Thing Right. This is where the technical craft happens and where most people invest most of their time in. But even here, I’ve learned that technical excellence isn't enough on its own. A tool can be bug-free and run at lightning speed, but if the person on the other end finds it cumbersome or confusing, the project has failed its business objective. This phase has to be a marriage of technical requirements and usability. We have to keep asking if the tool we're building will actually serve the target user when the time comes.
Navigating these two phases is difficult to do from the inside. When you’re deep in the day-to-day operations, it’s hard to see your own organizational blind spots. If you feel that way it may be a good idea to get outside support. It's better to invest in extra muscle and increase the success rate of a project than launching a cheaper product that will add poor value to the user and the organization.
At the end of the day, my takeaway after years of doing this is pretty simple: technology should always serve the business, not the other way around. If we treat the software as the vehicle rather than the destination, the path to success becomes a lot clearer for everyone involved.
.svg)