The Six Blind Men and the Requirements: Part One
There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant. The first man wrapped his arms around the elephant’s leg and said, “Why, an elephant is just like a big tree.” “No,” said the man who held the elephant’s tail, “an elephant is like a rope.” The third man felt the side of the elephant and reported, “This elephant is like a big wall.” The fourth man gripped the elephant’s trunk and declared, “You’re all wrong. The elephant is like a giant snake.” The fifth man rubbed the elephant’s tusk and said, “I think an elephant resembles a spear.” “No, no, no!” said the final man, who touched the elephant’s ear. “An elephant is like a big fan.”
The blind men were all correct. The elephant has all the characteristics they described, but no single feature of the elephant provides a complete description of what an elephant is all about. Each man had but a limited view of the elephant and could draw conclusions only from that view.
There’s an analogy with software requirements. I learned long ago that no single view of the requirements tells us everything we need to know about them. Often it’s desirable to represent requirements in multiple ways, thereby giving the readers a richer, more holistic understanding of the requirements elephant. Unfortunately, nearly every requirements specification I have read contains just a single view: natural language text. The clever business analyst can do better than that.
Limitations of Natural Language
Natural language is, well, natural for people to use. We employ it every day of our lives in diverse forms. But natural language has some shortcomings. One of the biggest limitations is ambiguity. I once was talking with my father about cars. I said, “For my next car, I’d like to get one of those high-mileage gas-electric hybrids.” My father replied, “I don’t know if you’re going to be able to find a used one.” Used one? I didn’t say anything about buying a used car. When I said high-mileage, I meant, “gets many miles per gallon.” When my father heard high-mileage, he thought, “big number on the odometer.” These are both perfectly sensible interpretations of the phrase high mileage. Ordinary, natural language led to a miscommunication in a casual discussion with someone I knew rather well.
In conversation, we rely on context, body language, and the chance to ask questions for clarification to ensure that we understand what we heard. We have an opportunity during discussions to detect and quickly correct ambiguity. Written communication, such as a requirements specification, doesn’t allow for this opportunity. Confusion can result from misinterpretations and ambiguity, and ambiguity is one of the big risks that natural language poses for requirements. This is one reason why you should never expect an SRS to replace conversations among BAs, developers, and customer representatives. However, when collaborating on software development over long distances, you don’t have many opportunities for conversations. High-quality written communication becomes essential for success.
Writing in natural language also leads to bulky and verbose specifications. In an attempt to clarify what he’s trying to say, the BA might duplicate a piece of information or state it in more than one way. Redundancy often is not helpful in requirements specifications. It can introduce additional ambiguities and inconsistencies. And, frankly, long documents with page after page of text are boring to read and daunting to review. There’s a good chance that reviewers will glaze over and fail to find some of the problems in the document. This is unfortunate, because well-executed reviews of requirements documents are one of the highest-leverage quality practices you can perform on a software project. Detecting and removing defects while they are just ideas is much faster and cheaper than correcting problems in the code.
Another issue is that detailed textual requirement statements represent a low level of abstraction. Each requirement describes but a small fragment of the system’s functionality or characteristics, with little context. Specification readers can have a hard time grasping the big picture and seeing how each individual requirement contributes to it. This makes it difficult for them to judge whether each requirement is correct, complete, and necessary. So the ability to depict requirements knowledge at multiple levels of abstraction and from different perspectives provides a much richer understanding than can any single view.
In this series of four articles, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I will describe why it is so valuable to create various views of your requirements. I’ll tell you about some of the analysis models and other techniques you can use to represent requirements information and give you some ideas about how to choose an appropriate model.
[cta id=”7603″]
PMI-PBA vs. IIBA’s CBAP
With the PMI’s recent release of the new Professional in Business Analysis (PBA) certification, business analysts (BAs) in the community are asking what is the difference between this new PMI-PBA and the IIBA’s existing Certified Business Analysis Professional (CBAP)? Also, if we’re looking into getting certified, which one should we go after?
In their announcement to offer the new certification, the PMI quoted a statistic by the US Bureau of Labor Statistics that “business analysis jobs are predicted to increase 19 percent by 2022.” We agree that this is a good reason for more people to get certified in the field of business analysis. We’re looking at this new certification from the PMI as great news; business analysis as a profession needs to break through the lack of recognition and demand more respect from the global community so that we can all be more successful in our jobs. This certification is definitely a step in that direction.
But before you go and sign up for the PMI-PBA pilot program, we recommend making sure it’s the right certification for you. After looking at the available literature, including the PMI-PBA Examination Content Outline (ECO), it is apparent that this particular certification is focused on a very specific area of business analysis, and is developed for a very specific subset of business analysts.
According to the PMI’s literature on the new certification, “business analysis is a critical function that helps define business requirements in order to shape the output of projects and drive successful business outcomes. In order to ensure the quality of requirements and projects, it is crucial that individuals be skilled and knowledgeable in industry standards and best practices.” While at Enfocus Solutions we agree this is true, we’re also aware that there is a broader usage of business analysis than the PMI-PBA’s project- and program-focused definition.
There’s more to business analysis than just requirements. We’ve always preached that at Enfocus Solutions. While the PMI has acknowledged there are broader applications for business analysis, they do not focus on those topics as a part of the PMI-PBA certification. Their website is very clear that the focus of the PMI-PBA is business analysis in the context of project and program management.
The scope of the PMI-PBA is much narrower when compared to the CBAP offered by IIBA. The PMI makes it clear their BA certification significantly emphasizes requirements management, especially with the recent release of the Requirements Management Knowledge Center of Excellence. On the other hand, the IIBA’s Business Analysis Body of Knowledge (BABOK), a well-established resource for BAs, incorporates enterprise and strategic business analysis, as well as requirements management. Comparing BABOK’s Knowledge Areas to the PMI-PBA ECO’s Domains, you can see the PMI-PBA is centered around requirements development and management activities, whereas BABOK has much broader applications.
This isn’t necessarily a bad thing. It’s just something to keep in mind when looking for the right certification for yourself. In what ways will you need to use business analysis? Are you performing it on an enterprise-scale, or a project-scale?
When we compare the qualification requirements for the two certifications, it becomes apparent that the PMI-PBA leans toward a certain type of audience—that of project and program management. For applicants with a relevant bachelor’s degree, the PMI-PBA requires less hours of BA experience. The PMI-PBA requires 4500 hours over 8 years, versus the CBAP’s requirement of 7500 hours over 10 years. The PMI-PBA is actually more similar to the Certification of Competency in Business Analysis (CCBA) offered by IIBA, which only requires 3750 hours of BA experience over 7 years. What does this tell us? That people going after the PMI-PBA probably don’t spend all of their time on business analysis, and most likely have other project-related responsibilities.
Also, to renew the PMI-PBA every 3 years, you must complete 60 Professional Development Units (PDUs). These courses are created by education providers registered with the PMI, meaning the content is generally focused on project and program management. This is also something to keep in mind if trying to decide between one certification or the other. Are you planning on following a project management-focused path? Or, will you need to learn broader applications of business analysis?
While both certifications have their merits, the PMI-PBA is very obviously geared toward someone with an existing project management background. The IIBA’s CBAP is geared toward a broader audience by including enterprise and strategic business analysis activities. There is an existing, well-established body of knowledge developed by the IIBA, covering all areas of business analysis. However, some people don’t need all of that information. Business analysis is often only a part of what someone does. So, depending on your goals, either certification could be the right one for you. Generally, we suggest people who work in more of a project management capacity to apply for the PMI-PBA as a natural continuation of your project management skills development.
[cta id=”7441″]
Early Validation in Agile Projects is Cost-Effective
When it comes to software development projects, agility should be focused on delivering business value in increments, and not developing software in cycles. While software development is a major aspect, it’s not the end goal of our projects.
Too often when following agile development, the team is uncertain or unclear of what to build that will actually deliver the value set out for at project inception.
Then, what happens is the team starts coding before understanding what really needs to be built, which is a very expensive way to validate that the solution meets customer and business needs. If there is no feedback until the end of a big project, it might be too late or costly to adjust. Instead, it is prudent to get as much feedback as possible, as early in the project as possible.
As Eric Ries, author of Lean Startup, puts it, don’t we all want to “avoid building products that nobody wants?” Recent Standish Group research shows that 20% of Features are used regularly and 50% of Features are hardly ever or never used. According to the study, the gray area is the 30% of Features and functions that get used sometimes or infrequently. All of these Features and functions that are never or barely used are causing higher costs, lower value, and longer cycle times, resulting in lower customer satisfaction. Focusing on the 20% of the Features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction.
To focus on the 20% of Features that give the most value, you need to validate early. So instead of coding and then getting feedback from stakeholders, validation should be upfront in the project and follow Lean best practices, meaning performed with as little waste as possible. The Lean concept of Minimum Viable Product (MVP) is perfect for cost-effective product validation. The MVP is that version of a new product or service which allows a team to collect the maximum amount of learning and feedback with the least amount of effort required. MVPs help the project team to identify and focus on the issues and features that are important to customers before developing a fully working solution.
According to Eric Ries in his presentation on the “Minimal Viable Product,” there are several useful techniques for creating a MVP so that the team can prioritize and eliminate the Features and functions that provide little or no value to customers:
- Smoke Testing—Determine whether users would actually pay for a product or service before developing it by creating landing pages where users can pre-order. Then, use Adwords to attract users to your site. A smoke test is a tried and true marketing technique that measures customer interest in the product or service.
- Search Engine Marketing (SEM)—SEM is a Google innovation in which the advertiser decides how much a user’s click on an advertisement is worth. After setting the amount per day you’re willing to spend, sit back and watch the search engine bring visitors to your website. SEM is a great technique for startups and small businesses who don’t have much of a budget for marketing. Over time, through website optimization (i.e., tweaking landing pages, split-testing the payment system, etc.), those visitors will convert into customers.
- In-product Split-Testing—Create hypotheses about an existing product or service and test your ideas out to determine whether your hypotheses about what customers really want are correct. Split Testing can be used to test out large and small changes, and it’s a good way to get regular feedback and avoid building something nobody wants.
- Paper Prototypes—Draw a basic prototype on paper of how an application interface should work, and walk customers through what it will be like and how it will solve their pain points. Paper prototypes are good for identifying usability issues in software that hasn’t been built yet, meaning the team isn’t wasting time and money developing something that doesn’t work.
- Customer Discovery/Validation—First, discover what customers need and want through various stakeholder engagement methods, such as personas, scenarios, and stakeholder needs. Then, create a repeatable sales roadmap and corroborate your business model with Customer Validation. Validate that you are offering a product that customers want to buy through the process you’ve devised to sell it. When Customer Validation is successful, continue on the roadmap as planned. When it isn’t successful, return to Discovery activities to determine what customers will pay for. Customer Discovery and Validation should be a no-brainer on every product and service, but often gets left out or done poorly, resulting in unsuccessful projects.
- Removing Features—Remove unnecessary Features and focus on the single value proposition that outweighs all others. This is a good technique for new product development. When early users adopt your solution because of how awesomely you executed that value proposition, you’ll have the chance to add those Features and wow them again later. Removing Features can also be a useful technique for existing products and services when certain Features do nothing for user engagement or revenue.
The benefits of using this approach are quickly evident when the organization starts to receive value early in the project cycle. Using code to validate ideas is very expensive, but there are cheap methods available. Better, more cost-effective validation practices will eliminate working on Features that provide little or no value.
[cta id=”7460″]
Agile Business Transformation Q&A
There were a few great questions asked at the end of our webinar yesterday, Agile Business Transformation. While I didn’t have time to answer them in the information-packed webinar, here are your answers.
Q: Does Enfocus know of publications on Agile transformations for business with products with HW as well as SW products?
A: –Agile Development has been used for both the development of hardware and software products. One of the best-known examples is the development of Nokia phones. In Enterprises, many infrastructure groups are also starting to use agile. Many organizations are starting to adopt DevOps which is an umbrella concept that refers to anything that facilitates a smoother interaction between development and operations. The best information for large agile transformations is at www.scaledagileframework.com. There is also a major movement toward integrating Lean with agile and there are several good books on this subject. A very good book on this subject is Implementing Lean Software Development: From Concept to Cash by Tom and Mary Poppendieck.
Q: I find it challenging to differentiate a Feature from An Epic! For example, how would you determine if a BR is a feature or an Epic?
A: — Great Question. A feature has to be small enough to fit into a Release. An epic spans multiple releases. Epics are approved by Portfolio management, whereas Features are defined by program management and are used to decompose an Epic into manageable components. View an epic as a project and a feature as a component of a project.
Q: Most of the time, we find the stories changing to be a Feature or Epic!
A: –This is very common. Teams have to groom the backlog to ensure that stories are small enough to fit into a sprint. Some Scrum trainers recommend that Teams spend 10% of their time each week grooming the backlog. It is much better to have a separate backlog for Features and another backlog for Stories. The Feature backlog is maintained by Program management. The Features are validated and prioritized and given to Teams when ready. The Team Product Owner and Team Members break the Features into stories that comply with INVEST. One backlog for both does not work well for most teams. Many people refer to this problem as “user story hell.”
Q: Question: My team consists of system integrators. Before we can engage them, we need an SOW and they need requirements. With agile, there’s no sets of requirements, how do you guys address this gap?
A: Enfocus Solutions fully addresses this gap. There are two basic ways to do this. It really depends on who provides the Product Owner.
If your organization provides the Product Owner, then the Product Owner defines stories for the backlog and works with development teams to negotiate what will be done for each sprint. You are basically negotiating for a fixed number of sprints. The Product Owner’s job is to define the user stories and associated tests in enough detail to maximize the velocity of the Team. The Product Owner will also need to serve as the SME for the team.
If the Product Owner is provided by the Systems Integrator. Then you will be defining a set of Features which represents the project scope. The validated set of Features is placed in a Statement of Work and are given to a System Integrator. The SOW is done for each Release. Our software fully supports both of these methods.
Q: Could you update the presentation so that on slide 11 with all those stats, could you provide the link to the source, or at least the dates of the report?
A: A copy of the updated slide is shown below. (Also note all slides will be sent to registrants and available in the archive within a few days.)
Q: Slide 13: Any stats on how many organizations actually use paper? Versus Word or other docs that are stored electronically.
A: — I do not have stats on this. I think the number will grow continually as organizations become more agile. There is a huge growth in collaboration and agile development tools. Producing paper documents is slow and anti-agile.
Traditional PMOs vs. Enterprise PMOs that Deliver Value to the Business
The common Program Management Office (PMO) is constantly challenged and called into question by senior management and the C-level. Without executive support, the PMO struggles to be successful in delivering program and project outcomes that effectively provide business value.
Traditional PMOs have a tendency of becoming too bureaucratic and too focused on managing tasks instead of value, increasing project complexity and causing headaches across the enterprise. But recent research proves PMOs can still be effective at delivering business value if managed the right way—at the enterprise level.
To deliver value with initiatives and reduce project complexity, the organization requires centralized coordination of processes and practices. In a traditional, departmentally-based PMO, it is very difficult to align projects with the strategic priorities of the organization. These types of PMOs may be successful on a departmental level but are often not taken seriously by the rest of the organization. When PMOs are departmentally-based, they tend to define value in different ways, skewing project results. Instead, the organization needs a PMO that provides a consistent mechanism to standardize practices and evaluate progress of initiatives across the organization, without creating unnecessary complexity.
When the PMO is operating at an executive level, there is an increased likelihood that project outcomes align with organizational strategy because the PMO has the ability to affect the entire organization. According to a recent study, strategic PMOs that implemented an enterprise-wide approach in 2013 tended to have the most mature processes and practices, and were the most likely to achieve consistently successful project outcomes. The findings indicate that the traditional approach to Program Management Offices is transforming to an approach in which there is one central Enterprise Program Management Office (EPMO) held accountable for the organization’s entire program portfolio.
The EPMO provides a way of effectively managing projects in today’s complex, global marketplace. The traditional PMO lacks direction and control on enterprise-wide initiatives. Without executive sponsorship, projects fail. Resources are reluctant to work with and report to individual PMOs within their own silos without executive support. A centralized EPMO has the respect and executive sponsorship necessary to get people involved. The EPMO creates the appropriate decision-making processes for addressing issues that arise, including how to resolve issues that cross multiple projects. The EPMO structure varies from company to company; most organizations have a single EPMO at the executive level that oversees all projects, but larger organizations have departmentally-based PMOs reporting to a central EPMO that ensures projects are aligned with the strategic plan and manage project prioritization.
The EPMO has the ability to align all projects, either at the corporate or departmental levels, with the organization’s strategic plan to better manage project prioritization and resource allocation. When organizations take on too many projects or programs at once, resources are stretched thin. There needs to be an EPMO in place that can determine whether the projects in the portfolio are carefully aligned with organizational objectives, and that can prioritize projects according to those objectives, making sure to eliminate low-value added projects or projects that don’t align with the enterprise strategy.
A major advantage of the EPMO is that its perspective spans across departments and initiatives, meaning it has insight to all projects and programs across the organization. Unlike a traditional, departmentally-based PMO, an EPMO is able to perform impact analysis on a project in the context of the entire organization—how will the project affect existing people, processes, and technology, as well as concurrent projects.
An EPMO can do a lot more for your organization than a traditional PMO. Implementing an EPMO will improve the way the program portfolio is managed, increasing the business value delivered with each initiative by…
- Defining a consistent definition of value across the organization
- Ensuring projects meet or exceed customer expectations
- Aligning projects with organizational strategy
- Ensuring projects are successfully delivered—on-time, on-budget, and aligned with customer needs
- Mitigating risk early
- Reducing cycle times
- Reduce project costs
- Identify impacts on the organization, individual departments, and customers
- Resolves issues that cross multiple projects
- Provide transparency to project stakeholders
- Communicate project progress across silos
- Ensuring project teams have appropriate skills and competencies
- Standardize project processes, tools, and templates
- Standardize measurements and metrics
[cta id=”7636″]
Creating a Service Design Package (SDP)
When we attended Knowledge14 in San Francisco earlier this week, one thing we noticed is how amazingly far organizations have gotten in adopting IT Service Management (ITSM).
But while it does seem organizations have caught onto the fact that moving towards ITSM provides a lot of value, many have still not yet adopted or placed enough emphasis on the ITIL practices of Service Strategy and Service Design. This is a huge mistake, as ITIL offers valuable guidelines to service providers on the best ways to design and maintain services for the business.
Image from ITIL Service Design
One of those guidelines is to create a Service Design Package (SDP). It seems that many new service providers either neglect the SDP or create one that’s lacking in all the necessary elements. However, creating an SDP ensures your services are designed well, and according to the authors of ITIL Service Design “the better and more careful the design, the better the solution taken into live operation,” so creating a SDP is not a step you want to skip
The Service Design Package (SDP) follows a service through its lifecycle from initial proposal to retirement. It contains all the information required to manage an IT service. The SDP specifies the requirements from the viewpoint of the client (not IT) and defines how these are actually fulfilled from a technical and organizational point of view. When created properly, SDPs bring a lot of value to the business. A SDP…
- Improves the quality of services
- Improves decision-making
- Makes implementation of new or changed services easier
- Improves alignment of services to the business
- Makes service performance more effective
- Improves IT governance
- Makes ITSM more effective
- Reduces Total Cost of Ownership (TCO)
Once a SDP is completed, it is passed from Service Design to the Service Transition phase to provide all information required to develop the service solution, including a preliminary (i.e., intended) time-schedule for the Service Transition phase. Service Transition, Operation, and Continuous Improvement provide input to the requirements in the SDP, ensuring services get better as time goes on.
According to ITIL, a Service Design Package (SDP) should consist of the following contents:
Requirements
This section includes the agreed and documented business requirements, such as the problem statement, vision, and business objectives. The requirements also include service contacts, such as the business stakeholders and customer representatives. These are the high-level details with which the rest of the SDP must align; you want to make sure to deliver the right service to the right group of people.
Service Design
Service Design refers to the functional requirements describing the new or changed service and the Service Level Requirements (SLRs), including service and quality targets. Also, this section includes the operational management requirements for the new or changed service (e.g., supporting services and agreements, control, measuring and reporting). Lastly, this section should document the plan for the service’s transition, implementation, and operation. The Service Design section is very heavy in detail. In addition to the requirements for all service components and infrastructure, don’t forget supporting processes and procedures, as well as measurements, metrics, and reports.
Organizational Readiness Assessment
The information in this section will make up the plan to assess benefit, financial, technical, and resource aspects, and needs to include a description of the new skills, competencies, and capabilities required to transition and implement the new or changed service.
Service Lifecycle Plan
The last section includes the plan for each subsequent phase in the ITIL service lifecycle. This should include the required business processes, as well as a plan for communication and reporting. The Service Lifecycle Plan documents to manage related people, processes, and technology. It should also include timescales and quality targets for each phase. The Service Lifecycle Plan must include all details about service transition and operations focusing on the following:
- Service Transition Plan—document transition strategy, objectives, policies, risk assessment, and plans
- Service Operational Acceptance Plan—document interface and dependency management, as well as planning, events, reports, and service issues regarding the new service and final service acceptance
- Service Acceptance Criteria—document the acceptance criteria progression through each stage of the lifecycle
There are not many tools on the market that enable ITIL’s Service Strategy and Service Design. Enfocus Solutions provides software and services to IT service providers and managers looking to adopt ITIL best practices. Our software and services are designed to ensure services deliver value to the business by providing the capabilities to create a complete Service Design Package.
[cta id=”7640″]
Mobile Apps and Agile Discovery
In today’s world business leaders are demanding IT organizations deliver high value mobile applications at little cost and lightning speed. And if you’ve worked on any mobile application project, then you know that mobile application development projects can be a challenge.
Mobile apps and websites used to simply be a replica of the desktop version of a website, but today they are much more. They are productivity tools, information lifelines and are central to how successful companies are conducting business. For example, in the past marketers used to have to wait and gather campaign statistics – in this day and age, marketing and sales use mobile apps to track campaigns, manage promotions, track inventory – in real-time!
By now we’ve all heard of Pinterest and have seen how much growth they have experienced since they first popped up on our social media radar a couple years ago. From inception, Pinterest has seen visits skyrocket by 5,124 percent to more than 28 million visits per week in their second year of business. The result? As an organization, they had to move quickly to successfully support their growth spurts, or risk the trap of ‘growing too fast’ and not being able to keep up with the market demands. They did this through automation, agile tools and strong collaboration between developers and all other operations.
In other words, Pinterest was successful because they were able to move quickly and had established an agile development environment early on.
One of the key principles of Agile Development is the ability to handle changing requirements even late in the project, and minimize the risk usually involved in doing so. In fact, in agile projects, it’s vital that the stakeholders can make changes easily at any point in the development lifecycle – from beginning to the end. Tracking and managing these constant changes is vital in order to stay on top of any project and still come in on time and on budget – and with happy stakeholders.
But for any project, it’s important to remember that before agile development comes effective discovery.
Discovery starts with the team—it can include business analysts, designers, developers, business stakeholders and the list can go on. Establishing what stakeholders want can be tricky but a must in the discovery phase—in fact it’s what successful discovery is all about. The team needs to look at: what are the current best practices? What are the current experiences? How can your future app improve these current practices and experiences? Is this feasible? Can it be built? What should be built first? What will be the most valuable functionality?
But discovery goes beyond just asking the questions, it’s important that the time is taken to understand who the people are that you are asking these questions to.
By doing user research, a clearer picture can be painted and an understanding of who your users are is established. User personas can show who the user is, how they currently perform their work and what they would find valuable to have in the future. Create a story map and include what makes your project fun, painful, or confusing for the stakeholder. Do we need to change behavior for the stakeholder? What should the outcomes be? Capture and analyze the problem statement or opportunity so that you are addressing in enough detail to get everyone on the same page.
And don’t forget about your business overall. What will YOUR company gain from building this app? Develop the app in the context of your business objectives to make sure you’re meeting the needs of the company and helping them achieve their overall goals.
Establishing and meeting key performance indicators are vital in figuring out what the right mobile application should look and act like for your organization and your market. Establish a common vision among all team members and stakeholders so everyone is motivated toward the same clearly defined goal. Also make sure everyone is aware of vital constraints – understand and communicate the budget, deadlines, and other limitations to your whole team.
Organizations that implement and utilize agile discovery are more successful at understanding what needs to be built—resulting in more successful projects that deliver higher value features and products at lower costs and higher rates of user satisfaction.
Learn more about Enfocus Solutions and how we can ease your Agile Discovery process.
Collaboration: Working together through Product Delivery (Part 3 of 3)
For Part 1: Easy to Talk About, Much Harder to Achieve, read previous blog post
For Part 2: Working Together through Product Discovery, read previous blog post
In the last blog post we talked about the importance and the opportunities for collaborating during the product discovery phase of the product development lifecycle. In today’s blog post, we take a look at collaboration through the product delivery phase of the product development lifecycle.
Collaboration during Product Delivery
The second track in the dual track agile approach to product development is the product delivery track.
Once a feature has made it onto the product delivery track, it will have been validated for viability and an understanding that the right feature has been defined — but now needs to be built correctly.
Easy right?
Not without collaboration and validation from your development team, your users, your marketing ream, your design team … well, you get the picture. Just the same as product disovery requires a collaborative validation effort to be successful, so does product delivery.
The difference in the product delivery phase is that the focus becomes less of ‘are we building the right product’ — and more of ‘are we building the product right?’
This means the focus shifts towards ensuring a product will be adopted — in other words, the focus is on the usability of a product and ensuring the features that are developed, are developed in such a way that they will actually be used.
User adoption is driven by understanding what the user needs
Once a product reaches the delivery phase, we know that it is the right product, but that does not always mean it will be developed right. To understand how a product can best be developed to fullfill the needs of the market, it’s necessary to go out and talk to the market.
Collaboration with your users is necessary to understanding what they need. But collaboration is not simply a review activity — to collaborate with customers and users, a relationship needs to be establish and they need to be considered a valuable partnership.
At Enfocus Solutions, we typically discuss collaboration as having three different levels:
- Review and Approve: your customers and users provide input on their needs and review and approve a requirement document to ensure their needs are met.
- Engage: your customers and users have complete transparency into the project adn will consistently track, review, and contribute their feedback on decisions and items of interest to them.
- Partnership: your customers and users are considered a partner and actively participate in the design of a solution that meets their needs.
A partnership is what you should aim for, engagement is a great stepping-stone to achieve it, and review and approval is a good starting point but utlimately does not provide you with the collaboration you need to be successful.
Ideally, when on the product delivery track of the product development lifecycle, your customers have already been engaged in the process from product discovery and have become your partners. They are available to help prioritize the features of a product, participate in the design of the product, beta test the product once a prototype has been complete, and provide you with a transparent validation of the product. If your customers view themselves as your parnters in development, they will soon understand that their participation is just as valuable to them as it is you.
The key to making them partners? Show them that their input will have a direct impact on what they receive in your products. Many times users of a product do not see their input as being impactful on the products they give feedback for. As a result, many users are hesitant to really offer their input into what they are really looking for in a product — and when they do, most times they are compelled to do so out of a feeling of frustration, versus the sense of being a partner contributing towards a better product for all. It’s a mistake for companies not to consider the input of their customers in an influential way — decision-making is all too often done outside the scope of those who have insight into the user experience. There needs to be a balance in developing the user experience of a product and including user input, and motivating product users as partners to deliver that input is part of that balance.
Designing beyond the physical product
There is more to user adoption and utility than making sure it has a friendly physical design and appeal. Companies also need to make sure that there are services and options in place to support customers through the adoption of their product. I know I cannot be alone in saying that many times my decision to purchase or keep a product is driven by the amount of support that I know I will get in using it. There are some companies better at this than others – and I’m not going to name specific examples – but I’m sure we can all think of examples of good customer support experiences, and very bad ones, in our lifetime.
Collaboration with your users should not stop once they have simply purchased and the product. Communicate and build relationships with your market past their purchasing to understand what they need to be successful with the product. Do they need a specifid type of training? Do they need more useful manuals? Do they need a better warranty to feel comfortable keeping the product? Send out surveys, make phone calls, send emails, figure out why users like or or don’t like your products.
In today’s market where innovation is advancing at a rate quicker than ever, products are becoming more complex, consumers have more choices, users have more knowledge and stronger opinions, and product teams are racing against their competitors, collaboration is quickly becoming the foundation upon which all product development processes should be built.
[cta id=”7457″]
Two new webinars: Agile Business Transformation and Agile & ITIL
Join us for two of the newest webinars in our Enfocus Solutions webinar series!
Agile Business Transformation
May 15th 2014 at 12 PM Eastern Standard Time (US & Canada)
Agile has become mainstream for developing software. Organizations that have adopted agile have seen improvements in quality, cycle time, and customer satisfaction. Standish Group research shows that agile projects are three times more successful than traditional plan driven projects.
However using Agile Development practices does not make an agile organization. Frequent delivery of software provides little value if the software cannot be deployed because of rigid release and change management processes. Another significant challenge facing enterprises is how to coordinate agile teams across multiple projects in multi-disciplined environments. Companies are appointing agile coaches to individual projects, but there is little or no company-wide coordination. In addition, little has been done to help transform the business to be able to respond more rapidly to change.
Agile transformation requires focus on four key areas:
- Agile Discovery
- Agile Delivery
- DevOps
- Agile Business Change
In this webinar, John Parker will address these four topics with heavy emphasis on Agile Discovery and Agile Business Change. He will also discuss how BAs and PMs will need to transform to operate in the agile environment.
Target Audience: PMOs, Agile Project Managers, Agile Business Analysts, Enterprise Portfolio Managers, and Product Owners
Agile & ITIL
June 10th 2014 at 12 PM Eastern Standard Time (US & Canada)
At first Agile and ITIL seem at odds because of the rigid release and change management process of ITIL and the rapid delivery of software in agile. However, the two frameworks are actually quite complimentary.
In this webinar, John Parker will describe how the design of End-to-End business services works in an agile development environment and how agile can easily be integrated into ITIL change and release management processes.
He will address the following topics:
- Managing Services instead of Products
- Defining Agile Services
- Service Portfolio Management
- Economic Benefit of Small Batch Sizes
- Design Coordination Management
- Creating a Service Design Package
- Service Transition Management
- Creating RFCs
- Dealing with Release and Change Management
- Continuous Delivery
- Achieving Agility and Operational Excellence
- Requirements: The Old way and the new way
- Using ITIL for Scaling Agile
Audience: ITSM Service Managers, Agile Product Owners, Portfolio Mangers, PMO Directors, and Program Managers
Collaboration: Working together through Product Discovery (Part 2)
For Part 1: Easy to Talk About, Much Harder to Achieve, read previous blog post
The question of when teams need to collaborate in the product development lifecycle has an easy answer: always. But, there are key activities that take place within a product development lifecycle where collaboration is absolutely necessary.
Collaboration through Product Discovery and Product Delivery
There is an emerging concept in product management called dual-track agile that essentially looks at product development as two tracks: the product discovery track, and the product delivery track.
On the product discovery track, teams collaborate to understand what the right product is to build. On the product delivery track, teams collaborate to make sure the product is built right. (Source: Jeff Patton, www.agileproductdesign.com)
Both tracks require a foundation of collaboration and validation in order to be successful.
In today’s blog post we’re going to talk about the importance of collaboration through the product discovery phase of product development—when teams are trying to figure out ‘what’ actually needs to be built in order to be of value to the market.
Traditionally, in the product development lifecycle the validation of a product doesn’t tend to happen until after the launch of a product or during the validation of a developed prototype. Usually by that time, a significant amount time and money has already been spent on defining and developing the product to some degree—without completely validating that the product will meet a market need.
On the product discovery track of the dual track agile approach, the focus is on validation, validation, and validation. Validation that the right problem has been identified, validation that the right solution has been decided upon, and validation that the solution being proposed is a beneficial opportunity for the company to invest in. Validation cannot be done without collaboration.
Remember that statistic we mentioned the other day? That 80% of a product’s features are never or infrequently used? Well here’s another stat to think about—of the billions of dollars in consumer electronics that are retuned annually, only about 5% of those are because of defects. And what that really says is that the main reason people are returning products is simply because they are not what they expected or needed. And it’s not just because they were unwanted Christmas or birthday presents. Returning a product because it is not what we needed is something we can all probably relate to—how many of us can say that every product we have purchased has met our needs perfectly? Or that we have never returned a product once purchased because once we got it home ‘it was way more complex than it needed to be.’ People want products that solve their problems and are easy to use—in other words, they want usability and utility.
Product discovery helps us develop products that will solve a real problem—and make sure the features we do develop are meaningful and valuable for the target market. And that’s because the product discovery track’s entire purpose is to eliminate all potential product features that will not solve real market problems. In the world of lean, it means that we are eliminating the ‘waste.’
How does product discovery work?
During product discovery, validation is the name of the game—and in order to validate, you need to collaborate.
The right market problems need to be identified and validated.
There is no value, or business sense really, in developing a product that solves a non-existent problem. It’s a lose-lose situation—the market gains nothing and the company developing the product could possibly lose everything.
One of the key activities within the product discovery phase, and one that almost every product manager is responsible for, is to ensure real market problems are being identified to solve. How to identify the problems can be the tricky part—the list of potential problems can sometimes seem endless and the effort to sift through them all to identify the real ones can often seem overwhelming. There are problems reported directly from existing customers in the form of complaints, there are direct requests for new features from existing customers, the request for new products from potential customers, the market studies that indicate the need for this or for that for market segment x or market segment y—you get the picture and most likely relate. Identifying the real problems to solve can be a daunting task. But if it’s not done and the right problem is not defined then there can be an entire domino effect into the solution that is eventually defined, then developed, and then released—most likely into a market that will not want it.
The source for gathering problems can be many in product management: specific feature requests from existing customers, product requests from potential customers, focus group results, market studies, customer interviews, user conferences, and the list can really go on. But receiving problems and understanding what problems need to be resolved in order to be of value to a customer is a different ball game.
We have all probably heard the famous ‘horses’ quote by Henry Ford:
“If I had asked people what they wanted, they would have said faster horses.”
Whether or not that statement is actually accurate, we cannot be sure—but I think the point of the quote is important and valid. And that is: the problems we receive from our customers are not always the problems that need solving. They are however, problems that need analyzing. Many times what we receive from customers are the symptoms of the real problem or a solution they have already thought up in the form of a feature request—the product discovery team then needs to take those problems to analyze them, categorize them and identify where the patterns lie—and what the real problems are that need solving. To do that effectively (and efficiently) requires validation through collaboration. Problems need to be analyzed from different perspectives, and everyone on the team needs to be on the same page about what the valid market problems are that they will be solving with a new feature or product. If only one person undertakes this activity, or there is too much of a reliance on the market to dictate the real problems, there is a serious risk that the real problem will be overlooked and the wrong solution developed.
To identify market problems, product teams must work together and with their customers and users to understand, analyze and then validate what the real problems are that need solving.
The solution that solves the problem needs to be validated too.
When you start thinking about how to solve a problem, there is a good chance you will think of more than one way to do it. In fact there is almost always more than one way a problem can be solved.
In product management, there are also factors that influence how a problem can be solved—the budget a company has to develop or enhance a product, the market segment the product is being developed for, the amount of time a company has to develop the product before their competitor does, and even the level of complexity and effort that should be used to solve a problem. Some problems we may need to develop a new generation of product for, other problems we may only need to apply small enhancement and maintenance upgrades to. Both approaches could result in the same level of value and satisfaction for a user.
Collaboratively analyzing problems and coming up with the most effective solution is all part of determining and validating the solution to an identified problem. Problems are solved more effectively when done by a team of people, and solutions are more valuable when they are constantly validated throughout the development lifecycle.
Let’s talk about why collaboration is so important when it comes to defining valuable solutions.
As individuals, we simply don’t have all of the different perspectives, experiences, and knowledge to brainstorm all potential problems and solutions ourselves. Our perspectives are filtered by our past experiences, and we can very quickly fall into the traps of confirmation bias and functional fixedness.
Confirmation bias is a human tendency that happens when we already think we know what the solution or problem is without really examining if we might be wrong. Subconsciously, we do it all the time—we look for evidence to support what we already believe. We seem to remember only the times our favorite sports team has won yet tend to easily forget about all those times they have lost—or maybe we only tend to research the information to confirm our already formed opinions when it comes to write a new article. Or have you ever noticed that when you buy a new product—maybe the newest phone, or a new car, that you start to see it everywhere you go? That’s confirmation bias—it’s us looking for evidence that we purchased the right product. In product management, confirmation bias can present a real threat to both understanding what the real problem is, or determining what the best solution is to build when it is undertaken by only one person, and not questioned by the team.
We also tend to get trapped in a cycle of what is called functional fixedness—meaning that we tend to approach solving problems in the same way over and over again, especially if we are familiar with the components of it.
Want to test it out and take a break from reading? Try the following test designed by psychologist Karl Duncker to illustrate the effects of functional fixedness:
Given the following items:
How could you fix the candle to the wall so that the candle’s wax does not drip onto the floor below?
Well if you are like most people, resolving this problem is a challenge. Often, individuals alone cannot approach a problem from different angles to fully explore all viable solutions. In the case of the thumbtacks, matches, and the candle—many people get stuck thinking only of the objects as they are presented, which are in the boxes. But remove the thumbtacks or matches from the boxes and ask them the same question, and they are more likely to get it right:
To fix the candle to the wall so the wax does not drip, remove the thumbtacks from the box, place the candle in the box, and tack the box to the wall so it catches any dripping wax.
Most individuals get stuck on thinking about the problem in only one way—but when they are allowed to collaborate with others to discuss possible solutions, many tend to get the answer eventually right. When we apply functional fixedness to product management, we can immediately start to see why brainstorming solutions needs to be a collaborative effort—it is too easy for a single person to miss a potential solution.
We also can’t forget about the role customers and users of a target market can play in validating the solutions we come up with—before they ever make it to the market. The product discovery phase of a product’s development is arguably the most important time to engage your customers and end-users in understanding the problem and what the best solution will be. Collaborate with your market by inviting them in for focus groups, calling them up to elaborate on requests or complaints—drill further down into their issues, and ask them to contribute towards or rate the various solutions your team has generated.
Before any product idea moves into development you want to have it validated by the market you are trying to sell it to—doing so will save you time, money, and many frustrations down the road.
Once the solution is validated, the opportunity needs to be as well.
The development of a product needs to be mutually beneficial for all stakeholders involved—the customers, the users, and the company investing in the development of it. The product development team may have thought of a really great feature to solve a real problem with—but that doesn’t always mean it will be beneficial for the company to develop it. Thought and consideration needs to be put into how an identified solution can also help the company achieve its goals. No feature or product should be developed until it is determined it can actually be developed successfully.
To do this, a collaboration and validation process needs to take place with the relevant internal stakeholders to determine that the identified opportunity is one that is worth a company undertaking. The team together needs to answer the questions: ‘how will solving this problem help our business?’, and ‘why us? What makes our company capable of solving this problem successfully?’
Stay tuned for the next blog post that talks about collaboration through the next phase of the product development lifeycle: product delivery.
Read Part 3: Working Together Through Product Delivery
[cta id=”7443″]