In our previous blog on Dual-Track Agile, John Parker described the benefits of this emerging concept. Dual-track agile is an approach to agile development in which project teams are constantly working on the discovery and delivery of solutions that will deliver business value and obtain user adoption. By following the principles of dual-track agile, project managers and their teams can eliminate a lot of frustration and costs in agile development. Below are the key guidelines to implementing dual-track agile in your projects.
1. Put together a proficient discovery team with expert capabilities who are able to blend entrepreneurial skills and research gathered from the market. Your team needs to have the following skills so they can thoroughly and effectively understand the problem, recommend the best solution, and align the project with business needs:
- User Experience/User-Centered Design
- Business Analysis
- Pricing and Financial Analysis
- Customer Discovery
- Impact/Gap Analysis
- Focus on Collaboration
- Experimentation Attitude
2. Have the discovery team working one or more months ahead of the development team. The discovery team should be constantly populating the backlog with validated ideas and user stories.
3. With the help of the discovery team, create an understanding of your customers’ core problem before gathering ideas/features. Do not start putting together a solution until you have a complete understanding of the problem. Use Root Cause Analysis techniques like Fishbone Diagrams or The Five Whys to dig deep into the source of the problem and set the context for the project.
4. Develop a shared vision by hosting a vision planning workshop. Invite the product owner, business stakeholders, technical subject matter experts (SMEs), user-centered designers, and customer representatives. Before the end of the meeting, ensure everyone understands the problem or opportunity and why it is important.
5. Develop a clear set of business objectives for the project to ensure the delivered solution achieves critical business outcomes laid out in the vision. Once ideas or features are documented, business objectives will be referred to for validation. All features must align with business objectives.
6. Do not allow user stories to be defined until ideas/features are fully documented and validated.
7. With the guidance of user-centered design specialists, validate ideas/features to ensure they meet business needs and eliminate low-value features. With the help of business stakeholders, customer representatives, and technical SMEs, validate that each feature is:
- Prioritized Correctly
8. For every validated feature, develop a complete set of user stories. Make sure your user stories consist of the Three C’s:
9. Each user story needs to be written in a consistent format and follow the INVEST model:
- Sized Right or Small
10. It’s important for the discovery team to collaborate with each other and provide support to the development team. Use collaboration mechanisms such as feedback elicitation, stand-up meetings, demonstrations, and retrospectives. Discovery teams should have frequent interaction with developers, business stakeholders, and the QA team.
If you’re a PM needing help on implementing these guidelines, Enfocus Solutions Inc. provides a complete solution for dual-track agile development by helping teams focus on discovery to ensure projects deliver value to the business, customers, and users. Download the white paper below or contact us for a consultation to find out how we provide a complete solution for powering business value, reducing waste, and increasing ROI on projects.
I’ve written a fair number of requirement documents in my business analyst lifetime, and I’m still not sure what took longer – gathering and documenting the requirements, or trying to get the business to read and approve them.
Let me know if this sounds familiar…
You spend weeks, maybe months, eliciting requirements, reviewing requirements, and documenting requirements in a nicely formatted word document with the title Business Requirements Document (or something similar) slapped on the front. You are proud of the work you have done, the diagrams you have drawn, the requirements you have logically ordered and laid out for your stakeholders to read – and you’re sure that you have made it down right simple for anybody to just open it up and review it.
You happily click send on the email, sure that your stakeholders will read it and send back their input within the requested time frame—after all, who wants to risk the project deadline, right?
Problem is, usually stakeholders don’t have the time, or the space, to review a long—and let’s be honest—often boring, requirements document. Your priority as the BA to get the requirements document reviewed and approved is unfortunately often not their priority—and it’s extremely hard to make it so. Or even when you do get their input, what you receive is often not as meaningful as you were hoping—I remember on more than one occasion receiving a requirements document back with fewer comments about the requirements themselves than about the spelling or grammar style I chose to write it in.
In today’s projects, where the dynamics of the solution is constantly shifting, the complexities increasing, and our stakeholders’ attention spans are ever so quickly decreasing (whose isn’t really?)—the inefficiencies of using a document to record, manage, review, and gain stakeholder approval for requirements needs to be questioned.
If it’s not, projects will continue to be negatively impacted by:
- Incomplete and inaccurate sets of requirements
- Delayed implementation schedules
- Lack of stakeholder engagement
- High levels of change requests during the test phase
- Lack of user adoption once the solution is implemented
- High levels of rework resulting from requirement misunderstandings
And, I’m sure you can probably name a few more that affect you as well.
We need to start acknowledging, and managing, the fact that stakeholders simply don’t have the time, or the desire, to read the stodgy documents we tend to throw at them in projects. We also need to acknowledge that much like the projects we are working on, requirements also need to be able to easily adjust and pivot with the changing dynamics of a project landscape. Business objectives can change, stakeholder needs can change, the market can change, the priorities of what we are building can change—and with those changes, the requirements need to change as well.
As business analysts, we need to be able to effectively manage them. Assessing change requests can be one of the largest challenges any project manager or business analyst faces on a project—and attempting to do it from within a large document, can make it all that much more worse. In fact, doing so poses a risk to the entire project. How can you tell what the impact of a change request will be when the traceability and context of a requirement is spread confusingly throughout a document? Wouldn’t it be easier to just see all those impacts in one place? And really that is just one small example of how managing requirements within a document can be so inefficient.
So what’s the answer?
Well, at Enfocus Solutions, we think: enough with managing the documents, time to start focusing on managing the data instead.
To effectively manage requirements means that as business analysts, we need to stop spending our time on managing the document the requirements are in, and instead focus on managing the requirements themselves.
We need a better way to:
- Review requirements with stakeholders and receive meaningful feedback to ensure the accuracy and completeness of their requirements as we move through the project.
- Establish a visible and accessible location to document the requirements for a project.
- Control the changes made to the requirements once initial approval has been achieved, and control the resulting versions of requirements that result.
- Effectively communicate changes to requirements to the right stakeholders throughout the lifetime of a project.
- Capture the context and traceability of the requirements we define—where they came from, why they are being developed, and what value they will ultimately deliver.
So what does managing data instead of documents look like?
Instead of documents, and the multiple versions that usually result…
Use a requirements management tool to establish your single source of documenting, reviewing, validating, and managing requirements throughout the lifetime of your project.
Instead of gathering stakeholder feedback in isolation of one another…
Establish transparency and generate conversation with and amongst your stakeholders using a tool that allows you to capture stakeholder comments and needs in one location on the requirements themselves, keeping the conversation visible and accessible to everyone else on the project.
Instead of validating and approving requirements all at once, after you’ve completed the document…
Validate and gain stakeholder approval as you go—eliminating the need for stakeholders to navigate their own way through a large requirements document, and enabling them to easily navigate their way to only the requirements that impact them.
Instead of limiting the participation of your project team by making them wait for a completed and approved requirements document….
Enable collaboration with them by providing visibility and access to the validated requirements as you go through the project. If you start to review with your stakeholders as you go, then developers and testers can start to work in parallel with you too. Keeping your team actively involved in the conversation from the start, is just as important as keeping your business stakeholders involved.
Instead of wanting to pull your hair out trying to manage changes to requirements after review and approval…
Manage the change requests through a defined process built into your requirements management tool, so you can easily assess the impact each change will make and control the changes that are included in each release.
And the list can really go on.
Documenting requirements is an important part of any successful project, but at the end of the day if we are spending our time and energy on managing the vehicle we are communicating them instead of the requirements themselves, there is a large risk that requirements will be overlooked, be incomplete, and ultimately not clearly define what it is the business needs to be successful.
Once the shift starts to move away from building and managing the documents that hold the requirements themselves, and more towards managing the data within them, then the opportunity for improved collaboration, requirements quality, requirements development, testing, and ultimately, project success is what results.
Business analysis is at a dangerously low level of maturity for most organizations. According to Standish Group Research, the top five reasons for failed or challenged projects are:
1. Lack of user involvement2. Lack of transparency3. Poor or incomplete requirements4. Changing requirements5. Lack of business alignment
Look at all these problems carefully; all of these are related to poor business analysis. Looking at this and other research, poor business analysis is the number one cause of failed and challenged projects. A vast majority of business analysts only write solution requirements and do not perform other activities as specified in IIBA’s Business Analysis Body of Knowledge. Many are not involved in activities such as Enterprise Analysis and Solution Assessment and Validation. Many only write solution requirements and have not idea about the importance of other requirement types defined in BABOK. A mature business analysis function will perform the following types of activities:
- Focus on achievement of business outcomes and enablement of business change.
- Perform analysis and evaluation, not simply taking notes.
- Work with Business SMEs to analyze the problem and root cause.
- Work with Business SMEs to redesign business process to decrease cycle time, reduce errors, and reduce waste.
- Serve as the knowledge manager for the solution by providing advice, facilitating discussions and decisions, and promoting collaboration between business and technical stakeholders.
- Responsible for defining and managing solution scope.
- Work with stakeholders to simplify solutions and eliminate non-value added features and functions.
- Write high quality requirements that are concise, clear, complete, testable, and valuable.
- Assess and validate the development and deployment of the solution to ensure it achieves the expected results.
If the primary or only role of BAs in your organization is to write solution requirements, then your level of maturity of business analysis is very low. Your organizations has a high risk for:
- Increasing the number of failed or challenged projects
- Failing to achieve business benefits
- Delivering solutions that do not meet user needs
- Creating high development rework resulting in budget and schedule overruns
- Having low customer and user satisfaction
- Failing to manage solution scope resulting in delays and budget overruns
If your organization suffers from these problems, then it is time to deal with the cause of the problem, which is most likely poor business analysis. You should focus on building business analysis skills. Here is a list of specific recommendations:
- Ensure that the role of the BA is documented and understood. Business analysis involves more than just defining solution requirements.
- Increase business analysis maturity—encourage standardization of business analysis practices. Consider establishing a community of practice or Center of Excellence to focus on education and building business analysis skills.
- Ensure that critical up-front business analysis activities such as problem definition, solution scope, and the business case are performed as part of every project.
- Project managers should verify that projects have critical business analysis skills on the team. If not, project managers should document this as a risk and look at supplementing the team with external resources who have these skills.
- Ensure that the problem is understood and a clear vision has been developed before starting to define requirements.
- Ensure that the solution scope is defined before starting to define solution requirements. Do not use requirements to define solution scope!
- Require a Business Analysis Plan that addresses
- Requirements Management
- Stakeholder Engagement and Communications
- Requirements Traceability
- Solution Assessment and Validation
- Business Requirements
- Stakeholder Requirements
- Functional Requirements
- Non-Functional Requirements
- Transition Requirements
- Ensure that all five types of requirements are defined.
- Develop requirements collaboratively—both user and technical input are critical.
- Develop requirements with just enough detail, just in time. Do not under-specify, and do not over-specify.
- Ensure that business analysis deliverables are defined and included in the Work Breakdown Structure (WBS).
- If your project involves business processes, ensure that the solution is being built for the To-Be solution and not the As-Is way of operating.
- PMs should work with the BA in properly defining the Solution Assessment and Validation approach and integrating with Quality Management processes.
- Use a proven business analysis tool such as Enfocus Requirements Suite™—do not rely on Microsoft Word or Excel, or on a simple requirements management tool. A basic requirements management tool will not solve a business analysis problem!
Even though it’s a methodology designed for product management teams, Lean Startup provides a lot of good concepts and principles for project managers looking to make sure their projects are successful. And while the word “startup” is in the name, its core tenets can actually be applied to any organization, whether a startup or a Fortune 500 company.
“The goal of a startup is to figure out the right thing to build—the thing customers want and will pay for—as quickly as possible. In other words, the Lean Startup is a new way of looking at the development of innovative new products that emphasize fast iteration and customer insight, a huge vision, and great ambition, all at the same time.” - The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries
If we take this quote from author and Lean Startup pioneer Eric Ries and replace the phrases “a startup” and “Lean Startup” with the phrase “an organization,” the statement would still be true. Any organization wants to figure out the right thing to build as quickly as possible, not just startups. With agile development being the latest craze, we all want to emphasize fast iteration, and experience has taught us all that customer insight is at the core of success.
Many of the lessons and principles in Lean Startup are indeed tailored to the needs of entrepreneurs and new endeavors; however, many of them also apply to project management initiatives in any company. 50% of features and functions are rarely or never used, while 30% get used sometimes or infrequently, according to recent Standish Group research. Organizations need a way to figure out the right amount of features and functions to build so that users adopt solutions and customers are satisfied. Adopting the Lean Startup approach will help.
Lean Startup is based on the tried-and-true scientific approach that we all learned for the first time back in elementary school. The process is simple and can be applied to project management initiatives:
1. Create hypotheses.
One of the major goals of a project is to figure out the right thing to build as quickly as possible, meaning the thing that customers want and will pay for. A traditional project starts out with a problem statement, vision, business objectives, and the set of features that make up the solution. According to Lean Startup, these requirements are only hypotheses at this point—educated guesses.
For each feature of the solution, the project team has researched customer needs and prioritized scope according to alignment with organizational strategy. Each feature can be written as a hypothesis:
“We believe that [building this feature] [for these people] will achieve [this outcome.] We will know we are successful when we see [this signal from the market.]”—Ries
This set of hypotheses will be tested in the next couple steps by building only the features about which the hypotheses are written.
2. Deliver minimum viable product.
To validate that our set of hypotheses is correct, the project team builds the minimum viable product so that they can get feedback before moving forward. The minimum viable product consists of only the most critical features to achieve the project’s vision. More features and functionality will be added in later iterations, but all the project team needs to focus on now is building a product that only includes core features. It’s usually delivered as a prototype or only to a select group of users.
The minimum viable product is a good way of ensuring you’re satisfying customers. Focusing efforts on the minimum viable product provides a feedback loop to guide development and helps to ensure the solution provides enough value for user adoption.
3. Get feedback.
After the minimum viable product is built, the project team works on getting feedback and measuring results to understand the actual value delivered. Retrospectives and meetings with customers may be necessary. In this step, the project team compares the received comments with the hypotheses created at the beginning of the project.
The purpose of this step is to achieve Validated Learning. According to Ries in The Lean Startup, validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects. This iterative process of validated learning is useful for ensuring your project teams always deliver the most value possible with the least amount of effort.
4. Repeat, pivoting if necessary.
If the feedback we received in the last step is not satisfactory and does not meet the needs of the project, then the project manager needs to decide how to pivot. A pivot is a major strategic change toward a new direction. Sometimes, structural course corrections are necessary to meet the goal of the project. It’s best to know about these changes as soon as possible, which is why we deliver the solution in increments as minimum viable products.
If the feedback aligns with our hypotheses, then we continue on down the path of the project lifecycle, delivering functionality in small increments and pivoting only when necessary. This iterative process is continued until the company achieves a desirable product-market fit, or until the product is deemed non-viable.
The questions below came from our latest webinar on KPIs for Agile Project Managers and Business Analysts.
What are some leading BA KPIs?
- Stakeholder satisfaction by Feature (Satisfaction)
- Stakeholder activity by Feature (Engagement)
- Cycle time from ideation to Feature approval
- Business value per Feature (Value)
- Test coverage for Feature (Quality)
- Number of defects per Feature (Quality)
- Feature Completeness (Inspection or Peer Review)
Is it common practice to have stakeholders sign off on KPIs prior to development?
Yes, however, stakeholders should also be actively involved in their development. Getting stakeholder approval is key for all KPIs.
What is a good way to minimize the time to get signoff on requirements WITHOUT getting poor/missing/misunderstood requirements?
Optimally, requirements should be reviewed as they are being created. To do this requires an automated requirements tool such as Enfocus Requirements Suite™. Here are some specific recommendations:
- Break down the solution scope into separate independent components (Features).
- Validate each Feature and eliminate Features that provide little or no value.
- Define solution requirements only for validated features.
- Assign a BA and a Sponsor to each Feature
- Allow stakeholders to review and comment on each requirement as they are being developed using an automated tool such as Enfocus Requirements Suite.™
- Obtain review and signoff on a Feature by Feature basis using stakeholders that are involved in that feature. This procedure can prevent a lot of noise.
- Measure the cycle time from Ideation to validation and validation to acceptance.
Where can I get the benchmark for any metric?
There are many benchmarking services, including:
- The Hackett Group
- Enfocus Requirements Suite™ (RequirementCoach™)
- Process Intelligence
What tool was used for slide #54 "Monitoring Stakeholder Engagement"?
The graphic was a screenshot from Enfocus Requirements Suite™ by Enfocus Solutions. This is captured as a standard metric in the tool.
All the metrics described in the presentation require measurements. To become useful, some sort of engine is needed to collect all the data, calculate the KPI and present it. Can we have the presenter recommend tools for doing that?
Yes, visualization of metrics is very important using a dashboard. There are hundreds of tools that do this. Here are some of my favorites:
How can PMs learn how to create KPIs/metrics?
This is a standard skill that every PM should learn. As we move away from traditional project management towards agile, PMs will be expected to manage the delivery of value more and more. I would highly recommend that all PMs learn how to define and use KPIs and metrics.
In general whether the methodology is waterfall or agile, is it necessary to trace the KPIs of business analysis to that of project management? If yes, how can this be achieved?
Business analysis is a key part of every project, similar to testing and development. Business analysis KPIs should be established to measure business analysis just like any other activity. Here are some good metrics for business analysis:
- Number of defects in requirements
- Average cycle time to validate and approve a feature
- Stakeholder satisfaction for each feature
- Benefits identified by feature
- Inspection Report for Feature Completeness
- Developer Satisfaction
- Tester/QA Satisfaction
- Amount of Test Coverage/Feature
- Amount of Requirement Change
What do you recommend as the best way to ensure that time is properly allocated to follow up post release to ensure project KPIs are met? Should this be the stakeholders’ responsibility rather than IT, in order to ensure that they are focused on making sure they get benefit realization?
I would recommend not closing project until the benefits have been realized. The PM should continue to work with business stakeholders to ensure project benefits have been achieved. Most of the IT team can be released after solution delivery, but the PM should stay until benefits have been realized.
For a good explanation of this approach, refer to March Resch’s book Strategic Project Management Transformation – Delivering Maximum ROI & Sustainable Business Value.
Is it possible to prioritize features in the tool?
Yes, many features are built into Enfocus Requirements Suite™ for prioritization including:
- Rank Order
- High, Medium, Low
- Likes and Dislikes
Features that provide little or no value may be descoped from the project. Please note that 64% of features that are developed are rarely or never used. Validating and prioritizing features is absolutely critical for scope management and controlling costs on projects.
Are you aware of any particular issues people may come against when trying to get stakeholders engaged in benefit-focused requests rather than instinct and what are the best ways to challenge this thinking?
Project sponsors love KPIs and metrics. They want to see their business outcomes achieved and without effective measures it is difficult to achieve. Stakeholders also want to see improvements in operations. The key is to reach agreement on the KPIs and communicate them to everyone. Research has shown that proper use of KPIs actually reduces political conflict and turmoil.
Can you apply these concepts mentioned in your webinar to projects other than IT? I.e., huge infrastructure projects, involving many stakeholders.
Yes these same techniques work on any type of project including manufacturing and construction projects. Please contact us for a consultation to discuss additional information. These same concepts apply to product development and management. The metrics and KPIs will change based on the project.
Any scenario is set up to reach a certain target; for example, what do we need to do to increase xx by yy %? Project results should be the outcome of this scenario.
Yes start with a scenario, convert it to a specific objective and define metrics to measure performance. Scenarios are an excellent tool to use to reach agreement on objectives and metrics.
Delivering a project “on-time and on-budget” is no longer an adequate measure of project success. In today’s environment, the key question should be: “Did the project deliver value to the business?” For example, a project could be delivered on time and on budget, but does not guarantee:
- Benefits outlined in business case were achieved
- User adoption
- Expected ROI was achieved
- A satisfied customer
- The solution addresses the customer need
- Sales were in line with forecasts
- There will be market demand for the product
As a project manager, you may think that delivering business results isn't your concern and that it is the customer's problem to solve. However in today’s environment, project managers are expected to partner with the customer, understand the business drivers, and ensure that the project delivers the business results that were specified in the business case. That is how many organizations are beginning to view project success.
Delivering business value can be a tall order. Delivering business value requires gaining an understanding of the business drivers: the problem or opportunity that precipitated the project and defining a clear set of business objectives to address the problem. Measuring business value is best done through defining Key Performance Indicators (KPIs) and measuring actual performance using the KPIs. Key Performance Indicators are quantifiable measurements that are agreed to by stakeholders to reflect the critical success factors of an organization. KPIs are:
- Established by the customer at the beginning of the project and listed in order of priority.
- Directly related to and supported by business goals and objectives.
- The basis for critical decision-making throughout the project.
- The basis for acceptance of the solution by the customer at the end of the project.
Defining KPIs can be challenging. Good KPIs must have a target value and a way to be accurately measured and reported on. Ideally, it would be best if the project sponsor simply handed you a list of project objectives, success criteria, and KPIs when you were brought on board as the project manager. However this rarely happens; you will usually need to work with the customer or project sponsor to define them. Many sponsors are not trained on how to define good KPIs. This is a skill that you will want to have and to provide as a project manager. Good KPIs are:
- Aligned—Agree with the specific organization’s vision, strategy, and objectives.
- Optimized—The KPIs should be focused on providing organization-wide strategic value rather than on non-critical local business outcomes. Selection of the wrong KPI can result in counterproductive behavior and sub-optimized results.
- Measurable—Can be quantified/measured.
- Realistic—Must be cost effective and fit into the organization’s culture and constraints and achievable within the given timeframe.
- Attainable—Requires targets to be set that are observable, achievable, reasonable, and credible under expected conditions as well as independently validated.
- Clear—Clear and focused to avoid misinterpretation or ambiguity.
- Understood—Individuals and groups know how their behaviors and activities contribute to achieving the KPI.
- Predictive—The KPI may be compared to historical data over a reasonably long time so that trends can be identified.
- Agreed—All stakeholders should agree and share responsibility for achieving the KPI target.
- Reported—Regular reports are made available to all stakeholders and contributors so they know the current status and take corrective action if needed.
Bernard Marr, a well-known performance management expert, has developed a list of 75 KPIs that every manager needs to know. Every business and every project will have different KPIs to measure performance, but Bernard’s list gives you a good starting point for conducting discussion with the business. The set of 75 KPIs that Bernard Marr developed is listed below for your convenience.
1. Net Profit
2. Net Profit Margin
3. Gross Profit Margin
4. Operating Profit Margin
6. Revenue Growth Rate
7. Total Shareholder Return (TSR)
8. Economic Value Added (EVA)
9. Return on Investment (ROI)
10. Return on Capital Employed (ROCE)
11. Return on Assets (ROA)
12. Return on Equity (ROE)
13. Debt-to-Equity (D/E) Ratio
14. Cash Conversion Cycle (CCC)
15. Working Capital Ratio
16. Operating Expense Ratio (OER)
17. CAPEX to Sales Ratio
18. Price Earnings Ratio (P/E Ratio)
19. Net Promoter Score (NPS)
20. Customer Retention Rate
21. Customer Satisfaction Index
22. Customer Profitability Score
23. Customer Lifetime Value
24. Customer Turnover Rate
25. Customer Engagement
26. Customer Complaints
Market and marketing efforts:
27. Market Growth Rate
28. Market Share
29. Brand Equity
30. Cost per Lead
31. Conversion Rate
32. Search Engine Rankings (by keyword) and click-through rate
33. Page Views and Bounce Rate
34. Customer Online Engagement Level
35. Online Share of Voice (OSOV)
36. Social Networking Footprint
37. Klout Score
38. Six Sigma Level
39. Capacity Utilisation Rate (CUR)
40. Process Waste Level
41. Order Fulfilment Cycle Time
42. Delivery In Full, On Time (DIFOT) Rate
43. Inventory Shrinkage Rate (ISR)
44. Project Schedule Variance (PSV)
45. Project Cost Variance (PCV)
46. Earned Value (EV) Metric
47. Innovation Pipeline Strength (IPS)
48. Return on Innovation Investment (ROI2)
49. Time to Market
50. First Pass Yield (FPY)
51. Rework Level
52. Quality Index
53. Overall Equipment Effectiveness (OEE)
54. Process or Machine Downtime Level
55. First Contact Resolution (FCR)
Employees and Their Performance:
56. Human Capital Value Added (HCVA)
57. Revenue Per Employee
58. Employee Satisfaction Index
59. Employee Engagement Level
60. Staff Advocacy Score
61. Employee Churn Rate
62. Average Employee Tenure
63. Absenteeism Bradford Factor
64. 360-Degree Feedback Score
65. Salary Competitiveness Ratio (SCR)
66. Time to Hire
67. Training Return on Investment
Environmental and Social Sustainability Performance:
68. Carbon Footprint
69. Water Footprint
70. Energy Consumption
71. Saving Levels Due to Conservation and Improvement Efforts
72. Supply Chain Miles
73. Waste Reduction Rate
74. Waste Recycling Rate
75. Product Recycling Rate
User stories provide agile practitioners with great success because they help focus on the value being delivered to users. As Mike Cohn writes in his book, User Stories Applied: For Agile Software Development: “Rather than allowing product backlog items to describe new features, issues to investigate, defects to be fixed, and so on, the product backlog must describe some item of value to a user or to the product owner.”
And that’s why a key component to agile software development is effectively managing the user story backlog.
Typically in an agile operation, an initial set of user stories is defined as part of the discovery process, and additional user stories are continuously added by the team as needed during delivery. Defining user stories is a convenient way of capturing requirements at a high level of detail while focusing on user goals—which is why they can be so successful at helping you determine what is valuable to your uers.
Good user stories are much more than just statements. A good user story consists of three elements, commonly referred to as the three C’s:
The user story should be able to fit on a 3”x5” note card, efficiently capturing the most important information. While this “C” sometimes refers to an actual note card, we mean it to refer to the optimal size of a user story. As Jeffries writes, the card should not contain all information about the requirement, but rather just enough to be used in planning to identify the requirement and remind the project team of the story. Each user story should follow the standardized format of:
“As a [particular user], I want to [perform this action], so that [I can achieve this goal.]”
Focus on gathering user stories for each user type to create a set of the most representative user stories possible. Whenever possible, user stories should be written directly by the users. However, depending on the type of project and organizational specifics, user stories may be written by project team members and/or the product owner, as well. A complete set of user stories can be gathered using common elicitation techniques such as interviews, questionnaires, observations, and user story writing workshops to ensure that the user stories accurately reflect user needs.
Before user stories are about to be placed into a sprint, the product owner should talk to customers about their user story (or a user story that pertains to their business domain) for elaboration and validation. Elaborative conversations with users are necessary because a user story may be difficult to interpret, some background knowledge could be needed for implementation, or the requirements could have changed since the story was written.
Conversations represent discussions between the project team and the product owner or other stakeholders and business SMEs. In these conversations, the product owner informs stakeholders of what is going on, and stakeholders or team members exchange thoughts, opinions, and feelings. Conversations should take place throughout the project lifecycle. While we’re mainly talking about verbal discussions here, conversations can also include electronic communications through email, internal chat programs, or a via a requirements management and business analysis tool such as Enfocus Requirements Suite™.
The final component of a user story is the acceptance criteria used to confirm that the user story is implemented correctly and successfully delivered. Acceptance criteria must be defined before development begins to determine when each user story is finished and working as the user intended. Acceptance criteria can be used to demonstrate a user story’s boundaries, and are often thought up during conversations between the product owner, project team, and users. It is recommended that users are the ones to write acceptance criteria because each user story was written from a user’s point of view—therefore the tests ensuring a user story’s completion and satisfaction should be written by the users, too.
It is best to define details like acceptance criteria just in time before user stories are placed in a sprint. Providing too much detail is wasteful and time consuming because if a user story changes, the details will need to be changed, as well. However, providing too little detail often results in significant rework and forces developers to make incorrect assumptions. They should be written to be barely sufficient; that is, user stories should only contain the absolute minimum amount of information required to enable development and allow testing to proceed with reasonable efficiency. The rationale for this is to minimize time spent on anything that doesn’t add value to the end product.
Many project risk managers view risk management as the identification and mitigation of potential events that could affect the likelihood of a project’s success. This view is flawed, as the greatest risk to a project success is not some event that might occur, but rather simply having poor processes and practices for collaboration, project management, discovery, development, or delivery.
At the beginning of an initiative, there are many risks associated with getting the requirements right, obtaining active user involvement and adoption, and enabling business change to achieve successful business outcomes. However, most risk management practices are focused internally on project resources, project activities, and project deliverables. Risk management practices must change from the current process of focusing internally within the project to an external focus on the business and the users.
There are two aspects to software risk: Context and Process. Both of these areas are explained below.
Understanding the context for risk is critically important. In understanding risk, it is important to gain an understanding of both the organizational and strategic context. Gaining this understanding requires a thorough review of the environment in which an organization exists and operates. It is important to take into account your organization's specific objectives and capabilities, as well as external factors, such as the changing legal environment and shifting social standards. Establishing context provides the framework for the risk management process. Context risks can be defined in three broad categories: Project, Business Change, and User Adoption, which are explored in the following paragraphs.
Project context is where risk management has traditionally concentrated. It is generally focused on the work to deliver a successful project. In gaining an understanding of project context, it is important to look at, among others:
- Project resources and skills
- Budget and time constraints
- Solution scope
- Project management methods and tools
- Development lifecycle (e.g., agile, plan-driven, or other)
- Requirements development and management practices
Understanding the amount and extent of business change is best done though identifying the impacts to the areas listed below. Understanding how the project will impact these areas can make a big difference in delivering better outcomes.
- Business processes
- IT services and technology
- Enterprise data
- Governance and business rules
User adoption risk is perhaps the greatest risk in delivering value from an IT Project. User adoption needs to be considered from the start of project. Projects that accumulate too much user adoption risk should be modified or cancelled if their chances of failure are too high. Too often, user adoption is addressed as “change management” only before deployment.
In gaining an understanding of user adoption risk, it is important to look at:
- Who the users are,
- What tasks and activities the users perform, and
- What problems and needs does the solution address?
Using well-defined proven practices for project management, business analysis, and development significantly reduces project risk. For example, agile methods are now considered an effective method leading to project success. Agile methods are effective for the following processes:
- Project management
- Communications and collaboration
- Delivery and deployment
There are two essential practices that should be part of every project. The first is breaking the project into smaller components that can be delivered independently, and the second is reducing and managing solution scope.
Simply breaking a project into smaller components that can be managed and delivered separately significantly improves the success of a project. It is important not to interpret breaking projects down into a series of smaller projects. This does not mean defining a large project into milestones, phases, critical paths, and activities. Rather, it means planning a series of projects each with its relevant milestones, phases, critical paths, and activities. Delivery of concrete and usable results demarks a successful completed project.
According to the Standish Group, 64% of software features developed and implemented are rarely or never used. Identifying and eliminating features that provide little or no business value before they are developed can have a significant impact on value delivery and achieving successful results at a much lower cost.
A new breed of tools is beginning to emerge that enable the key concepts identified in the Standish Group Report to be achieved. One leading example is Enfocus Requirements Suite™, a Software as a Service product from Enfocus Solutions Inc. This tool allows features to be defined and validated independently and then delivered as series of small projects (bundles). The benefits of applying these two techniques using a tool such as Enfocus Requirements Suite™ quickly become evident when the organization starts to receive value earlier and projects success rates soar.
By proactively identifying and eliminating or remedying poorly performing application assets, Application Portfolio Rationalization helps companies to:
- Reduce costs,
- Target efforts to the areas of highest return, and
- Maximize the business value of their application portfolios.
Globalization and changing business requirements impose significant challenges on technology leaders who are under constant pressure to both innovate and reduce costs. These demands to do more with less have been exacerbated by business leaders hearing about prospective savings from use of the Cloud without understanding the impact of transition. Many organizations are electing to combine their initiatives for application rationalization and migration to the cloud.
IT leaders are forced to accelerate the rollout of new systems and technologies to support the business without compromising the performance of existing applications. They must address key issues, such as balancing cost, complexity, and capacity, and also deliver business value by applying continuous improvement methodologies. Application portfolio rationalization helps organizations turn these challenges into benefits in terms of reduced costs and more value delivered to the business.
Application portfolio rationalization is an important and continuous exercise for evaluating and controlling IT costs. Application portfolio rationalization involves focusing on the application portfolio looking for redundant applications, one-off technologies, applications with few users, and applications with a high cost/user ratio. With a complete understanding of the current environment, the next step is to consider what should be done to move from current to the ideal.
Gartner Group research confirms that a focused application rationalization effort will typically result in substantial cost savings while improving support for the lines of business. These savings are too large to ignore. Additional benefits include a simplified infrastructure and an availability of resources—allowing organizations to focus on what really matters. One of the most consistent discoveries that organizations find in the rationalization process is that they are at a competitive disadvantage. IT environments are considerably more complex than they thought, and their total cost of ownership is considerably higher than many of their peers.
In rationalizing an application portfolio, it is important to look at three key areas:
- Reduce Cost and Remove Complexity
- Deliver More Business Value
- Reduce Maintenance and Support Risks
Each of these areas is discussed in the following paragraphs.
Reduce Cost and Remove Complexity
The first step in application portfolio rationalization is simply to identify opportunities to reduce cost and remove complexity. Some of these methods are easy and obvious and others will take significantly more work.
- Consolidate Redundant Applications – Consider replacing or removing redundant applications that have overlapping functionality in order to reduce costs.
- Eliminate Applications that are not used – In many application portfolios, there are applications that are no longer used.
- Find Other Alternatives for Seldom Used Applications – Many applications may only have a handful of users. These applications can be very expensive to maintain and support.
- Replace Applications that have High Maintenance and Support Costs – Analyze the support costs for each application. If support costs for an application seem high compared to the business value provided, work with the business to consider replacing expensive applications with a more cost-effective solution.
- Standardize Application Vendors – Consolidating a major portion of your application portfolio with one main vendor (e.g., IBM, Microsoft, Oracle, SAP, etc.) enables an organization to gain additional discounts due to higher volume purchases, and cost less in interfaces and in achieving seamless streamlined processes. Training costs and personnel support costs are also less with a consistent technology stack.
- Manage User Counts – Ensure you have an accurate user count for software licenses. Right size application software for your exact needs. Only purchase and pay maintenance for software licenses for the current number of users. For example, one company purchased 300 ERP licenses as the company was on an aggressive growth curve. The company did not grow as anticipated, and they continued to pay for excess software license capacity for years rather than right sizing the contract.
- Watch Processors, Cores, or Virtual Machines – The price for some software is based on the number of CPU processors or number of core processors. If so, look at reconfiguring hardware to have a lower processor count. Make sure to understand the impact of virtualization on application licenses. For example, one major vendor requires that if an organization uses a software product in one virtual machine, they must pay license fees as if the software were deployed to all of the cores in that server.
- Consolidate Application Instances – Try to consolidate application instances into the least number possible for a lower TCO. Generally, each separate instance costs additional money for licenses as well as maintenance and support costs.
- Minimize Customizations – Minimizing customizations to package software takes discipline but can save significant dollars. A software vendor package that has significant customization is a challenge to support and keep operational. The total cost of ownership of custom modifications is significant over the life of the software package as it is necessary to redo and test modifications on all future software releases. This also has a significant impact on business agility. Unfortunately for many companies, software customizations are like eating just one potato chip; it is difficult to stop once you start.
Deliver More Business Value
Business change is occurring rapidly, requiring IT to be able to respond at an increasingly rapid pace. Many applications support old antiquated business processes. Worse yet, many businesses make changes to the business processes without making necessary changes to the technology that support them. Business units became frustrated with long cycle times for IT to make the necessary changes, and as a result developed workarounds in the form of spreadsheets or standalone departmental systems to accomplish their needs. One goal of application rationalization is to leverage the application portfolio to deliver more value to the business.
- Identify and Eliminate Workarounds – A good starting point is to simply identify the number and extent of workarounds and departmental systems. Find out why these exist and see if there is a quick fix by simply taking advantage of functionality that already exists. Commercial software is generally continuously upgraded, but most companies fail to fully take advantage of these features after the initial implementation. Companies have been paying for these features through ongoing maintenance contracts but have not taken advantage of the functionality to improve operations and reduce workarounds.
- Assess Business Value – Assess business applications to ensure they are providing the desired business value. Make sure that the business value received from each application is in proper alignment relative to the associated costs. Review the support costs by application with each business executive to ensure they feel they are getting comparable value.
- Identify Functionality Gaps – When examining the application portfolio, try to identify areas that are underserved. For example, in one company, when doing this analysis, the company discovered that there was no automated support for marketing. When looking at the processes in marketing, they found a severe need for improved processes and technology, which, when implemented, resulted in tremendous business benefit. Other examples include implementing a Business Intelligence (BI) system to get the right information to the right individual faster and cheaper, enabling improved business decisions and finding new ways to interact with customers to drive additional revenue.
- Use More Functionality – According to the Standish Group, 64% of functionality implemented is rarely or never used. Most companies fail to take full advantage of their enterprise software packages, ignoring important features that drive significant business efficiencies. Work with business managers and staff to review currently owned functionality to see if they would benefit from using available features.
- Use Purchased Software or SaaS Where Possible – Custom-made, internally built applications cost more than vendor-supplied packages in the long run. The real question is how to change an organization with a strong appetite for custom software to a mentality focused on utilizing standard software packages. Most organizations claim that they are special, their business is unique, it has to be a certain way, and the like. In fact, just about every company makes that claim. Yet, evidence shows that about 80% of all business functions are common to all companies within a given vertical. The key is to figure out what and where is that 20% that provides a true competitive advantage, and make it better. The goal is to use commercial software for 80% of the business and custom software only for the other 20%.
- Focus on Business Process Improvements – In implementing new software, many companies focus on the software and hardware when focus should be on business process improvement and redesign, as that is where the true benefits are realized. Companies that have focused on the process and people benefits have realized exponential payback from software implementations. When finished with implementing new software, the business process improvement must continue.
The following are examples of ways that companies have redesigned business processes to realize true cost savings:
- Faster cycle times
- Fewer handoffs
- Fewer steps in the process
- Fewer decisions
- Less duplication
- Minimize delays
- Minimize discrepancies
- Allow fewer exceptions
- Automate manual activities
- Automate workflows by using conditional rules to drive different processes
- Capture data at the source
Reduce Maintenance and Support Risks
Many application portfolios place companies at great risk. If executives really knew how prevalent this problem was, they would not sleep well at night. The main goal is to assess the portfolio from a risk perspective and to take action to reduce risk to the business from the following:
- Evaluate Unsupported Software – Do you ever ask this question: "Should I upgrade my software, or should I take a risk and keep using an old unsupported version?” Taking a risk accurately describes what using unsupported software equates to. It’s like driving your car without insurance so when something goes wrong, it can cause you a world of pain. Eventually, unsupported software becomes a security, support, and business risk. It is important to identify software that is no longer supported and determine what is the best strategy for moving forward. If the software supports a critical business function that is the lifeblood of your company, then the risk is probably too great to continue. For example, you may find that the application software no longer functions when upgrading the hardware it runs on.
- Assess Availability of Skills – There is still a lot of legacy software written in programming languages where it is difficult or impossible to find programmers with the skills to maintain it. Even something as common as COBOL is becoming a problem as this language is simply not taught at the university level and the people that know it have left the active workforce.
- Assess Software Complexity and Documentation – Some software has been patched so many times and has so much technical debt that any changes made to the code has great risk or takes 10 times as much time as it should. This is further exacerbated because there is little or no documentation available and the software developers have left the company.
After identifying strategic changes to their application portfolio, organizations must plan how to move forward to achieve these benefits. This requires defining and prioritizing projects, and defining a clear set of requirements for each project.
Enfocus Requirement Suite™ from Enfocus Solutions Inc. is a powerful tool, knowledgebase, and framework that can be used to help with application portfolio rationalization. Using this SaaS, applications may be defined in a product portfolio and evaluated for areas of improvement. Organizations can identify key stakeholders and make decisions to determine which applications should be retired, combined, or enhanced to deliver more value to the business. Projects may be defined with specific business objectives and accountable stakeholders to make the necessary changes to the application portfolio. The needed changes can be defined as project scope statements. Additionally, each scope statement can include detailed requirements to ensure that the application support teams clearly understand what needs to be done to achieve the cost savings and improvements in delivering more business value. To find out more, please download our product fact sheet below.
Ask someone about business value and you will most likely get a blank stare or many different answers. Is business value the same thing as Shareholder Value or Customer Value? OK—if all else fails, let’s go to Wikipedia; it is always a trusted source right? Here is the definition of Value in Wikipedia:
In management, business value is an informal term that includes all forms of value that determine the health and well-being of the firm in the long run. Business value expands concept of value of the firm beyond economic value (also known as economic profit, economic value added and shareholder value) to include other forms of value such as employee value, customer value, supplier value, channel partner value, alliance partner value, managerial value, and societal value.
Wow, I don’t think this helps much. Let’s look at another source. IIBA’s new BABOK (Version 3) that will be published this year is heavily focused on value. IIBA recently conducted a webinar on Value and posted it on YouTube. According to the IIBA and the new BABOK, value is defined as “The importance of something to a Stakeholder in a Context.” I am not sure that I agree with IIBA’s definition of value but I definitely agree with the IIBA when they say “Value is not understood.”
At first look, this definition is nebulous, but it has components that are very important. There are three key words here that we have to focus on: Importance, Stakeholder, and Context.
- Importance – Importance allows us to compare one option to another and make decisions in terms of what delivers the most value.
- Stakeholders – Understanding the stakeholders is key for any project. Satisfying stakeholder needs is delivering value.
- Context – We must understand the context in order to deliver value. Delivering value in a business context may mean money. Delivering value in a non-profit may mean saving lives and helping people in need.
Product managers are more often expected to deliver more value on projects. This is a tough task if we cannot even define what value is. Product owners are supposed to prioritize the backlog for business value, but what does this really mean?
Here is my definition of business value for a software project (notice the Context):
Business value is achieved when users use software to perform meaningful work resulting in better business outcomes.
There are four perspectives for delivering value on a software project:
- Solution Delivery – We must be able to build the product in a cost effective way and in a timeframe that is acceptable to the customer. The key measures are Cost, Speed, and Quality. If we don’t deliver a high value solution that meets the need of the customer on time and at a reasonable cost, then we have a value problem.
- User Adoption – We can have the best and most reliable software in the world, but if we do not get the users to use the software, then our solution delivers no value at all. User adoption is absolutely essential for delivering value.
- Customer Outcomes – Customers have expectations when they purchase a product or service. For most organizations, this usually equates to money, meaning producing a good ROI by increasing revenues or reducing costs. If our product does not help the customer achieve this, then our product is not delivering value.
- Business Results – To deliver value, we expect the solution to deliver positive results for our own organization. The results are generally measured as increase in market share or increased profits.
So why do we care about value? We care about value because it helps focus us on the right things to build. For software products and projects, we need to focus on the things that deliver the most value. According to Standish Group Research, 64% of functionality that is built is rarely or never used. Focusing on value helps us reverse this trend. In moving forward, we must discover and validate what delivers value. Creating value hypotheses and using validated learning methods such as Lean Startup go a long way in helping us deliver better software products.