Failure and technology are two words that have become increasingly familiar in recent years. From the wildly popular FailCon – the annual conference where the tech community explores their failures – to the 41 million results that come back from Google when you type in, “why products fail”.
While failure has become an accepted part of technology’s lexicon, a question still hovers over why precisely does it happen so often? One of the biggest, according to research firm Forrester Consulting, is a mismatch between the expectations of those involved. As many as 40 per cent of companies cited in the firm’s research said problems arose because people couldn’t agree on key aspects of a product’s design or function.
The good news about this research means that human error, not the billions of lines of code or latency of your semi-conductors, can easily be tweaked to ensure your product gets to market. But where are these friction points and what can be done about them? Here we pick out the seven instances – and what to do about them – to ensure you never need utter the words failure and product in the same sentence again.
1. 11th Hour Swoop In
We’ve all experienced it. You’ve racked up 16-straight hours on a project to get it ready for the final push and one of the execs from upstairs swings by with their ‘changes.’ It’s a common problem in all product cycles, but the impact can be devastating.
How to combat: Previous research has shown the better the product development team members are connected to each other and to key external parties, the more successful the project is going to be. To solve this, communication channels must flow both up and down the teams involved. All teams need to understand key decisions made by other teams.
“Communication is not easy. Even in close, personal relationships, we forget to keep someone informed or communicate in a way that leads to misunderstanding,” says Bob Kustka, CEO of The Fusion Factor. “Communicating to multiple audiences in the corporate setting requires even more careful thought.”
When a project is beginning, ask yourself:
– How do the core teams collaborate with each other currently?
– Are there gaps in understanding and where does communication need to be improved?
– Is there a centralized hub containing all relevant information, updates and decisions for the various teams?
Agreeing on this before the project starts can eliminate the sudden changes from an exec at the last minute.
2. Missing Vault
This scenario arises when one member of your team holds all the insight and analysis the project requires to make it to the finish line. But, when all the power rests in one individual – if they are sick or go on vacation – what happens to the knowledge they possess?
How to combat: Before the project begins it’s important to have an easily accessible repository of who is involved in which aspects of the project and their level of expertise. Chances are there will be a combination of people on your project who could collectively plug the gap left by a missing vault persona.
Collaboration platforms are also effective to get the information out of an individual’s head and into the corporate network where it can be accessed by the team. With most projects, the ideas or the IP hold the real value, so companies risk having their progress come to a standstill when a single person is not available. Even if conversations are drifting onto email, they’re at risk of being locked away from other members of the team. So if a developer makes a critical change to a component of the project, the entire team receives a notification.
“Having a central repository allows anyone to go in and see these insights, find out who was involved and what changes have been made,” says Matt Mickle, a project management consultant at Jama Software.
3. Decision Recollection Disorder
A major stakeholder flies into town and wants you to walk you through the project thus far. But where are your notes on the decisions and iterations you took to get where the project is now?
How to combat: Consider this – when your team updates the product or project, where does that change get logged? If it’s a spreadsheet, it’s difficult to understand why decisions were made and there is the inevitable version control problem. The stakeholders in your project need traceability to review decisions made along the way, so any questions that arise can be dealt with in real time.
According to the Standish Group’s ‘Chaos Report’ the number one reason for project success was user involvement. The report also goes on to suggest meeting your stakeholders beforehand and ask them to identify other stakeholders so that you can identify where influence might come from during the project and keep them in the loop as decisions are being made.
CYA Syndrome
When a project runs into the trouble, people start looking for someone blame. The “cover your ass” phenomenon eliminates accountability at key stages in the project, resulting in a witch hunt, which can derail progress on the project.
How to combat: The best way to avoid CYA syndrome is to make decisions and changes totally transparent. Reviewing aspects of the product delivery process in the same place where those decisions are captured means the context for which decisions can be made would be readily available and obvious to the person reviewing.
This requires letting go of the typical command and control model, a management style invented for the military. “In a high tech company the individual contributors always have more information than the leaders, so they are really in the best position to make decisions. When the boss wanders into an office where two developers have been discussing the best way to build a feature, the person with the least information is the boss, so that’s the last person you’d want making a technical decision,” says Joel Spolsky, a co-founder of Trello.
5. Bridging the development understanding gap
Every project has a moment when teams divide into “us” and “them.” Translating business value being delivered into action for development can generate a lot of misunderstanding and confusion between the two teams.
How to combat: Giving developers or engineers a common vision or touchstone is key. They need a place to understand the overall experience the product is intended to provide before they’re tasked with the dev work. This helps to ensure things don’t get lost in translation. All parties need access to the conversations that take place when a project first gets off the ground. Customer input is also important because it shapes the opinions of the parties involved. Ask yourself:
- How do these parties collaboration and communication on an ongoing basis around a project?
- Do developers understand product concept and intended experience before dev work begins?
6. Inability to manage change effectively with stakeholders
If a project reaches an impasse and needs a change of direction, but the stakeholders don’t agree, how do you move forward? Roadblocks are sometimes inevitable in projects, but they don’t need to be with your stakeholders.
How to combat: Sending updates in a document or in meetings can make a change very easy to miss. The stakeholders don’t have an immediate opportunity to make their voices heard which can lead to frustration further down the line. Can stakeholders see feedback from customers, for example? Joining that space together allows those stakeholders to make better decisions about their aspect of the product journey.
7. Mismatched expectations
It’s the big reveal on the project. You, your stakeholders, dev team and marketing are all in the room. But when it comes to the big unveil, there is a definite disconnect between the expectations and the end result.
How to combat: At what point do all the different teams get to see and give feedback to the product development? It isn’t helpful to have a free-for-all at the time of product delivery. Rather, product teams need a forum for keeping different teams involved in the process and providing a platform for elicitation, approval and validation. Teams can’t operate in a silo, they need to be insync along the entire journey to keep everyone’s expectations in check.
A key aspect in managing expectations, says Johanna Rothman, a management consultant, is defining what “done” means before the project has started. “Release criteria are objective measurements of the critical attributes of the product or project. Listing and referring to the criteria allow you to know whether the product is ready to release.” Revisiting these requirements and expectations for the product throughout the process is key.
Read Next: 5 ways to tackle the complexity of your next big project
Get the TNW newsletter
Get the most important tech news in your inbox each week.
This post is brought to you by Jama Software – reinventing product delivery by changing how products are conceived, built and launched.
