Enough Time to Build It Wrong

Home > Research > Enough Time to Build It Wrong

Enough Time to Build It Wrong

Once again, we were in a workshop and common product delivery themes came out.

Because of contractual development, we don't have time to do it right.
We just push something else out there to meet the deadline.
With the amount of rework we do on every product, I can't believe we are still in business.
We know what it takes, but our leadership team doesn't care. They just want it done and think it should be easier.

The conclusion:

We have time to do it wrong and fix it several times later, but we aren't willing to take a fraction of that time to get most of it right the first time. Our research supports it. The average project ends up four times as large as the original forecast before the original business needs are met. Even though we've all experienced this, the 400% variance still surprises most people.

So, what are the causes and how do we fix it?

Build trust. Healthy organizations build trust and open communication so that teams can have crucial conversations up front.
Maintain an outcome orientation. Team focus should be on the goals and value, not the scope of features or changes. This allows more degrees of freedom to accomplish the goal when constraints are found. See our Rapidly Develop an IT Strategy and Build a Better Product Owner blueprints.
Leverage baseline requirements. Product teams need to establish a core repository of reusable requirements that serve as a baseline to determine impact and estimate changes needed to accomplish the goals.

It's the last one we want to focus on here as it relates to requirements management tools and gaining the most value from them. Managing product and project knowledge throughout the delivery and support lifecycle is critical to success. You must develop an integrated toolchain that supports your people and processes, not one that dictates your process.

Here are seven key practices that will reduce errors, rework, delivery variance, and failed implementations.

Take a product focus. Structure requirements based on the product or service, not the project scope. When you take a product focus, changes are steps that improve product maturity and value in your roadmap. Simply documenting what is changing misses constraints and dependencies and increases production support complexity.
Use the impact assessment. Most requirements management tools have an impact assessment tool. By selecting the process, entity, or requirements that are changing, the tool will flag all related areas that might be impacted. This is a fast and effective way for starting your effort estimation and a driving value for a dedicated requirements management tool.
Define your requirements approach. Plan how the team will define changes and impacts and agree to a schedule and priority. Analysis is just as important as any other development function and does more to reduce delivery cost later in the lifecycle. Aligning teams up front will ensure that dependent steps can be effectively aligned and managed. This also helps with iterative approaches to delivery so that teams know what sections are "Requirements - Done" and "Design - Ready". This is another advantage of a requirements platform. These tools can track status and approval at the requirement level or package groups of changes for easier review and implementation.
Define the level of detail. Agile does NOT mean no documentation, but the manifesto does call attention to the value of having the right level of documentation for the team. Use your requirements approach to define the level of detail needed to support design and testing. Consider that higher-risk or more-complex features may require more documentation.
Start with a context diagram. Business and system context diagrams are a visual map to ensure that the solution and impacts are clearly understood. In one case with a team I was advising, the group was concerned that it was going to take them three times as long as expected to build the solution. After working with the team to create their business, then system, context diagrams, the team discovered they were trying to solve the problem in the wrong area. Once they aligned the solution where it was most needed, they were able to complete the project in just two weeks.
Process flows are a BA’s best friend. With teams shifting to Agile methodologies, the user story has become the primary container for requirements. I still recommend focusing on your process flows first and use the process as a way to analyze and define your requirements. Take an iterative approach, aligning your decomposition to the backlog priority and level of detail the team needs. If your product or requirements management platform doesn't have process tools built in, look at extending them with a compatible tool (e.g. Draw.io Extends Confluence for Design).
Build quality checks into the entire process. Quality is not a verification step at the end of a cycle. It is a set of standards and goals built into every step in your process. Testing is just a mechanism to verify that the quality goals were met before the work moves forward. Think about Toyota's approach to defects: They don't fix defects, they fix the process that allowed a defect to occur (Build a Strong Foundation for Quality).

Want to Know More?

Build a Strong Approach to Business Requirements Gathering

Poor requirements are the number one reason that projects fail – take a strategic approach to optimizing requirements gathering in order to give the business what it needs.

Build a Strong Foundation for Quality