The document discusses different approaches to requirements management for various types of projects and organizations. It provides a framework to help assess which approaches may be best suited for different project goals, environments, and constraints. It also offers keys to successful implementation based on years of experience in requirements engineering. Different project types have different cultures and requirements focuses, from engineering and compliance-driven to agile and minimalist. Economics and industry patterns also influence optimal processes and techniques.
Sailing in Requirements Management Cross Currents - www.manageware.co.il Seminar
1. Clickin cross currents:title text format
Sailing
to edit the
setting your course amidst the many current
approaches to requirements
Click to edit the outline text format
Second Outline Level
Third Outline Level
– Fourth Outline Level
Daniel Moul & Keith Collyer
– Fifth Outline Level
Requirements Outline Level
– Sixth Product Delivery Team
dmoul@us.ibm.com & keith.collyer@uk.ibm.com
– Seventh Outline Level
RDM 2023B
– Eighth Outline Level
– Ninth Outline Level
The premiere software and product delivery event.
June 6–10 Orlando, Florida
‹#›
1
2. Abstract
Click to edit the title text format
Click development? Manufactured products? Packaged applications? SOA? Agile?
Web to edit the outline text format
System requirements specifications? Use cases? User stories? Faced with the
Second Outline Level
many competingLevel of projects and approaches to creating and managing
Third Outline types
requirements, how can you determine which are right for your organization?
– Fourth Outline Level
– Fifth Outline Level
This session will survey major approaches, provide a framework to help you
– Sixth Outline Level
assess–them, and offer some keys to successful implementation based on years of
Seventh Outline Level
IBM Rational and Telelogic experience.
– Eighth Outline Level
– Ninth Outline Level
‹#›
2
2
3. In your edit the title text which
Click to current project …format ship are you sailing?
Click to edit the outline text format
Second Outline Level
Third Outline Level
– Fourth Outline Level
– Fifth Outline Level
– Sixth Outline Level
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level
‹#›
3
There are many kinds of ships because they are optimized for different goals, environments,
people and cargo.
Same with software and systems delivery projects.
You shouldn’t attempt to create the One Right Requirements Process for your organization.
The important thing is to understand each project’s goals, environment and constraints, and
optimize your requirements process for that project with them in mind. In this session we will
offer a framework for doing that.
3
4. On terminology
Click to edit the title text format
Clicktoday let’s outline textall of these “RM”
For to edit the consider format
Second Outline Level
Requirements Management
Requirements Level
Third Outline Engineering
– Fourth Outline Level
Requirements Definition
– Fifth Outline Level
– Sixth Outline Level
– Seventh Outline Level
Sometime we’ll use
– Eighth Outline Level
“practices” to mean
– Ninth Outline Level
“process”
‹#›
4
4
5. Not every requirement is called
Click to edit the title text format a requirement
Click to edit the outline text format
Gaps in Outline Level
Second
Packaged
Third Outline Level Capability
Applications Gap
– Fourth Outline Level
(military)
– Fifth Outline Level
– Sixth Outline Level
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level
Regulations
Business
Policies
Rules
Standards
‹#›
5
And not everyone doing requirements management realizes that’s what they are doing
5
6. Why to you need a text format
Click do edit the title requirements process?
Isn’t a requirements tool enough?
Click to edit the about people and process
Effective RM is outline text format
Second Outline Level
Third Outline Level
Process is whole-team behavior
– Fourth Outline Level
– Fifth Outline Level
Tools enable and accelerate process
– Sixth Outline Level
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level
‹#›
6
Process is whole-team behavior – much better if it’s premeditated rather than ad hoc
Promotes (and requires) discipline: “We agree we aspire to …”
Promotes situational awareness and reflection
“Are we doing / did we do what we said we would?”
Promotes predictability
Promotes quality
Requirements tools enable and accelerate your requirements process
Requirements Management is more about people, skills, and process than tools.
Tools are not a magic silver bullet.
Requirements is
6
7. The to edit the title text format
ClickBusiness Environment Determines Project Parameters
Click to edit customer or contractor?
Are you the the outline text format
What are Outline Level terms?
Second the financial
Third Outline Level
Who is responsible for what?
– Fourth Outline Level
– Fifth Outline Level
– Sixth Outline Level
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level
‹#›
7
The business environment also has a major impact on the optimal requirements process.
7
8. Click to edit the title text format
Projects are commissioned to meet business goals
Program & Portfolio
Click to edit the outline text format
Management
Second Business strategy
Outline Level
Objectives & priorities
Third Outline Level
Business cases
– Fourth Outline Level
Project proposals
– Fifth Outline Level
– Sixth Outline Level
– Seventh Outline Level
Project selection
Project charters
– Eighth Outline Level
– Ninth Outline Level
Vision documents
Requirements identified
Project execution
Project Management
‹#›
8
Start with portfolio prioritization: Which projects will we undertake?
Outcomes, Benefits & Risks
Costs: Time, Effort, Money
Timing: Short term, quick return OR Strategic, capital investment
8
9. Click to edit the title text format
Different projects need different governance
Uncertainty and risk are the key discriminators
Click to edit the outline text formatConstruction
Inception Elaboration Transition/Maintenance
Second Outline Level
Variance in Cost, Schedule, …
Third Outline Level
– Fourth Outline Level
New New Capability Maintenance and
Platform on existing small change
– Fifth Outline Level platform requests
– Sixth Outline Level
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level
High Variance Medium Variance Low Variance
Time
‹#›
9
Uncertainty in understanding of the problem and the solution
Leads to risk that the project will not deliver what’s needed (or that adjusting to
new knowledge will cost unanticipated money, schedule, etc)
Also early on there is a lot of execution risk: how effective/productive will the
team be?
Source of chart: Murray Cantor & Walker Royce
9
10. Click to edit the title text format
Project delivery is an exercise in removing uncertainty
Initial Plan
Click to edit the outline text format
Second Outline Level
Initial State
Third Outline Level Initial Planned Path Uncertainty in
Stakeholder
– Fourth Outline Level Satisfaction
Space
– Fifth Outline Level
Actual Path
– Sixth Outline Level
Acceptable
– Seventh Outline Level solution set
Points of feedback,
– Eighth Outline Level learning, and adjustment Delighted
customers
– Ninth Outline Level
Feedback course corrections better outcomes
10
‹#›
As often as possible (especially early in the project), get feedback and reset path. This
provides feedback for a steering mechanism.
Rational consultants consistently report that “becoming more iterative” is the most
valuable change that the teams can make, precisely for the reasons shown here.
Source of chart: Murray Cantor & Walker Royce
10
11. Managing Uncertainty = Managing Variance
Click to edit the title text format
A completion date is not a point in time, it is a probability distribution
Click to edit the outline text format
Second Outline Level
0 Third Outline Level 6 12
– Fourth Outline Level
Scope is not a requirements document, it is a continuous negotiation
– Fifth Outline Level
Scope Sixth Outline Level
–
Product features / quality
Plans / resource estimates Level
– Seventh Outline
– Eighth Outline Level
A plan– NinthaOutline Level it is an evolving,
is not prescription,
moving target Uncertainty in
Stakeholder
Satisfaction Space
Initial State Initial Plan
Actual path and precision of Scope/Plan
‹#›
11
On large systems projects the key variables tend to be cost and schedule,
particularly later in the project. After all, your ships need to float and your planes
need to fly regardless.
On IT projects often there is more opportunity to reduce scope and hold cost or
schedule constant.
Source of chart: Murray Cantor & Walker Royce
11
12. Click to Requirements Hierarchy – two views
Typical edit the title text format
Typical Systems View
Click to edit the outline text format
Typical IT View
Second Outline Level
Third Outline Level Problem
Problem
– Fourth Outline Level
Stakeholder
Problem
– Fifth Outline Requirements
Level
hy
Definition
Problem Space
rarc
– Sixth Outline Level Needs
Hie
– Seventh Outline Level
Tra
Ta
Abstract System Solution
ent
cea
– Eighth Outline Level
e b
Solution Requirements Features
rem
Space
billii
– Ninth Outline Level
ty
qui
Re
Software
Design Requirements
Mech Elec S/W Human
Interfaces
‹#›
12
Should be possible to change the design without changing the system
requirements
You need to be cognizant of when you are working on problem vs solution
domain
Am I trying to understand the problem or trying to create a solution
to that problem?
Present in sw world but not as big an issue
Need to be aware when the gap is so small that we go straight to solution
more common in IT projects, maintenance projects
Need to update docs afterward a la Parnas
Managing requirements involves the translation of stakeholder requests
into a set of system features. These in turn are detailed into specifications
for functional and nonfunctional requirements. Detailed specifications are
translated into test procedures, design, and user documentation.
The above diagram doesn’t show the use of requirements to guide the
work of the project team or for showing that what you are delivering
actually meets the requirements. This of course is hugely valuable.
12
13. Progressive removal of format
Click to edit the title textuncertainty
Requirements
Definition
Click to edit the outline text format
Stakeholders identified Highly diverse,
Second Outline Level
Requirements collected unstructured
Third Outline Level
Domain knowledge & information
– Fourth Outline Level
terminology
– Fifth Outline Level
System scope determined
– Sixth Outline Level Problem statement
Requirements selected
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level
Requirements flow-down
Structured information
Solution design
Requirements
Engineering
Like sand in an hourglass, this can be a continuous process ‹#›
13
This does not suggest a waterfall process
The grains of sand are your requirements becoming clear during the
various iterations / stages of your project.
This metaphor doesn’t capture the feedback loops either
13
14. Models: Low-cost ways format
Click to edit the title text to learn early
Optimize for learning / adjusting
Visual
Click to edit the outline text format Simulations
Models
Second Outline Level
Third Outline Level
– Fourth Outline Level Performance
System
– Fifth Outlinecontext diagrams
Level Load testing
Business Process
– Sixth Outline Level
Sequence diagrams
Diagrams Monte Carlo Financial Return
– Seventh Outlineflow
Functional Level BPMN
– Eighthblock diagrams
Outline Level
Cost & Duration
Venn
– Ninth Outline Level Project Planning
UI simulations
diagrams IDEF
Stresses, heat
Use Cases CAD/CAM flow, air flow
Pictures
Screen shots
Manufacturability
Story boards Prototyping
Behavior
‹#›
14
Modelling helps you to …
•Understand a problem
•Reason about a solution
Analyze & Optimize
•Communicate with stakeholders
14
15. Economics the title text format
Click to editdetermine many of the possible optimizations
Optimize for learning and adjusting as much as possible within your constraints
Click to edit the outline text format
What can you optimize?
What are Outline Level economics?
Second the underlying
Third Outline Level
Value of being fast-to-market
– Fourth Outline Level
Cost of failure
Cost Fifth Outline Level
– of change
Cost Sixth Outline Level
– of communication
Cost Seventh Outline Level
– of non-compliance
Cost Eighth Outline manufacture
– of design and Level
– Ninth Outline Level
‹#›
15
We often don’t recognize that we are evaluating economic dynamics when intuitively choosing
the processes we use.
15
16. Industry patterns reveal format
Click to edit the title text optimized groupings
Click to industry outline text format
Unique edit the characteristics
Second Outline Level
Government / private
Manufactured systems / IT
Third Outline Level
– Fourth Outline Level
Patterns Fifthreflected in culture
– are Outline Level
– Sixth Outline Level
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level
‹#›
16
Systems - Key Drivers
Increasing complexity
SW is a growing % of product value
Complex sub-contractor scenarios
Faster time to market
More predictable outcomes
IT - Key drivers
Lower cost
Faster time to market
More predictable outcomes
16
17. Click to edit the title text format
Project have various cultures
Group Requirements Focus
Engineering & Compliance culture RM in an engineering process
Good outcomes the the result of good,
Click to edit are outline text format • Formal process
controlled processes.Level we missed
Second Outline “Have • Manufactured systems
anything?” • Mission-critical systems
Third Outline Level • Regulated, compliance, and contract-driven
– Fourth Outline Level industries
– Fifth Outline Level
Market-driven culture Level
– Sixth Outline Effective teams, efficient tools
Balance process and expedience. “How can • Business-oriented software applications
– Seventh Outline Level
we get this out faster with good quality?” • Fast-to-market manufacturers
– Eighth Outline Level
ALM minimalist culture Level
– Ninth Outline Use development and test tools
“We use our main tools for requirements too” • Requirements by and for dev and test
• Typically business analysts are not involved
Ad-hoc culture Using general-purpose tools at hand
“What is RM?” • May employ some RM, “pure agile”
“We don’t do RM” methodologies or no defined methodology at all
“We get by with office docs”
‹#›
17
We see these differences … we get “psychic whiplash” when we talk to engineering
team then to IT team in the same organization
17
17
18. Management Techniques in Organization Culture (extract)
Click to edit the title text format
Base Technique Engineering - Market- ALM Ad hoc
Lifecycle Compliance driven minimalist
Waterfall BDUF Y
Complete stages
Click to edit the outline text format Y
Single release Y
Second Outline Level
Complete plan Y Plan, what plan?
Incremental Outline Level
Third BDUF Y
– Fourth Outline Level
Parallel implementation Y Y Y
Early release Y Y
– Fifth Outline Level
Iterative / Large-scale iteration Y Y
– Sixth Outline Level
Evolutionary Plan complete at high level Y Y
– Seventh Outline Level
Cost-benefit driven Y Y Y
– Eighth at every release
Value Outline Level Y Y
Each release "complete" Y Y
– Ninth Outline Level
Small releases ? Y Y
Just enough planning Y Y
Agile User stories Y Y Y
Time-boxing Y Y
Test-driven Y Y
Work-item list Y Y Y
Common Evaluate against plan Y Y Y
Compliance-checking Y ?
Feedback Y Y Y Y
Consistency check Y Y Y ‹#›
18
Definitions of different lifecycle types:
•Waterfall: Each stage (typically Requirements, Design, Implementation, Test) is separate.
The output of each stage is the input to the next. In principle, the stages are carried out
consecutively, though in practice there will be significant feedback. All lifecycle models use
waterfalls in practice, though some of the disadvantages are often mitigated by making the
“size” of the waterfall small
•Incremental: The incremental model is similar to the waterfall model, except that after the
design is completed, the implementation and subsequent stages are divided into delivery
increments. Each increment is delivered separately, typically sequentially though occasionally
in parallel.
•Iterative / Evolutionary: Like the incremental lifecycle, the iterative or evolutionary lifecycle
delivers in parts. The significant difference is that each iteration is complete in itself, though
small compared to the envisaged scope of the entire project. Decisions are taken on what
should be delivered in each iteration on the basis of cost-benefit analysis.
•Agile: The agile approach is essentially a development of the evolutionary approach. The
most significant differences are not in the planning approach but in the ways in which the
system is defined. However, time-boxing (restricting development stages to a few weeks) is
specific to agile development, and the use of a work-item list (based mainly on change
requests) is common.
18
19. Click to edit theconstraints – Example: IBM agility@scaleTM
Consider other title text format
Team size Compliance requirement
Click to edit the10
Under
outline text format
1000’s of
Low risk Critical,
developers developers
Second Outline Level Audited
Third Outline Level
– Fourth Outline Level
Geographical distribution Domain Complexity
– Fifth Outline Level
Straight Intricate/
– Sixth
Co-located OutlineGlobal
Level -forward Emerging
– Seventh Outline Level
– Eighth Outline Level
Enterprise discipline Organization distribution
– Ninth Outline Level (outsourcing, partnerships)
Project Enterprise
focus focus Collaborative Contractual
Organizational complexity Technical complexity
Flexible Rigid Heterogeneous,
Homogenous Legacy
‹#›
19
In the early days of agile, the applications where agile development was applied were smaller in scope and
relatively straightforward. Today, the picture has changed significantly and organizations want to apply agile
development to a broader set of projects. Agile hence needs to adapt to deal with the many business,
organization, and technical complexities today’s software development organizations are facing. This is what
Agility@Scale(TM) is all about – explicitly addressing the complexities which disciplined agile delivery teams
face in the real world.
The agile scaling factors are:
Geographical distribution. What happens when the team is distributed, perhaps on floors within the same
building, different locations within the same city, or even in different countries? Suddenly effective
collaboration becomes more challenging and disconnects are more likely to occur.
Team size. Mainstream agile processes work very well for smaller teams of ten to fifteen people, but what if the
team is much larger? What if it’s fifty people? One hundred people? One thousand people? Paper-based,
face-to-face strategies start to fall apart as the team size grows.
Compliance requirement. What if regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 –
are applicable? These issues bring requirements of their own that may be imposed from outside your
organization in addition to the customer-driven product requirements.
Domain complexity. Some project teams find themselves addressing a very straightforward problem, such as
developing a data entry application or an informational web site. Sometimes the problem domain is more
intricate, such as a bio-chemical process monitoring or air traffic control or perhaps it is changing quickly,
such as financial derivatives trading or electronic security assurance. More complex domains will require
greater emphasis on exploration and experimentation, including but not limited to prototyping, modeling, and
simulation.
Organization distribution. Sometimes a project team includes members from different divisions, different
partner companies, or from external services firms. This lack of organizational cohesion can greatly increase
the risk to your project.
Technical complexity. Some applications are more complex than others. It’s fairly straightforward to achieve
high-levels of quality if you’re building a new system from scratch, but not so easy if you’re working with
existing legacy systems and legacy data sources which are less than perfect. It’s straightforward to build a
system using a single platform, not so easy if you’re building a system running on several platforms or built
using several disparate technologies. Sometimes the nature of the problem that your team is trying to
address is very complex in its own right.
Organizational complexity. Your existing organization structure and culture may reflect traditional values,
increasing the complexity of adopting and scaling agile strategies within your organization. To make matters
worse different subgroups within your organization may have different visions as to how they should work.
Individually the strategies can be quite effective, but as a whole they simply don’t work together effectively.
Enterprise discipline. Most organizations want to leverage common infrastructure platforms to lower cost,
reduce time to market, and to improve consistency. To accomplish this they need effective enterprise
architecture, enterprise business modeling, strategic reuse, and portfolio management disciplines. These
disciplines must work in concert with, and better yet enhance, your disciplined agile delivery processes.
Each factor has a range of complexities, and each team will have a different combination and therefore will need 19
a process, team structure, and tooling environment tailored to meet their unique situation.
20. Value to stakeholders should determine RM priorities
Click to edit the title text format
Practitioners Team Leaders Executives
Click to edit the outline text format
Many common aspirations: Regulatory &
Improvement in Requirements Quality
Second Outline Level Contractual
• Improve productivity
Third Outline Level
• Reduce rework Compliance
–• Fourth Outline Level right
Get the requirements
• Make customers happy Manage
– Fifth Outline Level Scope &
• Meet business goals
– Sixth Outline Level Change
– Seventh Outline Level Re-use Deliver to
Cost &
– Eighth Outline Level Audit Schedule
Trail Traceability Constraints
– Ninth Outline Level
Visible
Context between
Scalable
Common Role-Based Reqts
Repository Access
Tailorable
RM
Handle Process
Complexity
Increased use of Requirements Management Good Practices
‹#›
20
Each stakeholder looks through the lens of his/her personal ROI: What’s it going to cost me? What’s in it for me?
Executives won’t get the benefits they seek if the middle managers and practitioners don’t get what they seek.
Some examples
•Scalable Common Repository: a common database for requirements. Everyone knows where they are and
which ones are current. Less confusion and error.
•Handle Complexity: master arbitrary levels of complexity. Reduce errors of thought and execution.
•Visible Context: relevant views of information, in-line with attributes and related information
•Tailorable RM Process: process “right-sized” to team / solution; tools support and enable the process
•Audit Trail: Development process is under control (this is one of many factors contributing)
•Re-use: re-use of information through linking and copying. Save time & money; increase consistency and quality
•Role-Based Access: access control based on groups and users
•Traceability between Requirements (and to other things): Solution quality & completeness; dev process
coherence
•Manage Scope Change: impact assessments of potential changes and notification of changes
•Deliver to Cost & Schedule Constraints: The ability to control scope and changes enables greater certainty in
what should be delivered, hence greater control over costs and schedule
•Demonstrate Regulatory / Contractual Compliance: The ability to trace to internal and external information gives
confidence that regulations and contractual conditions are being met
•Conform with Standards (CMMI. SPICE, ISO): The transparency of information together with the ability to define
necessary information, allows conformity with standards to be assessed and managed
20
21. Click to edit the title text format
Click to edit the outline text format
Second Outline Level
Third Outline Level
– Fourth Outline Level
– Fifth Outline Level
– Sixth Outline Level
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level
‹#›
21
Like all icebergs, 90% is below the surface. The buying decision is often most
visible and has most attention, but that is just the start of the work of ensuring a
successful roll-out.
What management should do – vision:
•paint the vision – why? what value? what will success look like? what if not successful? how to
measure success?
•ensure seen as important, with full backing of Senior Management
•provide support
•commit personnel – people that are well respected in the organization
•tie performance evaluations to the work done on initiative
Initiative must NOT be seen as a secondary duty
Set realistic, achievable goals: Incremental, value-based adoption
Address team and personal ROI: Make sure teams (and individuals) see themselves being more
productive & successful when they follow them
Create a set of coordinated, customizable, adoptable, RM processes for your teams: Allow
appropriate degree of self-organization among the teams
Pilot, learn, replicate your success
Educate, mentor, measure, share success stories
Continuously improve
21
22. People edit the title text format
Click to impose significant constraints
And in one company there are many project team cultures
Click to edit the outline text format Systems
Second Outline Level Engineering
Research
IT Applications Group
Third Outline Level
– Fourth Outline Level Manufacturing
– Fifth Outline Level
– Sixth Outline Level
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level Software
Development
Software
Development
‹#›
22
There are a couple of things to say here.
First, the pictures of people remind us that the people involved impose significant constraints on the requirements
process
For example, which notations can be used to communicate effectively? Depends on their technical background:
you can communicate with developers using UML diagrams, but don’t try that with marketing!
Trust, competence, commitment, team work
People touch requirements in various ways: author, validate, approve, use requirements
•Know your audience. What do they need / expect? What can you expect from them? How best to communicate?
Includes many job roles …
•Marketing, Product Managers, Business Analysts, Requirements Engineers
•Licensed Engineers, Developers, Testers, Architects, Operations / Production team
•Project Managers, Executives, Customers, Other Stakeholders
•And many more
Second, in any reasonably large organization there will be projects that have differing optimizations and thus
differing project cultures.
22
23. Click to edit the title text format
Rational RM portfolio today
Addressing different cultures and different needs
Group
Click to edit the outline text format
Second Outline& Compliance cultures
Engineering Level
DOORS and
Good outcomes are the result of good,
Third Outline Level DOORS Web
controlled processes. “Have we Access
– Fourth Outline Level
missed anything?”
– Fifth Outline Level
Market-driven culture RequisitePro
– Sixth Outline Level
Balance process and expedience.
– Seventh Outline Level
“How can we get this out faster with Requirements
– Eighth Outline Level
good quality?” Composer
– Ninth Outline Level
ALM minimalist culture
Team Concert and
“We use our main tools for Quality Manager
requirements too”
Ad-hoc culture
50% of project failure
“We don’t do RM” can be tracked to poor
requirements practices
“What is RM?”
‹#›
23
Engineering & Compliance cultures
•Reliance on formal process
•Manufactured Systems
•Mission-critical systems
•Regulated, compliance, and contract-driven industries
•Customized tools to support process and analysis of complex requirements
Market-driven culture
•Business-oriented software applications
•Fast-to-market manufacturers
ALM minimalist culture
•Requirements by and for dev and test
•Typically business analysts not involved
Ad-hoc culture
Using general-purpose tools: office, collaboration tools, defect database.
•May employ RM, “pure agile” methodologies or no defined methodology at all
•We think ad-hoc culture teams should move up to one of the other groups (as shown by the arrows)
RRC’s bar has hash markings, since it can be used as a requirements definition accelerator with these other tools
23
23
24. Summary
Click to edit the title text format
Systems
Engineering
Research
IT Applications
Group
Manufacturing
An effective requirementstext format …
Click to edit the outline process will
FitSecond Outline environment and project methodology
the business Level
Software
Development
Third Outline Level Software
Recognize where there is scope for optimization Development
(and–where there isn’t)
Fourth Outline Level
– Fifth Outline Level
Recognize (and reduce) the degree of uncertainty in the
– Sixth Outline Level
solution throughout the project lifecycle
– Seventh Outline Level
Be adaptable … not “one size fits all teams”
– Eighth Outline Level
Be well communicated, understood, and followed
– Ninth Outline Level
Be relevant to the entire project lifecycle
Include measurement, reflection and continuous improvement
Be supported by (embodied in) tools
‹#›
24
24
25. Click to edit the title text format
Click to edit the outline text format
Second Outline Level
Third Outline Level
– Fourth Outline Level
– Fifth Outline Level
– Sixth Outline Level
– Seventh Outline Level
– Eighth Outline Level
– Ninth Outline Level
‹#›
25
25