1. Scope Management & Requirements
Project Management
Scope Management & Requirements
Minder Chen, Ph.D.
CSU Channel Islands

2. Design Thinking

3. Problem Analysis Roadmap
MRMUC Instructor Notes
Business
Problem
Solution idea or Opportunity
Identify stakeholders for problem.
Root cause analysis.
Emphasize: No matter how you start your project (business problem or an idea for a system), it is important that you go through the same steps to make sure the solution adds business value.
In this slide, the boxes show the stages and the arrows show the activity being performed to get to the next stage.
Use this to help describe:
There are two sets of stakeholders, one set for the problem and another (expanded) set for the solution.
The connection between problem analysis and business modeling.
The best solutions are the ones that clearly solve a business problem.
Relate this slide back to the Standish slide that mentions a clear statement of business objectives is key to project success.
Business Goals is used here to tie it to RUP. Business Goal and Business Objective are synonyms.
Note: Each transition arrow relates to upcoming slides. Read the subsequent instructor notes to see how to relate all problem analysis activities back to this slide.
Business problem defined
Actual problem identified
and defined
Understand the problem in the context of the business goals.
Problem validated/adjusted
Choose the best solution(s) to meet the goals.
This slide shows the two typical approaches to defining a system. One approach is where someone has an idea or recognizes a need and develops a product to solve that problem. The other stems from the realization that there is some problem that needs solving. In the case of the former, an analysis of the business problem is often implied or thought out informally.
No matter which perspective you start from, it is important to understand where the system fits in the context of the goals of the organization. Failing to do this could mean you develop a system that adds little or no business value. In fact, it is possible that the wrong system could impede an organization from achieving its business goals.
Note: The Standish Group uses the term Business Objectives. The Rational Unified Process uses the term Business Goals. They are the same thing.
A common reason for project failure is that people start with a solution idea and head straight to development. When the project starts to fail, they almost always back track through this workflow.
Reassess that the solution idea is the best solution.
Elicit Requirements
Best solution identified
Expand stakeholder list for solution.
Module 4 - Analyze the Problem

4. Root Causes: What Are the Problems Behind the Problem?
MRMUC Instructor Notes
Root Causes: What Are the Problems Behind the Problem?
Fishbone Diagram Techniques
The perceived business problem.
Relate this slide back to the root cause analysis of the “business problem” transition on the “Problem Analysis Roadmap” slide.
A fishbone diagram is a method for Root-Cause Analysis. Explain the fishbone technique. Show how to use the fishbone diagram to explore the root causes of the problem. Begin with the customer’s stated problem on the right hand side. Then ask, “Why?” Fill in the contributing causes on the “bones” of the diagram.
After the fishbone diagram is filled in, you can choose the key contributor(s) and expand them further using the same technique. Keep asking “why” until the question becomes trivial.
Further demonstrate the idea of a fishbone diagram by developing a second-level fishbone diagram. On easel paper, draw another diagram, and put “Need more banking locations” as the problem on the right-hand side of the diagram. Ask for contributing causes to this problem. Answers may be “Need banking nearer residential areas,” “Need cheaper facilities,” etc.
Then go on to the Pareto slide to talk about how to the focus on the main contributing causes.
Emphasis: You may discover more than one simple problem involved. See student notes (last two paragraphs.)
Want Privacy
when banking
Too much waiting
No Banking at night
Customers are dissatisfied with our service.
Queues in the
branches are too long
Want more banking
locations
“Customers are dissatisfied with our service.” Is this really the true problem?
The fishbone diagram is one method for finding the “root cause” of a problem.
The spines are contributing causes to the problem.
Once the root causes have been defined, focus on the ones that contribute most to the problem. You can then further explore the most important root causes to reveal contributing factors to these causes: expand each rib by building spines branching off the rib, or do a separate second-level fishbone diagram with a first-level root cause as “the problem.”
What you often discover is that there may be more than one simple problem involved. Instead, there may be many dimensions to and perceptions of what the problem really is. You may need to help the customer focus on the dimensions of the problem that they most need to solve.
You help the customer focus on the problem that really needs to be solved.
Once you have a list of problems, you then need to perform a little analysis to identify the best solution to the biggest contributors to the problem. This step comes after you have all agreed to the main contributing problems.
Banking in airports
List contributing causes to the identified problem. Keep asking “Why?” (expand each rib).
Module 4 - Analyze the Problem

5. Gain Agreement on the Problem Definition
MRMUC Instructor Notes
Problem Statement
The problem statement helps define the “real” problem by summarizing key issues about the problem. Emphasize that a problem statement can help gain agreement among all stakeholders on the parts of the problem that will be solved.
Go over the problem statement chart and the example problem statement given in the student notes.
Students use the problem statement as a template for developing a problem statement for the class project (in Exercise 4.1).
Note that we’ve seen how to develop several of the individual parts of the problem statement already.
Where do the spines of the fishbone diagram go? [Answer: in the description of the problem.]
How do we know which spines are worth noting in the problem statement?
[Answer: use the Pareto Principle.]
Who are our key stakeholders?
The problem of
(describe the problem)
(the stakeholders affected by the problem)
affects
the impact of which is
(what is the impact of the problem)
a successful solution would
(list some key business benefits of a
successful solution)
It is often useful to have the group agree on a short, clear statement of the agreed-upon problem that our product addresses.
Example: (for a customer support system)
The problem of untimely and improper resolution of customer service issues
affects our customers, customer support representatives, and service technicians.
The impact of which is customer dissatisfaction, perceived lack of quality, unhappy employees and loss of revenue.
A successful solution would provide real-time access to a trouble-shooting database by support representatives, and facilitate dispatch of service technicians, in a timely manner, only to those locations that genuinely need their assistance.
Vision
Module 4 - Analyze the Problem

6. Project Scope Management
5.1 Plan Scope Management—The process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled. 5.2 Collect Requirements—The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives. 5.3 Define Scope—The process of developing a detailed description of the project and product. 5.4 Create WBS—The process of subdividing project deliverables and project work into smaller, more manageable components. 5.5 Validate Scope—The process of formalizing acceptance of the completed project deliverables. 5.6 Control Scope—The process of monitoring the status of the project and product scope and managing changes to the scope baseline.

7. Product Scope vs. Project Scope
In the project context, the term scope can refer to:
Product scope. The features and functions that characterize a product, service, or result; and/or
Project scope. The work performed to deliver a product, service, or result with the specified features and functions. The term project scope is sometimes viewed as including product scope.

8. Plan Scope Management Data Flow Diagram

9. Collect Requirements: Inputs, Tools & Techniques, and Outputs

10. Collect Requirements Data Flow Diagram

11. What Are Sources for Requirements?
MRMUC Instructor Notes
What Are Sources for Requirements?
Requirement Specs
Business Models
Business Plans Personal Goals
See student notes.
Partners
Customer
Analyst
Users
You need to capture requests from all stakeholders and specify how these requests are addressed. Although the system analyst is responsible for gathering this information, many people contribute to it: marketing people, users, customers-anyone who is considered to be a stakeholder in the project.
Other examples of external sources for requirements are:
Statement of work
Request for proposal
Mission statement
Problem statement
Business rules
Laws and regulations
Legacy systems
Business models
Any results from requirements elicitation sessions and workshops
Problem
Domain
Site Visits
Domain Experts Industry Analysts
Competitive info
Initial Requests
Bug Reports Change Requests
Module 5 - Understand Stakeholder Needs

12. Challenges in Requirements Elicitation

13. Challenges in Requirements Elicitation

14. Normally no pointers are needed - people very readily interpret the pictures into their own organisational situation. Here are a few typical 'them and us' reactions just in case:
of marketing - add unnecessary value, add complexity, bells and whistles, embellish, put their own mark onto things, fanciful, impractical, untested, untried, creativity for creativity's sake, subjective not objective, theoretical not practical, clever ideas, think they know what's best for the customers even if the survey feedback is utterly clear, fail to consult with engineering, production and anyone else in the organisation.
of management - cost-conscious, process-led rather than output-aware, failure to understand and interpret real issues and implications, failure to ask questions, committee decisions produce impractical solutions, removed from reality, detached from customers and front-line staff, failure to consult with users and functional departments.
of engineering - technical interpretation rather than practical, unconcerned with aesthetics and ergonomics, consideration stops after the 'can we build it?' stage, lack of consultation with specifiers and user representatives, meets specification but doesn't work properly, inappropriate materials and absence of styling.
of manufacturing - production specification over-rides design considerations, a law unto themselves, you get what you're given, any colour you like as long as it's black, detached from users, specifiers, designers, and everyone else except other manufacturing staff, unconcerned with usability or functionality, certainly unconcerned with bells and whistles and added value, totally focused on production efficiency, cost and time, lack of liaison with all other departments.
of maintenance - necessity is the mother of invention, very big tool-boxes, huge stocks of parts and ancillaries, materials, nuts, bolts and all other fixings known to man, happy to work all hours, especially evenings, weekends and public holidays at treble-time-and-a-half with days off in lieu, never consult with specifiers or customer specifications, enjoy quick-fixes, sticky-tape, mastic, bending bracketry, planks of wood and extended tea-breaks, never liaise with any other departments and think management are all useless idiots who can't even change a plug.
of customers - if only we'd listened, understood, and checked with them once in a while......
Check this out

15. What Problems Might Be Encountered?
MRMUC Instructor Notes
What Problems Might Be Encountered?
Stakeholders
Have a pre-conceived idea of the solution.
Do not know what they really want.
Are unable to articulate what they want.
Think they know what they want, but do not recognize it when it is delivered.
Analysts
Think they understand user
problems better than users.
Everybody
Everyone sees things from
their own point of view.
Believes everyone is
politically motivated.
Ask: What are some of the problems you have encountered in determining your stakeholder needs? Keep the discussion relatively short.
This is a good time to relate the story of the five blind men and the elephant. If you are unfamiliar with the story you can find it here: ? ?
What are some of the problems you have encountered in determining your stakeholder needs?
Stakeholder
Analyst
Module 5 - Understand Stakeholder Needs

16. Laundry List Prioritizing  MUST have vs. NICE to have
Clarification  Attack ambiguity because ambiguity costs!
Operational definition  Measurable and testable;

17. Costs of Errors in Lifecycle Phases

18. Interview Techniques

19. Project Management Plan Baseline
Once the project management plan is baselined, it may only be changed when a change request is generated and approved through the Perform Integrated Change Control process.
Project baselines include, but are not limited to:
Schedule baseline,
Cost performance baseline, and
Scope baseline.

20. Establish Requirements Baseline
MRMUC Instructor Notes
Establish Requirements Baseline
Requirements Baseline
The set of features that constitutes the agreed upon basis for development and that can only be changed through a formal procedure.
Refer to our discussion of this slide in Module 1.
The implication here is that this baseline is compiled quite early. This is possible because it is a feature list and so not the final elaborated form of a requirement-the use case.
How do we know what the needs are?
How do we determine priority?
Where do we set the baseline?
How do we reach agreement on what features should be included in our project? Where would we set our baseline commitment for delivery?
The key is to under-promise and over-deliver but not too much! We want to maintain our credibility.
What needs of our stakeholders do the features represent?
How should features be prioritized?
What factors might influence the order in which we rank the features?
Feature 1: The system must...
Feature 2: The system must...
Feature n: The system must...
Time
Project
Start Date
Target
Release Date
Module 7 - Manage the Scope of the System

21. MRMUC Instructor Notes
Scope Management
MRMUC Instructor Notes
Problem
Problem
Space
Animation: A vertical dotted line appears in the pyramid after two seconds. Then a mouse click sets the user/custom er and developmen t teams arrows to appear.
Use the pyramid you drew on easel paper to further position this module. Point to or draw a line from the top of the pyramid to the bottom. We do not waste time refining parts of the system that are outside the scope of the current version of the system. This is reflected in the line through the pyramid: by taking a little off the top of the pyramid (focus on the needs and features that you can really accomplish) , you take a lot (of work refining the requirement s) off the bottom of the pyramid.
If presenting this course on-site at a company not using RUP, discuss the activities they use to accomplish this objective.
Mention the “healthy tension” between what the customer wants and what the developer can supply.
Capture
Needs
Traceability
Solution Space
Features
System to build
Software
Requirements
Scope management is maintaining a “healthy tension” between what the customer wants (maximum features) and what development believes it can deliver in a fixed timeframe. It is essential for the developer to get agreement from the customer regarding a baseline set of features to develop for the system to be built.
A good way to achieve the balance between customer desires and developer resources is by using iterative development and providing incremental “slices of the pie.” Then, the priorities can be reassessed at the end of each iteration.
The ideal time to decide what the baseline set of features we will actually develop is after the system is defined (Module 5) and before we have put a lot of time into refining the details (Module 7).
The following is a list of tips for avoiding scope creep, but allowing change:
‘Real’ requirements: Identify what is really needed for the business objective-prototyping, iterative development.
Minimum requirements: A conscious practice of a minimum requirements strategy, no ‘gold plating’, no including what ‘might be needed.
All requirements should be recorded and identified by source.
Realize all requirements have a cost and schedule impact.
The use of an agreed negotiation and sanctioning process (it need not be heavyweight).
All requirements come (in the end) through a well-identified channel, not from various and sundry random sources.
Expectation management and communication with the customer about what will be in each iteration. This helps uncover hidden requirements, unknown to the naïve developer but assumed by the domain-experienced customer.
Development Team
User/Customer
Design
User Doc
Test
Module 7 - Manage the Scope of the System

22. Project Scope Statement
Product scope description. Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation.
Product acceptance criteria. Defines the process and criteria for accepting completed products, services, or results.
Project deliverables. Deliverables include both the outputs that comprise the product or service of the project, as well as ancillary results, such as project management reports and documentation. The deliverables may be described at a summary level or in great detail.
Project exclusions. Generally identifies what is excluded as from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders’ expectations.
Project constraints.

23. Classifications of Requirements
Business requirements, which describe the higher-level needs of the organization as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken.
Stakeholder requirements, which describe needs of a stakeholder or stakeholder group.
Solution requirements, which describe features, functions, & characteristics of the product, service, or result that will meet the business & stakeholder 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.

24. Classifications of Requirements
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.

25. Group Creativity Techniques
Brainstorming. A technique used to generate and collect multiple ideas related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do.
Nominal group technique. A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization.
Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas.
Affinity diagram. A technique that allows large numbers of ideas to be classified into groups for review
and analysis.
Multicriteria decision analysis. A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.

26. Divergent and Convergent Thinking

27. Generating new ideas can be
The Groan Zone
Generating new ideas can be
Time-consuming
Painful
So why bother??!
Better solutions with diversity of opinions
Help participants understand
Complexities
Trade-offs
Constraints

28. Group Problem Solving Process
MRMUC Instructor Notes
Gather ideas for stakeholder requests/needs.
Clarify and organize the ideas.
Condense ideas.
Prioritize remaining ideas.
Required:
Refer the students to Exercise 5.2 in the Student Workbook. Lead the whole-class demonstration of brainstorming. For the class project that you began in Module 4, come up with a list of stakeholder needs for the project.
Estimated Time:
Brainstorming: 10 minutes
Idea reduction: 10 minutes
Comments:
The main exercise is the idea generation phase. Have the students shout out the idea to the facilitator and also write a short description (three to four words on a sticky note with a large marker so all can read). The facilitator collects these and places them on the easel.
It might be an idea to group the needs for each stakeholder.
If ideas start to change as people hear ideas and come up with variations, encourage and comment on it. Continue gathering ideas until the easel is filled with needs (20 or so).
See Student Workbook Exercise 5.2: Utilize Brainstorming Techniques.
Assume the roles of different stakeholders you identified in Exercise 4.2 and think about what they would need from the system that would help solve their problem.
To get you started, here is a short list of of stakeholder needs:
Trading Customer: “Obtain current and historical quotes ”
Trading Customer: “Maintain personal portfolio“
Trading Customer: “Trade anytime from anywhere”
Trading Customer: “Secure environment”
Marketing: “Advertise additional services”
Module 5 - Understand Stakeholder Needs

29. MRMUC Instructor Notes
Brainstorming
Generates as many ideas as possible.
Emphasize that brainstorming is a way to quickly generate as many ideas as possible.
See student notes for other key points.
Rules for Brainstorming
Clearly state the objective of the session.
Generate as many ideas as possible.
Let your imagination soar.
Do not allow criticism or debate.
Combine ideas.
Brainstorming is a way to quickly generate as many ideas as possible. In the idea generation phase, the emphasis is on quick generation of ideas. In the idea reduction phase, the emphasis is on combining ideas and focusing on the most promising ideas.
In order to encourage people to contribute ideas, it is important to finish with idea generation before doing any pruning or criticizing of ideas. Ideas may start to change as people hear ideas and come up with variations on them. This is good because some of the best ideas are those that build on the expertise and creativity of many people in the group.
One technique: This is a four-step process. None of the steps should be skipped!
Brainstorm the Features that the new Software System should realize. Cover a wall with yellow sticky notes.
Classify the Stickies: This process must be done with no talking! Invite everyone to move around the stickies and group those that describe a single feature. Additional stickies can be added at this time, but no one can talk to anyone except to the Facilitator.
Name that Feature: the facilitator then looks at each group of stickies, reads the stickies out loud, and helps the group name that feature. Affinitizing only gets you percent in the right groups. Naming the groups realigns the groups. Get rid of some and split up others. You almost always end up with groups.
Prioritize the Features: It is critical to understand which are the key features that the software must support. Use a process, such as bullet voting. It is quick and easy and almost always ends up with a clear bell curve.
Module 5 - Understand Stakeholder Needs

30. Brainstorming Advantages and Disadvantages
MRMUC Instructor Notes
Brainstorming Advantages and Disadvantages
Advantages
Used anytime, anywhere.
Good for groups.
Good for high-level entities and assumptions.
Amenable to some automation.
Disadvantages
Susceptible to group processes.
Unsystematic in “classic” form.
Description: the requirements engineer asks a group of stakeholders to generate as many ideas as possible with an emphasis on generation rather than on evaluation.
Preconditions: a suitable group of stakeholders.
Strengths: good for eliciting high-level domain entities and questioning assumptions which might otherwise have constrained approaches considered. Tool support available for some varieties.
Weaknesses: susceptible to group processes; unsystematic in "classic" form, though some varieties overcome this.
Takeda et al. 1993
Module 5 - Understand Stakeholder Needs

31. Idea Reduction: Prune and Organize
MRMUC Instructor Notes
The affinity diagram is used to organize the results of a brainstorming session into manageable groups. It is based on the relationship between the items found during brainstorming. It is a creative, rather than logical process.
After all the ideas are collected on the board the participants get up and move the cards or notes into groups that appear to be similar ideas. It is important that this be done silently. A rough guideline is that you will find seven to ten groups. Continue this activity until everyone agrees on the grouping.
The participants then discuss the relationships between the grouped items and identify a name for each group of cards or notes. Often one of the cards within the group serves as a title for the entire group; if not, create one and place it over the group.
If there are any items that fell into a miscellaneous group, see if they now fit one of the designated groups.
Those titles that were selected for the groups can now be studied to gain a better understanding of the original problem.
A good reference for affinity diagrams is: H. Beyer and K. Holtzblatt, "Contextual Design: Defining Customer-Centered Systems," Morgan Kaufmann Publishers, 1997.
Module 5 - Understand Stakeholder Needs

32. Idea Reduction: Prioritize Ideas
MRMUC Instructor Notes
Prioritize remaining ideas.
Vote
Cumulative votes
Buy ideas
Single vote
Apply evaluation criteria
Non-weighted
Weighted
After the idea gathering and pruning are over, organize and evaluate them.
There are many ways to evaluate. Go through all the prioritizing methods.
The “RU bucks” are a way to do cumulative voting. Each person in the workshop receives a fixed number of dollars. A person gives one “vote” for an idea by putting a dollar on a particular idea.
The faces on the dollars are: Ivar Jacobson, Grady Booch and Jim Rumbaugh. If you have time in the class, demonstrate one way of prioritizing idea by having students vote with bucks. Use cumulative voting, where each student gets 3 votes. Have students raise their hands for each item they vote for, and write the number of votes on each idea’s post-it note.
What are some ways cumulative voting can be “cheated”?
Someone puts all their money on their item which is unpopular with everyone else.
What would have been better ways to pay for the features in the previous exercise?
Perhaps using “critical”, “important”, “useful” and weighting the
Now, what do you do after you have gathered all these “great ideas”?
After the idea gathering and pruning are over, organize and evaluate them.
There are many ways to evaluate them. One technique you can use to generate a pareto-like diagram is to use a process where the group “buys features”. Buying ideas is a way to do cumulative voting. Each person in the requirements workshop would receive a fixed number of dollars. A person gives one “vote” for an idea by putting a dollar on a particular idea.
For example, use cumulative voting, where each person gets three votes. People raise their hands for each item they vote for. The facilitator writes the number of votes on each idea’s post-it note.
This method can be abused if someone puts all their money on their item which is unpopular with everyone else.
An alternative to voting is to apply names such as “critical”, “important”, “useful” and weighting the
Rational University “bucks”
Module 5 - Understand Stakeholder Needs

33. Requirement Traceability Matrix

34. Define Scope
Define Scope is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the project, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope.

35. Define Scope

36. Define Project Scope
Since all of the requirements identified in Collect Requirements may not be included in the project, the Define Scope process selects the final project requirements from the requirements documentation delivered during the Collect Requirements process. It then develops a detailed description of the project and product, service, or result.
The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation. During project planning, the project scope is defined and described with greater specificity as more information about the project is known.
Existing risks, assumptions, and constraints are analyzed for completeness and added or updated as necessary.
The Define Scope process can be highly iterative. In iterative life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one iteration at a time and the detailed planning for the next iteration is carried out as work progresses on the current project scope and deliverables.

38. Decomposition and The Work Package
Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts.
The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed.
The level of decomposition is often guided by the degree of control needed to effectively manage the project.
The level of detail for work packages will vary with the size and complexity of the project.

39. Decomposition
Identifying and analyzing the deliverables and related work;
Structuring and organizing the WBS;
Decomposing the upper WBS levels into lower-level detailed components;
Developing and assigning identification codes to the WBS components; and
Verifying that the degree of decomposition of the deliverables is appropriate.

40. Sample WBS Decomposed Down Through Work Package

41. Sample WBS Organized by Phase

42. Sample WBS with Major Deliverables

43. WBS
The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work. The WBS is finalized by assigning each work package to a control account and establishing a unique identifier for that work package from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information. A control account is a management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Control accounts are placed at selected management points in the WBS. Each control account may include one or more work packages, but each of the work packages should be associated with only one control account. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account with known work content but without detailed schedule activities.

44. WBS Dictionary Code of account identifier, Description of work,
Assumptions and constraints,
Responsible organization,
Schedule milestones,
Associated schedule activities,
Resources required,
Cost estimates,
Quality requirements,
Acceptance criteria,
Technical references, and
Agreement information.

45. Scope Management Tension
Scope management is maintaining a “healthy tension” between what the customer wants (maximum features) and what development believes it can deliver in a fixed timeframe.
It is essential for the developer to get agreement from the customer regarding a baseline set of features to develop for the system to be built.
A good way to achieve the balance between customer desires and developer resources is by using iterative development and providing incremental “slices of the pie.” Then, the priorities can be reassessed at the end of each iteration.
The ideal time to decide what the baseline set of features we will actually develop is after the system is defined and before we have put a lot of time into refining the details.

46. Avoiding Scope Creep, But Allowing Change
‘Real’ requirements: Identify what is really needed (not want) to achieve business objectives.
Minimum requirements: A conscious practice of a minimum requirements strategy, no ‘gold plating’, no including what ‘might be needed.
All requirements should be recorded and identified by source.
Realize all requirements have a cost and schedule impact.
The use of an agreed negotiation and sanctioning process (it need not be heavyweight).
All requirements come (in the end) through a well-identified channel, not from various and sundry random sources.
Expectation management and communication with the customer about what will be in each iteration (via prototyping and iterative development). This helps uncover hidden requirements, unknown to the naïve developer but assumed by the domain-experienced customer.

47. Uses for Requirement Attributes
MRMUC Instructor Notes
Attributes link project elements
Maybe your resources are limited, so that is a key factor in the lifecycle or some requirement s are necessary or mandatory for release. With attributes, you are able to see the impact each requirement has on the project.
Use examples to illustrate these uses of attributes. For example, by adding up the estimated costs of each requirement , you get an estimated total cost for developing the entire system.
Ask: How would you use requirement attributes to assess project status?
Of course, you cannot use requirement attributes for managing a project unless you have recorded the attribute values for each requirement . For example, you cannot use the requirement cost attribute for estimating total cost unless you have recorded cost for each requirement . You need to have good data before you can use it.
Status
Risk
Priority
Cost
Effort
FEAT 10
$$$
Approved Low High
FEAT 13 $$
Proposed Medium Low
Once you have a list of features in the baseline scope, the features need to be allocated to iterations so they can be implemented in a manner that removes the project risk and delivers important functionality as early as possible. Attributes play a key role in this decision process.
Requirement attributes provide a link between requirements and other project elements. For example, “status” provides the current status of each requirement and “effort” estimates the work involved to do each requirement. Among the uses for requirement attributes are:
Managing project scope
Assigning resources
Scheduling
Assessing status
Calculating software metrics
Managing project risk
Estimating costs
Assuring user safety
Attributes can be specified for all types of requirements: needs, features, use cases, supplementary requirements. The attributes to collect at each level are based on what information is needed for management reports and other uses.
The funnel icons represent a typical filter that an architect may apply when analyzing requirements to help make management decisions. In the above example the filter would be: “Show me all requirements with a status of APPROVED and a risk of HIGH RISK and a priority of HIGH and an effort of LOW.”
FEAT 40
Approved High High $
= Filter
Module 7 - Manage the Scope of the System

48. Process Helps Manage Scope
MRMUC Instructor Notes
Process Helps Manage Scope
Scope management and change management are inextricably linked.
New Feature
Reqt
Customer and User inputs
Single Channel
for Approval
New
Requirement
Design
Marketing
Approved Decision Process
(CCB: Change Control Board)
A key factor in managing scope is an effective change management process. As requests come in during our lifecycle, intercept them, and pass through a single approval channel.
Requests can then be assessed according to criteria such as: origin, customer priority, support of business goals, and impact on schedule.
The single channel of approval may be one person (like a project manager) or perhaps a group of representatives (for example; a CCB, Change or Configuration Control Board). The CCB should have representatives from each of the relevant groups.
Code
Coders inputs
Testers inputs
Bug
Change Request (CR)
Test
Help Desk
User inputs
Maint
Module 7 - Manage the Scope of the System

49. MRMUC Instructor Notes
Manage Expectations
MRMUC Instructor Notes
Why manage expectations?
So customers understand why you are deferring functionality
People perceive things differently
Things happen
This is key on both the customer (especially) and the developer side.
One of the keys to having happy customers at delivery time is to manage their expectations of what they are to receive.
A new car!
A new car!
Gause & Weinberg, 1989
Module 7 - Manage the Scope of the System

50. How to Manage Expectations
MRMUC Instructor Notes
Understand customer expectations.
Limit the expectations as appropriate.
Include the source of the limitation.
Under-promise and over-deliver.
Keep the possibilities open.
Communication is very important; no surprises.
Module 7 - Manage the Scope of the System

51. Improve Your Negotiation Skills
MRMUC Instructor Notes
Improve Your Negotiation Skills
Start negotiations with high demands, but don’t be unreasonable.
Separate the people from the problem.
Focus on interests, not positions.
Understand your Best Alternative To a Negotiated Arrangement (BATNA) – Bottom line.
Invent options for mutual gain (win-win).
Use diplomacy.
The information on this slide is from the Fisher & Ury book: Getting to Yes. These men worked with the Harvard Negotiation Project, which did studies of high-level (mostly diplomatic) negotiations and what made them successful.
Negotiation skills are key to any successful, multi-party program. Improving these skills is a normal, professional activity that everyone should spend time on.
This information is from Getting to Yes, by Fisher and Ury. Fisher and Ury worked with the Harvard Negotiation Project, who studied high-level (mostly diplomatic) negotiations and evaluated what made them successful.
The concept of BATNA (Best Alternative To a Negotiated Agreement) encourages you to also look at the consequences of not getting an agreement. How important is that to you? What if the customer cancels the project? This gives you a bottom line from which to work.
The key is to focus on the interests of all involved and attempt to come up with creative options that would satisfy both sides.
Improve your skills at every opportunity.
Fisher, Ury, Getting to Yes, 1991
Module 7 - Manage the Scope of the System

52. MRMUC Instructor Notes
The Product Champion
MRMUC Instructor Notes
Prevents projects from drifting into a technical or political abyss.
Helps manage project scope.
Owns the product vision.
Advocates for the product.
Defends against feature creep.
Negotiates with management, users, and developers.
Maintains a balance between customer needs and what can be delivered on time.
Represents the official channel between the customer and the development team.
Relate this slide back to the Standish CHAOS Report slide in Module 2. “Without a staunch project champion with a solid business vision, projects can drift into a technical or political abyss.”
This is a good time to have people in the class share stories of projects they have been involved with, in which a “product champion” (or the lack of one) was key in making or breaking a project.
Usually this is not a job title, but a role played by a key individual.
You may want to have one on both the development side and the customer side.
At what level in your company would this person be to be effective? (The key is that they must have enough authority to make things happen.)
The product champion is a very important, yet often intangible, aspect of having a successful project.
Usually this is not a job title, but a role played by a key individual.
Would you want to have a product champion on the development side or the customer side?
At what level in your company would this person need to be at to be effective?
The notion of a product champion is supported by the research performed by the Standish Group (refer to Module 2). Their findings were: “Without a staunch project champion with a solid business vision, projects can drift into a technical or political abyss.”
Module 7 - Manage the Scope of the System