Comprehensive software reviews to make better IT decisions
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.
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?
- 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.
- Drive product satisfaction by validating and verifying quality throughout your delivery pipeline.
- Improve collaboration and transparency with the business to minimize project failure.
- Stop delivering projects. Start delivering products.
- Create a roadmap that suits your objectives, the characteristics of your product, and the environment it lives in.
- The quality of your product backlog is key to realizing the benefits of Agile.
- Strengthen the product owner role in your organization by focusing on core capabilities and proper alignment.
- Streamline business value delivery through the strategic adoption of DevOps practices.
- Further the benefits of Agile by extending a scaled Agile framework to the business.
Traditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure dollars on the table.
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
So you’ve gone Agile. You do daily scrums, retrospectives, and all the “right” Agile ceremonies. But still your organization isn’t quite convinced. It is now critical to balance the drivers and goals of both Agile and traditional thinking in order to achieve organizational success.
Do you feel like your Agile teams are treading water – going through the motions but never going anywhere? It’s a risk, and practices such as daily standups, retrospectives, and demonstrations need to be used wisely or you risk losing discipline to meeting fatigue.
Stakeholders expect the speed and responsiveness of product delivery does not come at the expense of quality. QA tools offer retailers the ability to continuously ensure both business and technical quality standards are upheld, but these tools should not be viewed as a silver bullet.
When trying to implement Agile as a defined process, Scrum turned BAs or other roles into order takers with the title “product owner.” This undermines the entire value proposition of product management.
No matter how good your product roadmap and backlog are, they are only as good as your audience’s ability to understand your vision and priority.
The scrum master is like the conductor of an orchestra, ensuring that every piece fits together at the right time to create something greater than the sum of the parts. You don’t have to know how to play each instrument, but you do have to understand what each part contributes to the overall masterpiece.
Tools are important to product teams, but only when they support solid people and processes.