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.
Microsoft will end Support for Office 2010 on October 13, 2020. It’s now time to think hard about your next steps and put together an upgrade plan to a newer version, like Office 365 Pro+ or Office 365.
Tools alone don’t make great requirements. Requirements are a team sport and the team must collectively own and commit to delivering them for BizDevOps to be successful.
Companies that support customers through tough times build stronger relationships and loyalty. Develop a deeper understanding of the opportunities and threats facing your customers to shift products and services to address these needs.
“Being Agile” enables the delivery of the right value at the right time. When most people talk about delivering the right value at the right time, they think about the core technical skills required in the action of delivering software. This is only part of the Agile software delivery pie.
Centric Software launched Quick-Start Collaboration Packages to enable brands, retailers, and manufacturers to rapidly adopt remote work processes across the product lifecycle.
Micro Focus ALM Octane manages the quality and test management of application portfolios at enterprise scale and offers visibility and traceability across the SDLC.
Agile skills require an evolution in people’s soft skills and behaviors. Handling ambiguity, being agreeable, and being extroverted are some of what’s important for an effective agile team.
IIBA understands that it must continue to innovate to serve its members and help them succeed within their organizations.
Platform product owners struggle to develop a product roadmap and prioritize backlog items when their system supports multiple external products across business lines.