how to integrate business analysis into the project
Post on 13-Mar-2022
4 Views
Preview:
TRANSCRIPT
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
2 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
3 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
4 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
5 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
6 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
7 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
8 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Manage Data Not Documents
Requirement Documents
9 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
10 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
Requirement Documents
11 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
Requirement Documents
Not using Requirements Management SoUware to develop and manage requirements places a project at great risk!!!
13 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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?
14 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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)
15 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
17 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
18 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
19 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
20 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
21 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
22 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Writing Clear and Complete Requirements
23 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
24 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
25 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
26 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
27 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
28 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
29 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
31 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
32 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
34 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
35 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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
36 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
37 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Enfocus Requirements Suite™ Achieve Successful Results on Projects
38 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
39 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
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.
top related