how to integrate business analysis into the project

How to Integrate Business Analysis into the Project Management Process for

Spectacular Results

1 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

John E. Parker (Introduction) •  Chief Visionary Officer of Enfocus Solutions Inc. •  Previous Positions

o  President and CEO of Enfocus Solutions Inc. inception through February 2013

o  EVP and Cofounder, Spectrum Consulting Group o  EVP and CTO, MAXIMUS Inc. o  Outsourced CIO for HSHS (Large Healthcare System) o  KPMG Partner

•  Expertise o  IT Strategic Planning o  Business Analysis o  Recovering Troubled and Challenged Projects o  Enterprise Architecture o  Development Methodologies (Agile, Waterfall, RUP, Design

First, FDD, TDD) o  Financial and Cost Benefit Analyses o  Business Process Improvement, Reengineering, and

Management


Why Focus on Integrating PM and BA?

•  Deliver More Successful Projects o  Eliminate major causes of challenged or failed projects (Poor requirements, Lack of User Input,

Changing Requirements) o  Reduce Scope Creep (Significant cause of project delays and cost overruns)

•  Eliminate Waste o  Less rework – (40% of project costs is related to rework, 70% of this is from poor requirements) o  Eliminate unnecessary functionality (Standish Group research shows that 49% of functionality is never

used) •  Deliver More Business Value

o  Realize more benefits through Benefits Realization Management (Studies show 3x improvement when benefits realization is applied)

o  Obtain better understanding of business needs •  Achieve Results Faster

o  Identify and deliver quick wins o  Deliver high value functionality earlier through feature prioritization

•  Provide Better Solutions o  Gain a better understanding of business needs o  Understand various stakeholder perspectives o  Achieve higher user acceptance and support


Strategic Partners How project managers and business analysts can work together

Project Manager

Business Analyst

The Project Manager focuses on comple5ng the project on 5me and on budget.

-‐ Scope -‐ Schedule -‐ Budget -‐ Quality -‐ Resources The Business Analyst focuses on

delivering business value and ensuring that the stakeholders needs are met.

-‐ Business alignment -‐ Stakeholder needs -‐ Requirements -‐ Organiza5onal change -‐ Process improvements -‐ Benefits realiza5on


Project Management v Business Analysis

Project Management Business Analysis

Focus Manage costs, inputs, schedule, resources, and deliverables.

Business outcomes and value, solution scope, stakeholder needs, and solution requirements.

Deliverables WBS, work plan, costs, estimates, progress reports, milestones, issues, earned value, PERT charts, etc.

Problem Statement, Business Case, Solution Scope, Stakeholder Needs Analysis, Solution Requirements Document, Solution Defect Reports

Measures of Success

On-time, on-budget, delivery of specified change enabler (e.g., system, process), risk management

Solution achieves business outcomes and delivers and satisfies stakeholder’s needs.

Processes Initiating, Planning, Executing, Controlling, Situation

Situation Analysis, Elicitation, Needs Analysis, Requirements Development, , Requirements Management, Solution Assessment and Validation

Accountability Is accountable to the business sponsor for project deliverables

Is accountable to the business sponsor for ensuing that business needs are met

Timeline From project planning to implementation.

From problem identification through benefits realization.


Apply Lean Principles to Project and Solution

Project Management

•  Eliminate non-value added activities from project

•  Clearly define responsibilities •  Simplify WBS •  Eliminate waste from project

activities o  Waiting o  Over-Processing o  Defects o  Over-Production o  Excess Inventory o  Transportation o  Excess Motion

•  Ensure lean software development practices are used

Business Analysis

•  Eliminate low-value features and functions from solution

•  Avoid over-engineering features •  Remove NVA from supporting

business processes •  Prevent gold-plating of requirements •  Define right level of detail for

requirements •  Reduce rework through defining clear

and complete requirements •  Deliver requirements just-in-time for

development •  Manage data not documents


Good Business Analysis

•  Focuses on achievement of business outcomes and enablement of business change.

•  Performs analysis and evaluation not simply takes notes.

•  Serves as the knowledge manager for the solution by providing advice, facilitating discussions and decisions, and promoting collaboration between business and technical stakeholders.

•  Works 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.

•  Collaborating with stakeholders to build a knowledgebase of what problem is being solved and the solution that will solve the problem.


Enablers for Effective Business Analysis

•  A proven process that can work for all types of projects o  Agile Development o  Plan-Driven o  Acquisition of purchased solutions o  Maintenance o  Outsourced

•  A single repository to store and manage all business analysis and requirements knowledge and making this knowledge accessible to: o  Executives o  Project Management o  Business Stakeholders o  Developers o  Testers o  Other Technical Stakeholders

•  Clearly defined role and working with partnership with project manager •  Effective collaboration among business and technical stakeholders


Manage Data Not Documents

Requirement Documents


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


Manage Data not Documents

Requirements

Elicit

Analyze

Elaborate

Validate

Requirements consist of •  User story or “shall” statement •  Requirement aRributes •  Rela5onships to other objects •  Priori5za5on •  Es5mates •  Business rules •  Traceability •  Visualiza5ons •  Dependencies •  Review comments •  Test cases and acceptance criteria •  Ac5on items and work tasks •  Requirement change history

•  Crea5ng large requirement documents is an archaic prac5ce brought forward from the 70s.

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

•  CreaDng large paper requirements documents is slow, inefficient, costly, and simply a poor pracDce and is oHen the cause of failed or challenged projects



Manage Data not Documents

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:

•  Keeping Documents Current and Synchronized is very problematic

•  Getting Feedback from Stakeholders is slow and inefficient

•  Communicating Changes to Team Members and Stakeholders is Inefficient

•  Requirements are often more than text and are linked to models or prototypes which is difficult to do within documents

•  Requirements need to be regrouped for building the solution.

•  Requirements traceability is difficult to achieve.


Not using Requirements Management SoUware to develop and manage requirements places a project at great risk!!!


Start with Right Inputs


Start with the Right Inputs The Inputs of the Project Charter

1.  Project Statement of Work

o  Business Need o  Product Scope Description o  Strategic Plan

2.  Business Case 3.  Contract 4.  Enterprise Environmental Factors

o  Regulations and Standards o  Culture o  Marketplace Conditions

5.  Organizational Process Assets

Source: PMBOK Version 5

How can you create a valid project charter if you do not have the right inputs?


What is Solution Scope?

Project Scope SoluDon 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.

Solu5on Scope describes the characteris5cs, features, or func5ons of the product or service to be built. Solu5on scope is all about the solu5on to be implemented: how will it look, how will it func5on, and other characteris5cs. A business analyst prepares the product or soluDon scope.

Work Breakdown Structure (PMBOK 5.4)

SoluDon Scope (BABOK 5.4)


Solution Scope

Business Need or Problem and Organiza5onal Context

Business Objec5ves Business Objec5ves Business Objec5ves

Feature

Feature

Feature

Feature

Feature

Feature

Feature

Feature

Feature

Feature

Feature

Feature

Included Features Descoped Features

People Process Technology Data Governance

Impact Analysis


Creating the WBS


Three Key Concepts: Features, Bundles & Releases These Concepts Apply to Both Agile and Plan Driven Development

Features Bundles What is needed to solve the business problem or need?

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, bundles, and releases •  Managing features and bundles controls scope, controls quality, and ensures value is

delivered to the business

Releases How and when should it be

delivered?

Define and Design Build and Test Deploy


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 5me rather than tackling the whole project in one go.

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

3.  Solu5on 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.  Priori5ze features by business value and Implementa5on

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

Features are oUen called Epics in agile development. 8.  Features do not necessarily equate to how the solu5on

will be implemented. 9.  Features should comply with INVEST. 10. Features should be managed from incep5on 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

specifica5ons.

ElicitaDon and Development of Requirements


Bundles The Key to Managing Software Quality and Delivery

1.  The basic principle is to allocate solu5on requirements to solu5on components and development itera5ons in order to maximize the possible business value given the op5ons and alterna5ves generated by the design team.

2.  Bundles are oUen defined by module, team, service, or component or acquisi5on method.

3.  Bundles oUen 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 paRerns, requirement aRributes, acceptance criteria, visualiza5ons, aRachments, 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 crea5on to delivery.

Assessment and ValidaDon of SoluDons


Releases The Key to Delivery of Value

1.  The basic principle is to allocate func5onality and deliver value in a smooth and controlled way..

2.  Roadmaps are oUen used to link Features to Releases. 3.  Transi5on requirements are defined for each release. 4.  Organiza5onal readiness reviews are conducted to ensure

that the organiza5on is ready to receive the release. 5.  Release stakeholders may be different than the stakeholders

for Features and Bundles. For example, Support and Opera5ons, and Release Management resources are much more involved in Releases. However, these resources also need visibility into Features and Bundles to be successful.

6.  The key to improving IT implementa5on outcomes is to manage a release as a program rather than as just a set of pre-‐deployment ac5vi5es.

7.  Release management should connect all release components and track all dependencies to the ac5vi5es of interrelated projects.

Ensuring a Smooth TransiDon and Deployment


WBS Showing Features, Bundles & Releases

WBSProject Management

Define and Design

Build and Test

Transition and DeploymentRelease 1

Release 2

Bundle 1

Bundle 2

Bundle 3

Bundle 4

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

integration ManagementProject Charter

Kickoff Meeting Presentation

Time ManagementProject Schedule

Cost ManagementProject Budget

Cost Estimates

HR Management

Roles and Responsibilities

Project Status Reports

Meeting Notes

Communications ManagementStakeholder Register

Team Training Plan

HR Plan

Quality Management

Quality Management Plan

User Acceptance Test

Solution

Time Sheets

Feature 6


Writing Clear and Complete Requirements


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. •  Organizations do not understand the differences between business,

stakeholder, solution, and transition requirements. •  There is no agreement on how to document requirements, so teams just

move forward with building the product without requirements. •  Developing good requirements is difficult and time-consuming. Some

people do not view requirements as meaningful and just want to get on with the “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 part of the solution.


Common Requirement Mishaps

1.  Requirements are missing or incomplete 2.  Requirements are defined before the business problem is understood 3.  The requirements effort is short-cutted to save time or money 4.  Requirements are defined verbally, instead of in writing 5.  Not all stakeholder perspectives are considered 6.  The requirements are not properly validated by stakeholders, developers,

and testers 7.  Domain involvement occurs late in the project 8.  There is minimal discussion and review of the requirements 9.  Requirements are not properly allocated to development components 10.  Managers or other stakeholders speak on behalf of other stakeholders 11.  The requirements are tool or technique centric 12.  Nonfunctional requirements are not defined 13.  Developers gold-plate the requirements 14.  Requirements are gathered as a wishlist instead of a set of prioritized

requirements that deliver business value


Five Types of Requirements As Specified in BABOK v 2.0

Requirement Type DescripDon

Business Requirements Describe the reasons why a project has been ini5ated, the objec5ves that the project will achieve, and the metrics that will be used to measure its success.

Stakeholder Requirements Describe how various stakeholders will interact with the solu5on and needs they have in performing their assigned tasks and ac5vi5es.

Func5onal Requirements Capture and specify specific expected behavior of the system being developed. They define things such as system calcula5ons, data manipula5on and processing, user interface and interac5on with the applica5on, and other specific func5onality that show how user requirements are sa5sfied.

Nonfunc5onal Requirements Non-‐Func5onal requirements are associated with the state of the system and not with the func5onality that the system provides. General 'ili5es' of the system such as scalability, interoperability, maintainability, portability, performance and security are different types of nonfunc5onal requirements.

Transi5on Requirements Describe capabili5es that the solu5on must have in order to facilitate transi5on from the current state to the desired future state. They typically address data conversion, skill gaps, and other related changes to reach the desired future state.


Requirements Development Process Requirements are developed iteratively and incrementally

AcDvity DescripDon

ElicitaDon Collec5ng informa5on from stakeholders and other sources. Informa5on collected includes stakeholder needs, user requirements, constraints, risks, performance goals, and success criteria.

Analysis Analysis is the process that involves assessing and inves5ga5ng the informa5on gathered from elicita5on to determine the real requirements.

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

ElaboraDon Elabora5on involves adding addi5onal details such as visualiza5ons, business rules, and clarifying details to make the requirements more understandable.

VerificaDon and ValidaDon 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 tes5ng team.


Iterative and Incremental IteraDve Incremental

When you work iteraDvely you build what you can in one itera5on, then review it and improve it in next itera5on and so on un5l its finished. Requirements are built by going through a con5nuous 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 un5l you are finished. Requirements are built in layers, star5ng with high level business objec5ves, decomposed into features, func5onal requirements, and various layers of detail for each requirement.


Requirement Layers Layer ArDfacts ParDcipants

Business Layer •  Problem and Vision •  Objec5ves

•  Execu5ves •  Project Sponsors

Solu5on Scope Layer •  Features •  Epics •  Architecture Impacts

•  Product Manager •  SMEs •  Architects •  Enterprise BAs

Stakeholder Needs Layer

•  Stakeholder Impacts •  Personas •  Needs •  Scenarios

•  Organiza5onal Change Analysts

•  SMEs

Solu5on Requirements Layer

•  Func5onal Requirements •  NonFunc5onal Requirements •  Use Cases

•  Business Analysts •  SMEs

Solu5on Details Layer

•  Requirement PaRerns •  Requirement ARributes •  Visualiza5ons •  Conversa5ons

•  Systems Analysts •  Designers •  Developers •  UX Designer

Verifica5on & Valida5on Layer

•  Acceptance Criteria •  Test Cases •  Verifica5ons •  Valida5ons

•  Systems Analysts •  QA •  Developers


Example of a Requirement with Attributes

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

30 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. 2008 © Dan Roam THE BACK OF THE NAPKIN all rights reserved

Effective Requirement Visualizations The Back of a Na

pkin Marked Up Copy of a Report

Flowchart Mind M

ap


What Level of Detail is Needed?

•  Customers are extensively involved

•  Developers have considerable domain experience

•  Precedents are available •  A package solu5on will be used

•  Development will be outsourced •  Project team members are geographically dispersed

•  Tes5ng will be based on requirements

•  Accurate es5mates 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 oUen resul5ng in costly rework and associated schedule and budget overruns.

The Key to Good Requirements is the Level of Detail


Conversations Gain Understand and reach agreement of what is needed

Presenta5on

Process

Applica5on Logic

Data

Interfaces/Integra5on SAP Ac5ve Directory

Data Warehouse

•  UI •  Reports

•  Use Cases •  Workflow

•  Classes •  Subrou5nes •  Calcula5ons

•  Databases •  Queries •  Persistence

•  ESB •  Web Services •  Gateways •  Authen5ca5on


Collaboration


Collaborative

CollaboraDon is business analysts, business stakeholders, users and technical stakeholders working together to develop requirements. The various par5es work together by sharing knowledge, learning, and building consensus in terms of what is needed to build the solu5on. One leading consul?ng firm found that they were able to capture 93-‐95% of the func?onality by using a collabora?ve requirements approach versus only 65% when a more tradi?onal interviewing method was used. In addi?on, there was significantly higher user sa?sfac?on for solu?ons that were built with collabora?ve requirements.


Who owns Primary Responsibility for Requirements

Budget % of Target

Time % of Target

FuncDonality % of Target

Stakeholder Time % of Target

IT 162.9 172 91.4 172.9

Business 196.5 245.3 110.1 201.3

Jointly Owned 143.4 159.3 103.7 163.4

Source IAG Business Analysis Benchmark, 2008

Joint Responsibility for Requirements Makes a Big Difference


How can better Collaboration between the Solution Team and Stakeholders Help?

•  Lack of user input is the #1 cause of project failures.

•  Joint ownership of requirements results in lower costs and higher quality solutions.

•  Organization change goes more smoothly when users and other stakeholders are involved through the entire lifecycle.

•  Effective business analysis is the key for better collaboration between stakeholders and developers.


Enfocus Requirements Suite™ Achieve Successful Results on Projects


Enfocus Requirement Suite™ Achieving Spectacular Results

Outcome How to Achieve Outcome How Enfocus Requirements Suite Helps

1. Higher Project Success Rates

According to Standish Group Research, the top 5 reasons for failed or challenged projects are related to poor business analysis.

Our processes and tool-‐set helps organiza5ons address each of the five areas and more to keep your projects on track.

2. Improved Business Outcomes

Define expected business outcomes and align all work effort to achieve the expected business outcomes. Measure actual results against plan.

The en5re process included in Requirements Excellence Framework™ is built on the principle of delivering beRer business outcomes.

3. Increased Velocity

Manage projects using features and bundles and use powerful priori5za5on features focusing on delivering high value features early. Analyze how each feature impacts the business architecture and collec5vely manage changes to people, process, and technology using features and processes provided.

Measure the velocity of change using the dashboard and metrics that are captured. Define transi5on requirements to ensure a smooth and quick

4. Reduced Rework

According to industry research, 40% of project cost is related to rework. Of this, 70% is related to rework caused by ambiguous and incomplete requirements.

Use of RequirementPro™ significantly reduces the amount of rework related to poor requirements by wri5ng clear and complete requirements at the right level of detail.

5. Fewer Delays

The constant cycle of producing large paper requirement documents, making and managing revisions to the documents, and obtaining business approval is a slow and painful process and is a major contributor to project delays.

Use Enfocus Requirements Suite™ to manage data and not documents. In this manner, analysts can receive comments from stakeholder immediately and use powerful features to get rapid approval.


Enfocus Requirement Suite™ Achieving Spectacular Results

Outcome How to Achieve Outcome How Enfocus Requirement Suite Helps

6. High ROI

BeRer business analysis can 1) reduce costs (Waste, Rework) and 2) Improve Business Outcomes (Higher Revenues, Lower Costs, Higher Customer Sa5sfac5on, etc.).

We help you provide an excellent ROI for the investment you make. We also provide a powerful process for boos5ng ROI on projects using principles from the ROI Ins5tute.

7. Lower Costs

Through significantly reducing waste (unneeded features), reducing rework, and improving business analysis produc5vity, solu5on costs will drop markedly.

Our solu5on is based on proven methods to eliminate low value features and minimize rework for poor requirements.

8. Higher Quality SoluDons

Poor quality solu5ons resul5ng from missed or inaccurate requirements can result in dire outcomes.

Enfocus Requirements Suite™ is based on a powerful V-‐Model that allows organiza5ons to manage the verifica5on and valida5on processes to ensure high quality solu5ons are delivered that meet business needs. RequirementPro™ provides a dashboard and captures important metrics to monitor solu5on quality.

9. Less Waste

According to Standish Group Research, 45% of func5onality built is never used.

Enfocus Requirements Suit.™ provides many capabili5es in the form of feature paRerns, priori5za5on methods, stakeholder personas, needs, and scenarios to help ensure that solu5ons deliver needed and useful func5onality.

10. Greater Stakeholder SaDsfacDon

Keeping stakeholders engaged and informed results in solu5ons that meet user needs, and generates higher user sa5sfac5on and adop5on. The number of post-‐implementa5on workarounds can also be greatly reduced using these features.

Enfocus Requirements Suite™ allows users to enter their needs in their own words and see how they are mapped to solu5on requirements. Stakeholders have full transparency into the project using the stakeholder portal.


Q & A