Learn from failure

Imagine a new product being contracted out for delivery with an investment value of over $5 million. The target market launch is two years out, and the complexity is relatively high—the product is something the company has not built before. As expected, the business requires a fixed-bid statement of work that documents (at a high level of fidelity) deliverables for each phase of the project.

The Agile Manifesto explicitly states the value of working software over comprehensive documentation, but that’s hardly going to help with a siloed organizational structure where IT and business don’t see eye to eye. Business is interested in seeing the value generated match or exceed the dollars spent on the product. Software that only delivers 75 percent of the promised value at 100 percent of the cost is a problem; 50 percent of the value at 200 percent is a catastrophe. Yet these numbers are not rare in the industry. IT, on the other hand, are given orders and need to meet the specification provided by the business. Here’s where the system breaks down.

Failure 1: Siloed organizational structure

Business defines requirements and budget; IT handles the implementation. Design (or User Experience) is often an isolated department that is injected between business and IT. When expectations are not met by IT, safeguards are erected by the business and trust erodes.

The business plans new digital products based on assumptions and annual funding cycles and locks in requirements ahead of time. IT is required to deliver on fixed requirements in isolation, without involving the end user in the process. Delivery timelines of more than a year are common—with minimum learning along the way. Risk continues to mount as teams are working in isolation based on a lot of assumptions made during the research phase of the project.

The design team is tasked with creating wireframes and the UI of the product, resulting in an artifact that is close to four hundred interactive screens. Design decisions made up front become detrimental to success as they cannot be tested or validated with users. Once the design is complete, the team is deallocated, and the funds for this phase are exhausted. There is no room to go back and refine.

Another side effect is that design decisions made without consultation with engineering may have high architectural costs—something that could have been completely avoided through a collaborative workflow. The same can be said for quality assurance. An external QA team often focuses on a costly brute-force testing strategy instead of becoming a strategic partner in the cross-functional team and designing a defect-prevention strategy (working on the source of the problem, not the symptoms).

Delayed releases and mounting costs continue to erode trust between IT and business, resulting in a combative climate that makes everyone’s work harder than it should be.

Recommended approach

• Create an organizational structure that integrates all disciplines into a single team (often led by a chief product officer). Allow the team to own the business outcomes versus the requirements. Smart people can make decisions on their own.
• Build a stable cross-functional team with the core disciplines of product management, product design, software engineering (testing, development), and support from DevOps, security, and compliance. Empower the team to own the results.
• Establish clear business outcomes that the product team needs to hit, not requirements. Outcomes should be specific, measurable, and achievable.

Failure 2: Detailed requirements over team collaboration

Most unmet expectations result from lack of trust early on that results in requirements being collected by an analyst and locked in before the project kicks off.

Throughout delivery, the developers then attempt to align the product to the documentation created, even under circumstances where the needs change. In such instances, change requests are issued and signed, rework is completed, the budget keeps increasing, and timelines keep slipping—the exact opposite outcome from the original intent of reducing risk through documentation. Once the product enters testing at the end of the project, all sorts of nasty bugs, issues, and problems arise. When the stakeholders actually see it for the first time, it’s not what they thought they would get.

The question is, Why?

• Requirements imply design. Specifications often dictate solution design, yet not a single individual from the product team (such as a product designer, product manager, or engineer) has any input.
• Complexity cripples understanding. Large, complex systems are challenging (and pointless) to document thoroughly. A burdensome quantity of documentation creates an environment where the product team has no easy way to assimilate the information in the specifications.
• Paralysis through analysis. The project experiences significant delays as the analyst continues to discover edge cases. It’s a never-ending story—the deeper you dive into defining the solution, the more you discover, the more you need to capture, and the more you need to maintain. FYI: This is why the software industry has moved away from hard documentation and into “living requirements” through self-documenting code, user stories in Jira, and knowledge bases in Confluence.
• Biased requirements. Throughout the collection of requirements, needs are heavily biased toward the party being interviewed. For example, in a system where there are internal users as well as external customers, assumptions are made daily about “what the customer needs,” yet customers are never consulted.

Recommended approach

• Use Lean Requirements, roles, and user workflows to shorten time to start.
• Facilitate a workshop to build a shared understanding.
• Leverage research along the way to test assumptions and reduce bias.
• Demonstrate value through working software and user acceptance—not documentation.

Failure 3: Noniterative process

Project managers operating in waterfall do not have control over the definition of the deliverable—that was the job of the analysts who wrote the requirements. The users of the product are not involved in defining the solution.

Project managers typically report to the technology organization that builds the solution, so their allegiance is not necessary to the client who receives the end product. They’re likely to unintentionally shift the blame to clients for expanding the scope, providing incorrect requirements, or changing their minds. Project managers don’t have ownership.

Because a working product is only revealed at the end of the project, users and stakeholders have no way to provide meaningful feedback until it is too late. Stakeholders and customers also don’t have ownership. Without user involvement, nobody on the client side feels committed to a system—and can even be hostile to it. Classical project management leads to a lot of finger-pointing, exceeded budgets, and underdelivered value, even when all members of the team have the best intentions.

Waterfall delivery only ships a working product at the end of the project when the funds and time have been exhausted. There is no way to build iteratively, test with the target audience, and refine the product along the way.

Recommended approach

• Orchestration of delivery should be facilitated by a product manager/owner who retains ultimate control over the product (ownership).
• Individual team members should be allowed to fail, thereby increasing ownership and opportunities for members to “step up.”
• Sponsors and key stakeholders should be established and required to sign off on acceptance after delivery.
• Users should be involved in defining the product and providing feedback.
• The product should be built using some type of Agile methodology that allows the build-measure-learn loop to operate.