PMI Requirements Management Community

PMI Requirements Management Community

Achieving Successful Project Results Through Better Project Management and Business Analysis Practices

John Parker, Chief Visionary Officer, Enfocus Solutions Inc. July 26, 2013

John E. Parker Previous Positions

–  President and CEO of Enfocus Solutions Inc. inception through March 2013

–  EVP and Cofounder, Spectrum Consulting Group –  EVP and CTO, MAXIMUS Inc. –  Outsourced CIO for HSHS (Large Healthcare

System) –  KPMG Partner

Expertise –  IT Strategic Planning –  Business Architecture –  Business Analysis and Requirements Engineering –  Project and Portfolio Management –  Recovering Troubled and Challenged Projects –  Development Methodologies (Agile, Waterfall, RUP,

Design First, FDD, TDD) –  Business Process Improvement and Management

Chief Visionary Officer Enfocus Solutions Inc.

Topics •  Business Analysis: Why is it so important for Project Managers

•  Recommended Practices for Business Analysis

•  Recommended Practices for Developing Requirements

•  Reducing Business Analysis Risk

•  Questions and Answers

Top 10 Reasons IT Projects Fail

1. Lack of user involvement

2. Lack of transparency

3. Poor or incomplete requirements

4. Changing requirements

5. Lack of business alignment

6. Lack of executive support

7. Significant scope creep

8. Failed user adoption

9.  Improper solution

10. Poor testing and quality assurance

Poor Business Analysis is the Root Cause of Most Project Failures.

Successful 32%

Challenged 44%

Failed 24%

Source: Standish Chaos Report

Waste: 45% of Functionality is Never Used

Source: Standish Group Report at XP Conference 2002 by Jim Johnson

Major source of budget and schedule overruns

6

What Does the Industry Research Say? Poor Business Analysis is Costly

•  Companies with poor business analysis will have 3 times as many project failures as successes. (Ellis, BA Benchmark Report, 2009)

•  Companies pay a premium of as much as 60% on time and budget when they use poor requirement practices on their projects. (Ellis, BA Benchmark Report, 2009)

•  Requirements processes are the source of most serious quality problems. (Weinburg, 1997)

•  50% of defects are related to requirement errors. (Schwabber, 2006)

•  Getting requirements right early in the project can save you one-third or more of your overall project budget. (Hooks and Farry, 2001)

•  90% of projects that deliver on-time and on-budget did not deliver expected business outcomes. (Burdette, 2013)

•  On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. (Forrester, 2012)

7

Business Analysis is More than Requirements

Requirements •  Requirements Collection •  Requirements Development •  Requirements Management

Enterprise Analysis •  Problem Analysis •  Business Case •  Impact Assessment

Organization and Process Change •  Business Process Modeling •  Business Process Improvement •  Stakeholder Analysis and Communications •  Organizational Readiness •  Organizational Change Management

Manage Delivery of Value •  Solution Assessment and Validation •  Business Benefits Realization •  Enterprise Portfolio Management

8

Requires: - Understanding the Problem - Developing a shared vision - Assessing the Capability Gaps - Identifying Required Changes - Defining SMART Objectives - Eliciting stakeholder needs - Defining clear objectives - Adapting to changes in requirement - Assessing and validating the solution

Ensuring the Project Delivers Expected Benefits

Recommended Practices •  Business Analysis should be considered a project core competency. •  BA deliverables should be clearly defined. •  BAs should is a member of the project team and report to the PM. •  There should be only one WBS. •  Stakeholder communications should be coordinated. •  Projects should define all requirement types in PMBOK. •  Quality Management and Solution Assessment and Validation

activities should be coordinated.

Best Practices for Business Analysis

Successful Projects Require

Good Business Analysis Collaboration •  Good business analysis helps ensure

the right solution is developed for the right reasons to solve the right problem.

•  By focusing on an organization's business objectives, tracing them to a defined solution scope with the necessary set of features and then tracing further to detailed requirements, Business Analysts ensure that the efforts are focused on the right features and requirements.

•  Business Analysts work iteratively and collaboratively with business and technical stakeholders to elicit, develop, and validate requirements.

•  Because stakeholders represent groups of people from different backgrounds, business domains and authority levels, communication can be challenging.

•  Analysts must determine which sets of requirements are relevant to particular stakeholder groups and present requirements in the appropriate format for the audience to validate and to approve the requirements.

Business Analysis: The Big Picture Business

Architecture Portfolio

Management

Project Charter

What is the problem and need?

What is the Business Case?

What is the impact?

How are we going to build it?

Solution Scope��(Features)

Bundles ��(Requirements)

Releases (Requirements)

What changes are needed?

How are we going to deploy it?

Verification – Are we building the solution right?

Verification��& Validation Validation – Are we building

the right solution?

Business SMEs

Executive Sponsor

Governance Boards

Development

Test

Deployment

Users

Technical SMEs

What is Solution Scope?

Project Scope Solution Scope Project Scope includes all the work needed to create a product or deliver a service or result. Project Scope defines the work required to create and deploy the product. The project scope statement is prepared by the project manager.

Solution Scope describes the characteristics, features, or functions of the product or service to be built. Solution scope is all about the solution to be implemented: how will it look, how will it function, and other characteristics. A business analyst prepares the product or solution scope.

Work Breakdown Structure (PMBOK 5.4)

Solution Scope (BABOK 5.4)

13

Two Key Concepts: Features and Bundles These Concepts Apply to Both Agile and Plan Driven Development

Features Bundles What is needed to solve the business problem?

What is the most efficient way to build or buy it?

•  Managing features works for both Agile and Waterfall development. •  Project managers can create a WBS using features and bundles •  Managing features and bundles controls scope, controls quality, and ensures

value is delivered to the business

14

Features The Key to Managing Scope and Delivering Business Value

1.  The basic principle is to reduce a complex project into small, easy-to-understand units called features. This means taking one small step at a time rather than tackling the whole project in one go.

2.  Define features by decomposing business objectives or through impact or concept mapping.

3.  Solution Scope = The List of Features 4.  For each feature, assign a business owner and an

analyst. 5.  Use features to elicit and develop requirements. 6.  Prioritize features by business value and

Implementation complexity. 7.  Features work for both Agile and Waterfall

development. Features are often called Epics in agile development.

8.  Features do not necessarily equate to how the solution will be implemented.

9.  Features should comply with INVEST. 10. Features should be managed from inception to delivery.

Carefully defined Features are key to

prevent scope creep, deliver value, and serve as a basis for gathering

user needs and developing requirement

specifications.

Elicitation and Development of Requirements

Providing a Solution to Meet Business Needs

Business Needs

Required Changes

Processes Data

People Technology

Procedures and Rules

16

Bundles

The Key to Managing Software Quality and Delivery

1.  The basic principle is to allocate solution requirements to solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team.

2.  Bundles are often defined by module, team, service, or component or acquisition method.

3.  Bundles often equate to sprints in agile development. A group of bundles equates to a release.

4.  All of the requirements in bundle are generally validated together.

5.  Bundles contain not only requirements but all related data including: requirement patterns, requirement attributes, acceptance criteria, visualizations, attachments, related use cases, related business rules, and related user needs and scenarios.

6.  Bundles have lifecycle events that are used to trace requirements through the development lifecycle.

7.  Bundles are managed from creation to delivery.

Assessment and Validation of Solutions

17

Business Analysis Value Streams Ideation to Features (Enterprise Analysis) •  Gain an understanding of the

problem including what is causing the problem.

•  Define clear objectives for moving forward.

•  Identify and evaluate options to solve the problem.

•  Analyze the impact of the problem on stakeholders, processes, data, and technology.

•  Decompose the solution into a set of features to achieve the objectives.

•  Prepare the business case for undertaking the project.

Features to Requirements (Requirements Analysis) •  Use the features to elicit

needs from impacted stakeholders.

•  Analyze stakeholder needs and develop requirements to address needs.

•  Trace each requirement to stakeholder needs.

•  Validate the requirements with the business, developers, and testers.

•  Elaborate the requirements with additional detail such as visualizations, business rules, etc.

•  Bundle the requirements for implementation.

Requirements to Value (Solution Assessment and Validation) •  Collaborate with the

implementation team to ensure requirements are understood.

•  Evaluate development artifacts to ensure that they deliver expected business value and address the requirements.

•  Define transition requirements.

•  Assess organizational readiness.

•  Assess benefits realization.

Understand Problem and Need

Conceptualize Solution

Situation Analysis

Organizational Context

Vision

Constraints, Assumptions

& Risks

Capability Gaps

Objectives Impact Assessment

Solution Scope

(Features)

Ideation to Features

Analyze Stakeholders and Needs

Develop Solution Requirements

Allocate Requirements

Stakeholder Analysis

Stakeholder Needs

Stakeholder Scenarios

Stakeholder Personas

Functional Requirements

Nonfunctional Requirements

Requirement Elaboration (Attributes)

Visualization

Requirement Bundles

Acceptance Criteria

Lifecycle Events

Requirements Management

Features to Requirements

Assess and Validate Solution

Transition and Deployment

Verification Validation User

Acceptance Testing

Defect Resolution

Transition Requirements

Organizational Readiness

Benefits Realization

Features to Value

19

Requirements V-Model

Requirements Development

PMBOK Requirement Types •  Business requirements, which describe the higher-level needs of the organization as a

whole, such as the business issues or opportunities, and the reasons why a project has been undertaken.

•  Stakeholder requirements, which describe needs of a stakeholder or stakeholder group.

•  Solution requirements, which describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements:

–  Functional requirements describe the behaviors of the product. Examples include processes, data, and interactions with the product.

–  Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.

•  Transition requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state.

•  Project requirements, which describe the actions, processes, or other conditions the project needs to meet.

•  Quality requirements, which capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.

22

Requirement Challenges •  Customers and end users do not know what they want and can not express

what they want. •  Software requirements are often difficult to express in writing. •  There is no agreement on how to document requirements, so teams just march

ahead with designing and building the product without having requirements. •  Developing good requirements is difficult and time-consuming. Some people do

not view requirements as progress and just want to get on with “real work” of building the product.

•  Business dynamics move rapidly resulting in constantly changing requirements. •  Many organizations are simply not equipped to deal with the needed

adjustments in product vision to meet business needs. •  Solving business needs generally requires more than changes to software

(business process changes, alignment of responsibilities, etc.) and these changes are often ignored as teams tends to focus primarily on the technology.

23

Large Documents or a Wall of Post-It Notes

Large Requirement Documents A Wall of Post-It Notes

Requirement data is too dynamic to use either of these methods.

How can this support changing requirements?

Can you imagine what the chief compliance officer might say when told these are

requirements for one of our strategic systems?

Waterfall Development Agile Development

24

Manage Data not Documents

Requirements

Elicit

Analyze

Elaborate

Validate

Requirements consist of •  User story or “shall” statement •  Requirement attributes •  Relationships to other objects •  Prioritization •  Estimates •  Business rules •  Traceability •  Visualizations •  Dependencies •  Review comments •  Test cases and acceptance criteria •  Action items and work tasks •  Requirement change history

•  Creating large requirement documents is an archaic practice brought forward from the 70s.

•  Requirement data is way too dynamic to be managed using a word processing or spreadsheet software.

•  Creating large paper requirements documents is slow, inefficient, costly, and simply a poor practice and is often the cause of failed or challenged projects

Requirement Documents

25

Manage Data not Documents Continued

The traditional requirements approach is to create large paper documents that contain business, user, functional, and nonfunctional requirements. This document-based approach for developing requirements has numerous limitations:

•  Requirement change is inevitable. It is simply not practical to keep up the amount of requirement changes that occur using large documents.

•  Requirements verification and validation should be continuous process where stakeholders constantly review and revise requirements until they are clear and at the right level of detail. Waiting for the release of large requirements documents causes this verification and validation to be discontinuous and often ineffective. Doing too many requirements without validating them inevitably drives a good bit of the productivity loss that continues to hamper software projects.

•  Requirements often link to other information such as business rules or other dependent requirements. It is very difficult to maintain these relationships using documents.

•  Various types of visualizations are often used to create clear requirement. Some times even video, audio, and photos are used. This information is often impossible or impractical to embed in a Word Document.

•  Requirements need to be allocated to bundles by team, release, or component. This usually requires the creation of an SRS for each bundle. Cutting and pasting this information from the BRD is inefficient and error prone.

•  It is difficult for multiple project participants to develop and modify the requirements. This is even worse when they are geographically separated.

•  Communicating changes to all affected team members is a manual process. If developers do not have the most recent requirement, they may develop the wrong thing resulting in significant rework.

•  It’s not easy to store supplementary information (attributes) about each requirement.


26

Manage Data not Documents Continued

•  Requirements are often classified with tags or other data. This information is vital in performing analysis and for prioritization. This is not practical with large documents.

•  It is often necessary to track the status of individual requirements. This is almost impossible using large requirement documents.

•  Requirements traceability is very difficult using Word based requirements documents.

•  Concurrently managing sets of requirements that are planned for different releases or for related products is difficult. When a requirement is deferred from one release to another, an analyst needs to move it from one bundle or SRS to another.

•  It is difficult to manage and store requirements that were proposed but rejected This is further complicated when you consider other scenarios such as removing requirements from a baseline. Sometimes it is necessary to remember that these requirements had been proposed, because they might be back in scope one day.

•  Reusing a requirement means that the analyst must copy the text from the original bundle (SRS) into another bundle where it will be reused.

•  It is difficult to keep documents current and synchronized. The effort tying to keep the documents synchronized and ensuring that everyone has the most recent version can be substantial. This practice is both costly and wasteful.


27

Requirements Development Process Requirements are developed iteratively and incrementally

Activity Description Elicitation Collecting information from stakeholders and other sources.

Information collected includes stakeholder needs, user requirements, constraints, risks, performance goals, and success criteria.

Analysis Analysis is the process that involves assessing and investigating the information gathered from elicitation to determine the real requirements.

Specification Specification involves the tasks of writing the requirements in clear and concise manner so they can be understood by both business and technical stakeholders.

Elaboration Elaboration involves adding additional details such as visualizations, business rules, and clarifying details to make the requirements more understandable.

Verification and Validation

Requirements are verified and validated to ensure they represent the true business need and that they are understood by the development team, and can be tested by the testing team.

28

Iterative and Incremental Iterative Incremental

When you work iteratively you build what you can in one iteration, then review it and improve it in next iteration and so on until its finished. Requirements are built by going through a continuous set of reviews by stakeholders and the business analyst. Business Analysts receive comments from stakeholders, make improvements to the requirements, and ask for comments

When you work incrementally you add components piece by piece until you are finished. Requirements are built in layers, starting with high level business objectives, decomposed into features, functional requirements, and various layers of detail for each requirement.

Incremental Requirement Development

Example of Requirement with Attribute

•  Requirement: The system shall provide an online employee directory.

•  Attributes: •  Shall display employee last name, first name, location, and

employee ID number. •  Shall be sorted and displayed in alphabetical order by last name. •  Shall be able to search for an employee using the last name. •  Shall comply with corporate usability and design standards.

Requirements details are added to clarify requirements. In agile development, this process called “conversations” and is done just-in-time for development. btw- This also works for plan-driven projects also.

What Level of Detail is Needed?

•  Customers are extensively involved

•  Developers have considerable domain experience

•  Precedents are available •  A package solution will be used

•  Development will be outsourced

•  Project team members are geographically dispersed

•  Testing will be based on requirements

•  Accurate estimates are needed •  Requirements traceability is

needed

Less Detail More Detail

Determining the level of detail must balance cost vs. risk. •  Too much detail adds unnecessary cost to the project. •  Not enough detail leaves decisions about requirements specifics to the

development team often resulting in costly rework and associated schedule and budget overruns.

The Key to Good Requirements is the Level of Detail

32

Collaborative Requirements

Collaboration is business analysts, business stakeholders, users and technical stakeholders working together to develop requirements. The various parties work together by sharing knowledge, learning, and building consensus in terms of what is needed to build the solution.

One leading consulting firm found that they were able to capture 93-95% of the functionality by using a collaborative requirements approach versus only 65% when a more traditional interviewing method was used. In addition, there was significantly higher user satisfaction for solutions that were built with collaborative requirements.

33

Reducing Business Analysis Risk 14 Important Recommendations for Project Managers

1.  Ensure that the BA role is documented and understood.

2.  Do not omit critical up-front business analysis activities such as problem definition, solution scope, and the business case.

3.  Increase business analysis maturity – encourage standardization of business analysis practices.

4.  Ensure that the problem is understood before starting to define requirements.

5.  Ensure that the solution scope is defined before starting to define solution requirements. Do not use requirements to define solution scope!!!

6.  Require a Business Analysis Plan that addresses: –  Elicitation –  Requirements Management –  Stakeholder Engagement and Communications –  Requirements Traceability –  Solution Assessment and Validation

34

Reducing Business Analysis Risk 14 Important Recommendations for Project Managers

7.  Ensure that all five types of requirements are defined. –  Business Requirements –  Stakeholder Requirements –  Functional Requirements –  Nonfunctional Requirements –  Transition Requirements

8.  Develop requirements collaboratively – both user and technical input are needed.

9.  Ensure that all key stakeholders, including users are engaged and involved.

10.  Develop requirements with just enough detail, just in time.

11.  Ensure that Business Analysis deliverables are defined and included in the WBS.

12.  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.

13.  Work with the BA in properly defining the solution assessment and validation approach and integrate into WBS.

14.  Use a proven business analysis tool – do not rely on Microsoft Word or Excel or on a simple requirements management tool.

35

Thank you for your time!

Follow this link: http://info.enfocussolutions.com/webinar-pmi-713

To get your free assets: –  PDF of this presentation –  Writing Strong Requirements –  Requirement Quality Checklist –  Guide to Project Manager and Business Analyst

Collaboration

For any questions, you can also email my associate Andrea Palten at [email protected]

Enfocus Requirements Suite™

Q & A

PMI Requirements Management Community

Documents

Transcript of PMI Requirements Management Community