Project Agreement: A document written for a client that defines: the scope, duration, cost and deliverables for the project the exact items, quantities, delivery dates, delivery location Client: Individual or organization that specifies the requirements and accepts the project deliverables Deliverables: Work Products to be delivered to the client Documents Demonstrations of functional requirements Demonstration of nonfunctional requirements Demonstrations of subsystems The form of a project agreement can be a contract, a statement of work, a business plan, or a project charter.

1.1 Project Overview Executive summary: description of project, product summary 1.2 Project Deliverables All items to be delivered, including delivery dates and location 1.3 Evolution of the SPMP Plans for anticipated and unanticipated change 1.4 Reference Materials Complete list of materials referenced in SPMP • 1.5 Definitions and Acronyms

Lecture 3: Flashcards by Andreas Hein

Software Project Management Plan

Review: Software Project

A software project has a specific duration, schedule, consumes resources and produces work products
All technical and managerial activities required to deliver the deliverables to the client
Management activities to complete a software project: Tasks, activities, project functions

Software Project Management Plan (SPMP)

The controlling planning document for a software project
Specifies the technical and managerial approaches to develop the software product
Companion document to the requirements analysis and system design documents: Changes in either may imply changes in the other documents
The SPMP may be part of the project agreement.

How well did you know this?

Not at all

Perfectly

Project Agreement

Project Agreement: A document written for a client that defines:
- the scope, duration, cost and deliverables for the project
- the exact items, quantities, delivery dates, delivery location
Client: Individual or organization that specifies the requirements and accepts the project deliverables
Deliverables: Work Products to be delivered to the client
- Documents
- Demonstrations of functional requirements
- Demonstration of nonfunctional requirements
- Demonstrations of subsystems
The form of a project agreement can be a contract, a
statement of work, a business plan, or a project charter.

How well did you know this?

Not at all

Perfectly

How much planning should you do?

Two styles of navigation [Gladwin 1964]
- Europeannavigation (TraditionalPlanning)
- Polynesian navigation (Agile Planning)
The main difference between the two styles is the reaction to unexpected events (“change”).

How well did you know this?

Not at all

Perfectly

Project Plan (European Navigation)

Project Goal: Sail to Auckland Desired Outcome: Auckland is found Team: Captain and 50 sailors Organization: Hierarchical
Tools: Compass, speed meter, map

Methods: Captain determines course and writes it up before departure. Example: Start Lima. Sail West, keep the compass constantly at 97 degrees, stay at latitude 20 degrees

Tasks:

Task T1 (Check direction): Determine current direction of ship
Task T2 (Compute deviation): Determine deviation from course
Task T3 (Course Correction): Bring ship back on course

Wayfinding Process: T1 and T2 are executed hourly. If there is a deviation, T3 is executed to bring the ship back on the planned course

Schedule: With good wind conditions: 50 days; with doldrums 85 days.

How well did you know this?

Not at all

Perfectly

Project Plan Polynesian

Project Goal: Improve Living Desired Outcome: A livable place

Team: Navigator and 20 rowers Organization: Hierarchical

Tools: Navigator uses stars for navigation, checks water temperature with his hands

Methods: A set of event-action rules. When an event occurs, the action is based on the current context

Tasks:

Task T1 (Determine direction): Set direction of ship to a course
Task T2 (Check Clouds): Look for stationary clouds in the distance
Task T3 (Check Birds): Look for birds and determine their direction
Task T4 (Compute course): Determine new course for ship
Task T5 (Change course): Change direction to follow new course

Wayfinding Process: Start with T1. Then execute T2 and T3 regularly. Interpret task results (cloud detected, birds detected) in the current context. If the interpretation makes a new course more promising, execute tasks T4 and T5.

Schedule: None

How well did you know this?

Not at all

Perfectly

Situated action [Suchman 1990]

Situation Action: Selection of action depends on the type of event, the context (situation) and the skill of the developer. Also called context-dependent action

Events: Deviation from course, Birds are seen, Clouds are seen

European Navigation uses context independent actions:
- Event: “Course deviation in the morning”
  - => Action: “Course correction towards planned route”
- Event: “Course deviation in the evening”
  - => Action: “Course correction towards planned route”
Polynesian Navigation uses context dependent actions:
- Event: “Birds seen”, Context: “It is morning”
  - => Action: “Sail opposite to the direction the birds are flying”
- Event: “Birds seen”, Context: Evening
  - => Action: “Sail in the direction the birds are flying.

How well did you know this?

Not at all

Perfectly

Software Project Management Plan: SPMP Front Matter

Title Page
Revision sheet (update history)
Preface: Scope and purpose
Tables of contents, figures, tables

How well did you know this?

Not at all

Perfectly

SPMP Introduction

1.1 Project Overview
- Executive summary: description of project, product summary
1.2 Project Deliverables
- All items to be delivered, including delivery dates and location
1.3 Evolution of the SPMP
- Plans for anticipated and unanticipated change
1.4 Reference Materials
- Complete list of materials referenced in SPMP
• 1.5 Definitions and Acronyms

How well did you know this?

Not at all

Perfectly

SPMP Part 2: Project Organization

2.1 Process Model
- Relationships among project elements
2.2 Organizational Structure
- Managementstructure: reporting,decisionand communication structure , organization chart
2.3 Organizational Interfaces
- Relations with other entities (subcontractors, commercial software)
2.4 Project Responsibilities
- Major project functions and activities; nature of each; who is in charge
- Matrix of project functions/activities vs. responsible individuals.

How well did you know this?

Not at all

Perfectly

SPMP Part 3: Managerial Process

3.1 Management Objectives and Priorities
- Describes management philosophy, priorities among requirements, schedule and budget
3.2 Assumptions, Dependencies and Constraints •
- External events the project depends on, constraints under which the project is to be conducted
3.3 Risk Management
- Identification and assessment of risk factors, mechanism for tracking risks, implementation of contingency plans
3.4 Monitoring and Controlling Mechanisms
- Frequency and mechanisms for reporting
3.5 Staffing Plan
- Numbers and types of personnel required to conduct the project.

How well did you know this?

Not at all

Perfectly

Examples of Risk Factors

Contractual risks
- What do you do if the customer becomes bankrupt?
Size of the project
- What do you do if you feel the project is too large?
Complexity of the project
- What do you do if the requirements are multiplying during analysis? („requirements creep“)
Personal
- How do you hire people? Is there a danger of people leaving the project?
Customer acceptance
- What do you do, if the customer does not like the delivered system?

How well did you know this?

Not at all

Perfectly

SPMP Part 4: Technical Process

2.1 Methods, Tools and Techniques
- Specify the methods, tools and techniques to be used on the project
2.2 Software Documentation
- Describe the documentation plan
2.3 Project Functions
- Plans for (at least) the following project functions.
  - Plan to ensure quality assurance
  - Configuration management plan (IEEE Std 1042) • Verificationandvalidation plan
- These plans can be included in section 2.3 or there is a reference to a separate document.

How well did you know this?

Not at all

Perfectly

SPMP Part 5: Description of Work Packages

Work Breakdown Structure (WBS) (Section 5.1) #

Hierarchical decomposition of the project into activities and tasks

Dependencies between tasks (Section 5.2)

Structural relationships between tasks: “consists of”
Temporal relationship between tasks: “must be preceded by”
❖ Visualization of temporal dependencies: dependency graph
- Nodes are activities
- Lines represent temporal dependencies.

How well did you know this?

Not at all

Perfectly

Work Breakdown Structure

Work Breakdown Structure: The aggregation of all the work to be performed in a project.

How well did you know this?

Not at all

Perfectly

Creating Work Breakdown Structures

Two major philosophies
- Activity-oriented decomposition („functional decomposition“)
  - Example: Write the book, Get it reviewed, Do the suggested changes, Get it published
Result-oriented decomposition („Object-oriented decomposition“)
- Example: Chapter 1, Chapter 2, Chapter 3
Which one is best to manage? Depends on the project type:
- Development of a prototype
- Development of a product
- Project team consist mostly of inexperienced beginners
- Projectteamconsistsof experienceddevelopers

How well did you know this?

Not at all

Perfectly

Approaches to Develop a WBS

Product component approach

Structure the work around the work products
Example: Design documents, manuals, delivered system

Functional approach

Structure the work around development activities
Example: Analysis, design, implementation, integration

Geographical area approach

Structure the work based on the geographical location
Example: Munich team, off-shore team

Organizational approach

Structure the work based on the organization
Example: Line organization with R&D, predevelopment,

product development, marketing, sales.

Agile approach

Structure the work as a to-do list
Example: Product backlog, sprint backlog.

When to use what Approach

The teams are distributed over the continent: •
- Geographical area approach
The teams consist of experienced developers: •
- Product component or agile approach
The project consists mostly of beginners or has an inexperienced project manager:
- Functional approach
The project is a continuation of a previously successful project, there are no changes in the requirements and no new technology enablers:
- Organizational approach

Whatever approach you choose, stick with it to prevent possible overlap in categories.

Risk Management: Identifying Risky Activities

When you identify activities for a WBS, you can also identify the risks in your project
Risks are usually associated with “unknown information”
Unknown information comes in two flavors
- “known unknown”: Information that you don’t have but someone else does
  - Find out who has the information and determine what the information is (Interviews, Phone calls, tasks analysis)
- “unknown unknown”: Information that you don’t have because it does not yet exist
Develop contingency plans for each of these risks
- These contingency plans need be followed when you find out the information cannot be obtained or does not exist
•Describe these risks in SPMP 3.3 Risk Management.

Contingency Plan Examples

Risk: Members in key roles leave the project •
- Contingency Plan:
  - A: Roles are assigned to somebody else
  - B: Functionality of the system is renegotiated with the client
Risk: The project is falling behind schedule •
- Contingency Plan:
  - Extra project meetings are scheduled
Risk: Team 1 cannot deliver functions needed by team 2
- Contingency Plan:
  - A:The team liaisons get together to solve this problem • B: We drop the functionality
Risk: The planned platform will not be available in time
- Contingency Plan:
  - • We will use a simulator instead.

Risk Management Examples

Risk: Selection of the database system takes too much time
- Contingency Plan:
  - The Database team uses a bridge pattern and provides a mock to be used while the selection process goes on
Risk: The customer is not available for discussing and reviewing the user interface during development
- Contingency Plan
  - Make the design decisions that we feel are appropriate
Risk: No suitable indoor navigation system can be found
- Contingency Plan
  - The teamdevelopsitsownsolution.

Displaying Work Breakdown Structures

Three different formats are commonly used

Organization-chart format
- Effectively portrays an overview of your project and the hierarchical relationships of different activities and tasks
Outline format
- Sub-activities and tasks are indented below activities • Backlog: Outline format without indentation.
Bubble format
- The bubble in the center represents your project
- Lines from the center bubble lead to activities
- Lines from activities lead to tasks.

What is the best display format for WBS?

Org-chart format
- Often good for a “bird view” (executive summary)
- Less effective for displaying large numbers of activities
Outline format
- Easier to read if WBS contains many activities
- Good for agile projects, or people experienced with the project
Bubble format
- Effective for brainstorming
- Not so good for people not familiar with the project
Advice for large projects:
Start with the bubble format to develop the WBS
Then turn it into a mix of org-chart or outline format
- Display activities in org-chart format
- Display sub-activities and tasks in outline format.

Heuristics for developing a high quality WBS

Involve the people who will be doing the work in the development of the WBS
- In particular involve the developers
Review information from a WBS developed for a similar project
- Use a project template if possible
Use more than one WBS approac
- - Use project component & functional approach at the same time
- - This allows you often to identify overlooked activities
Make assumptions regarding uncertain activities
- - Identify risky activities
- - These are the activities whose times are hard to estimate.

WBS in Agile Projects

Identify product backlog and number of sprints (Project kickoff meeting)
For each Sprint:
- Start the Sprint by planning the WBS for the Sprint (Sprint planning meeting)
- List all tasks that can be completed in this Sprint WBS = Sprint Backlog •
- Prioritize the tasks
- Perform the tasks
At the end of each Sprint
- • Sprint review meeting: Identify the unfinished tasks and
- put them back into the product backlog
- • Sprint review meeting and Sprint planning meeting for the next Sprint are often done together
- • Update the SPMP.

Project-Initiation

* Activities * Meet with client, identify scope and visionary scenarios * Develop initial top level design * Establish staffing plan (flat staffing, ramping up) * Identify human resources: existing and new employees * Start hiring * Assign a subsystem to each team. Establish additional cross- functional teams (e.g. architecture, release management) * Write the problem statement with the client * Write the initial SPMP * Establish the WBS * Get project plan approved * Duration: Between 2-8 weeks * When: During Definition Phase.

Initial Planning List

* Activities * Scouting: Identify technology enablers that might influence * the design or the nonfunctional requirements * • Revise initial requirements and top level design * • Revise team structure, reassign team members if necessary * • Revise WBS and dependencies * • Establish cost and scheduling information * • Agree on requirements, duration and cost of the project * • Write the contract (“project agreement”) * Duration: About 2 weeks time * When: Before Start State (Project Kickoff) * Often called “planning phase” * Alternative: Immediately after project kickoff (Start) * Parallel to “requirements elicitation phase”.

Project-Termination

* Do a project-review: “What went right, what went wrong” * Often called “project post-mortem review” or “retrospective” * Based on input from the post-mortem session * Identify any new activities that were needed in the project. Tailor your software process accordingly * Revise your planning project kickoff activities * Revise the SPMP template (to be reused for your next project).

Summary

* Different approaches to develop a WBS * Product Approach * Functional Approach * Geographical Approach * Organizational Approach * Top down and bottom up WBS development • Heuristics for developing good WBS * WBS for Large Projects.

When the project has an inexperienced project manager, it is better to use the Select one or more: a. Agile approach b. Organizational approach c. Functional approach

A Project Agreement Select one or more: a. Can be in the form of a contract, a statement of work, a business plan or a project charter b. Is a document written for a client c. Defines the work products to be delivered d. Defines the scope, duration and cost for the project

a,b,c,d

The major WBS creation philosophies are Select one or more: a. Cost-oriented decomposition b. Activity-oriented decomposition c. Time-oriented decomposition d. Team-oriented decomposition e. Result-oriented decomposition

b,e

Which approaches can be used to develop a WBS? Select one or more: a. Organizational b. Agile c. Resources d. Product component e. Functional f. Geographical Area g. Time

a,d,e,f,b

Which factors lead to a high quality WBS? Select one or more: a. Compare with projects from other domains b. Use more than one WBS c. Assume each project is similar, therefore assume similar effort d. Involve the developers

d,b

Which of these activities are done in the Project-Initiation phase? Select one or more: a. Develop initial top level design b. Write the initial SPMP c. Write the contract d. Do a project review e. Establish the WBS

a,b,e

Select the correct alternatives which relate how to use WBS in Agile projects Select one or more: a. At the end of a sprint, unfinished tasks are put back to the Product backlog b. The WBS comprises the Sprint Backlog, as well as all documentation of the project c. The SPMP should be updated after each Sprint d. The WBS should be planned once for the whole project Feedback

a,c,