BEN610-T1-S1-2008

BEN610—PROJECT MANAGEMENT PRINCIPLES

Project Management Development and Delivery Methodologies

Queensland University of Technology

CRICOS No. 00213J

RemindersReminders

• You will need access to the PMBoK in class and during the i l i ll i k d b dtutorials especially in Week 3 and beyond

• Please take the ‘Getting to Know the BEN610 Class’ survey: l 30% h d dless 30% have responded. – Want to break the 70% barrier by Friday

– Otherwise we won’t have a good profile of the classOtherwise we won t have a good profile of the class

RemindersReminders

Assessment Item No. 1Assessment name: Short Case Study ExerciseDescription: The objective of the assignment is to test your general understanding of the theory as presented in the first five weeks of the unit. You are to write a 1500 word Brief to your CEO identifying three major project management problems, analysing the impact of these problems, and then,management problems, analysing the impact of these problems, and then, recommending and justifying changes to rectify these problems. Feedback will be given approximately one week after your completion of the exercise.Weight: 25%G I di id l I di id lGroup or Individual: IndividualDue date:Week 6

RemindersReminders

Assessment Item No. 1Assessment name: Short Case Study ExerciseDescription: The objective of the assignment is to test your general understanding of the theory as presented in the first five weeks of the unit. You are to write a 1500 word Brief to your CEO identifying three major project management problems, analysing the impact of these problems, and then,management problems, analysing the impact of these problems, and then, recommending and justifying changes to rectify these problems. Feedback will be given approximately one week after your completion of the exercise.Weight: 25%G I di id l I di id lGroup or Individual: IndividualDue date:Week 6

Project Simulation—Saturday 28 May 2011

Tentative Topic ScheduleTentative Topic Schedule

• Week 1: Introduction • Week 8: Quality

• Week 2: Development and Delivery Methodologies

W k 3 S

• Week 9: People

• Week 10: Communications• Week 3: Scope

• Week 4: Schedule

W k 5 C

• Week 11: Procurement

• Simulation Saturday: 28 May 2011• Week 5: Cost

• Week 6: Risk

k

• Week 12: Portfolio and Program Management

k• Week 7: Integration • Week 13: Exam preparation

Revision

j iA project is:a) A set of sequential activities performed in a

process or system.b) A revenue‐generating activity that needs to be

accomplished while achieving customer satisfaction.

c) An ongoing endeavour undertaken to meet customer or market requirements.

d) A temporary endeavour undertaken to create a unique product, service, or result.

Anbari, F. T. (2009). Q&As for the PMBoK guide (4th ed.). Newtown Square, Pennsylvania: Project Management Institute.

AnswersAnswers

A project is:a) A set of sequential activities performed in a process

or system.

b) A revenue‐generating activity that needs to be accomplished while achieving customer satisfaction.

c) An ongoing endeavour undertaken to meet ) g gcustomer or market requirements.

d) A temporary endeavour undertaken to create a ) p yunique product, service, or result. PMBoK Sec 1.2


j iProject management is:a) The integration of the critical path method and the

E d V l M t tEarned Value Management system.b) The application of knowledge, skills, tools, and

techniques to project activities to meet projecttechniques to project activities to meet project requirements.

c) The application of knowledge skills wisdomc) The application of knowledge, skills, wisdom, science, and art to organizational activities to achieve operational excellence.

d) A subset of most engineering and other technical disciplines.


j iProject management is:a) The integration of the critical path method and the

E d V l M t tEarned Value Management system.b) The application of knowledge, skills, tools, and

techniques to project activities to meet projecttechniques to project activities to meet project requirements. PMBoK Sect 1.3

c) The application of knowledge skills wisdomc) The application of knowledge, skills, wisdom, science, and art to organizational activities to achieve operational excellence.

d) A subset of most engineering and other technical disciplines.


Managing a project typically includes:Managing a project typically includes:a) Balancing the competing project constraints

including scope quality schedule budgetincluding scope, quality, schedule, budget, resources, and risk.

b) Integrating requirements of profitability lowb) Integrating requirements of profitability, low cost, and legal responsibility.

c) Implementation of software hardware andc) Implementation of software, hardware, and other systems to enhance organizational efficiencyefficiency.

d) Supporting human factors, communications, discipline and performance managementdiscipline, and performance management.


Managing a project typically includes:a) Balancing the competing project constraints

including scope, quality, schedule, budget, resources, and risk. PMBoK Sect 1.3

b) Integrating requirements of profitability, low cost, and legal responsibility.

c) Implementation of software, hardware, and other systems to enhance organizational efficiency.

d) h fd) Supporting human factors, communications, discipline, and performance management.


Project success is measured by:a) Degree to which the project satisfies its time and

budget objectives.

b) Triple constraints of schedule, cost, and technical performance.

c) Product and project quality, timeliness, budget compliance, and degree of customer satisfaction.

d) Degree to which the project satisfies the needs for ) g p jwhich it was undertaken and its long‐term contribution to aggregate performance of the organization’s portfolio.


Project success is measured by:a) Degree to which the project satisfies its time and

budget objectives.b) Triple constraints of schedule, cost, and technical

performance.c) Product and project quality, timeliness, budget

compliance, and degree of customer satisfaction. PMBoK Sect 1 4PMBoK Sect 1.4

d) Degree to which the project satisfies the needs for which it was undertaken and its long‐termwhich it was undertaken and its long term contribution to aggregate performance of the organization’s portfolio.


All of the following are true about projects andAll of the following are true about projects and operations EXCEPT:a) Operations are ongoing, repetitive, and permanent

endea o rs hile projects are temporar endea o rsendeavours while projects are temporary endeavours.b) Projects require project management while operations

require business process management or operations management.

c) Projects can intersect with operations at various points during the product life cycle At each point deliverablesduring the product life cycle. At each point, deliverables and knowledge are transferred between the project and operations for implementation of the delivered work.

d) Projects because of their temporary nature cannot helpd) Projects, because of their temporary nature, cannot help achieve an organization’s goals. Therefore, strategic activities in the organization can be generally addressed ithi th i ti ’ l tiwithin the organization’s normal operations.


All of the following are true about projects and operations EXCEPT:) O ti i titi d ta) Operations are ongoing, repetitive, and permanent

endeavours while projects are temporary endeavours.b) Projects require project management while operations require

b i t ti tbusiness process management or operations management.c) Projects can intersect with operations at various points during

the product life cycle. At each point, deliverables and k l d f d b h j dknowledge are transferred between the project and operations for implementation of the delivered work.

d) Projects, because of their temporary nature, cannot help h ’ l h fachieve an organization’s goals. Therefore, strategic activities

in the organization can be generally addressed within the organization’s normal operations. PMBoK Sect 1.5


• Who are the two peak international project management standards setting group?

• What are the names of their respectiveWhat are the names of their respective project management frameworks?

• Who are the two peak international project management standards setting group?g g g pOffice of Government Commerce, UK Government (OGC)

Project Management Institute (PMI)j g ( )

• What are the names of their respective project management frameworks?project management frameworks?– OGC—PRINCE2

– PMI—PMBoK

• What are the nine key project management knowledge areas according to the PMBoK?


What are the nine key project management y p j gknowledge areas according to the PMBoK?

Project Integration Project Time ManagementProject Scope Management

Develop Project CharterDevelop Project Management PlanDirect and Manage Project Execution

Define ActivitiesSequence ActivitiesEstimate Activity ResourcesEstimate Activity

ManagementCollect RequirementsDefine ScopeCreate WBSVerify ScopeControl Scope

Monitor and Control Project WorkPerform Integrated Change ControlClose Project or Phase

DurationsDevelop ScheduleControl Schedule

Project Cost Management

Estimate CostsDevelop BudgetControl Costs

Project Quality Management

Plan QualityPerform Quality AssurancePerform Quality Control

Project Human Resource Management

Develop Human Resource PlanAcquire Project TeamDevelop Project Team

Project Communications Management

Project Risk Management

Perform Quality Control

Project Procurement Management

Develop Project TeamManage Project Team

ManagementIdentify StakeholdersPlan CommunicationsDistribute InformationManage Stakeholder ExpectationsReport Performance

Plan Risk ManagementIdentify RisksPerform Qualitative Risk AnalysisPerform Quantitative Risk Analysis

ManagementPlan ProcurementsConduct ProcurementsAdminister ProcurementsClose Procurements

Report Performance AnalysisDevelop Risk Response PlansMonitor and Control Risks

• In PRINCE2, what document justifies the continuing viability of the project? g y p j

• What are the major topics which it addresses?

• In PRINCE2, what document justifies the continuing viability of the project?g y p j– The Business Case

• What are the major topics it addresses– Reasons, Business Options, Benefits, Timescales, Costs, Investment Appraisal, RisksCosts, Investment Appraisal, Risks

h fi jThe five Project Management Process Groups are:a) Planning, Checking, Directing, Monitoring, and

Recording.b) Initiating, Planning, Executing, Monitoring and

Controlling, and Closing.c) Planning, Executing, Directing, Closing, and

Delivering.d) Initiating, Executing, Monitoring, Evaluating, and

Closing.


h fi j• The five Project Management Process Groups are:a) Planning, Checking, Directing, Monitoring, and

Recording.b) Initiating, Planning, Executing, Monitoring and

Controlling, and Closing.c) Planning, Executing, Directing, Closing, and

Delivering.d) Initiating, Executing, Monitoring, Evaluating, and

Closing.

Ancient Projects QuizAncient Projects Quiz

• Can you correctly name the twelve ancient projects pictured in the Week One presentation? p

• First correct answer in each tutorial and then a drawing in class during Week 3!a drawing in class during Week 3!

http://www.youtube.com/user/projectlessons#p/a/u/1/C1uxCBx2‐UQ

Product and Project Lifecycle‐Revisited

http://www.iibc.com/transiting‐the‐life‐cycle/

Product versus Project Lifecyclej y

Product Lifecycle

P j Lif lProject Lifecycle

Project OperationsOr Business as Usual

DivestmentOr Business as Usual

The Simplest Project LifecycleThe Simplest Project Lifecycle

Startingthe

j

Organising and

i

Carrying out the work Closing the

jproject preparing project

ProjectCharter

ProjectManagement Plan

AcceptedDeliverables

ArchivedProjectDocuments

Project Management

DocumentsOutputs Time

Project LifecycleProject Lifecycle

• What trends might be see over the project lifecycle in:– Staffing levelsStaffing levels

– Ability of stakeholders to influence the characteristics of the delivered productcharacteristics of the delivered product

– Cost to make major changes

– Uncertainty and risk to achieve project objectives

32

Project LifecycleCost & Personnel LevelsCost & Personnel Levels

33(2008). A Guide to the Project Management Body of Knowledge. Newtown Square, Pennsylvania: Project Management Institute, p.16

Project LifecycleStakeholder Influence & Cost of ChangesStakeholder Influence & Cost of Changes

Initial Intermediate Final

34


(2008). A Guide to the Project Management Body of Knowledge. Newtown Square, Pennsylvania: Project Management Institute, p. 17

Project Lifecycle—Riskj yRisk

Time


35


(2004). A Guide to the Project Management Body of Knowledge. Newtown Square, Pennsylvania: Project Management Institute, p. 21

• In the tutorial, you’ll compare the different product and project life‐cycle models used in p p j ythe organizations represented by the course membersmembers

• Bring along an example of the project lifecycle h h h lwhich your organisation uses to the tutorial

Must project have well‐defined objectives and processes?

What is the difference between an objective and a process?process?

What is the difference between an objective and a process?process?

The Objective relates to theWHAT we want to achieve andThe Objective relates to the WHAT we want to achieve and the Process relates to the HOW we will achieve or attain the objectivethe objective

Objectives

Process

What is a project revisited?What is a project—revisited?

• A project is a temporary endeavour undertaken to create a unique product, service, or results

• The temporary nature of projects indicates a definite beginning and enddefinite beginning and end

• The end is reached when the project’s objectives h b hi d h th j t ihave been achieved or when the project is terminated because its objectives will not or

b h h d f h jcannot be met, or when the need for the project no longer exists

Following the catastrophic failure of an multi‐hundred million dollar ICT project, an edict was issued by the CEO that:

“No project should be authorized or funded unless the project has specific, measurable and certain objectives and well‐defined and certain processes to achieve those objectives!”

Is this a good rule?

Under all circumstances or are there are exceptions?

But do the exceptions become a ‘slippery slide’?

Managing Project ComplexityWhat & HOW (WHOW) Model

Dombkins’ WHOW MatrixDimensions of Uncertainty

WHAT—Uncertainty in WHAT the project objectives are?

HOW

UncertaintyHigh Low

Dombkins, D. H. (2007). Complex Project Management: Seminal Essays. North Charleston, South Carolina: BookSurge Publishing, p. 392.

Dombkins’ WHOW MatrixDimensions of Uncertainty

LLowy

HOW—Uncertainty in HOW to achieve the project objectives

WHAT

Uncertainty

U

High

HOW

UncertaintyHigh Low


Dombkin’s WHOWMatrixDombkin s WHOW MatrixLLow

T pe B T pe A

y

Type B Type A

WHAT

Uncertainty

Concept

U

Type CType D

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low



T pe B T pe A

y

Type B Type A

Identify one example of each project type!WHAT

Uncertainty

y p p j yp

Concept

U

Type CType D

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low



T pe B T A

y

Type B Type A

WHAT

Uncertainty

Concept

U

Type CType D

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low


Type A ProjectsType A ProjectsLLow

y

WHAT

Uncertainty

Concept

U

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low

Dombkins, D. H. (2007). Complex Project Management: Seminal Essays. North Charleston, South Carolina: BookSurge Publishing, pp. 396=397


T B T pe A

y

Type B Type A

WHAT

Uncertainty

Concept

U

Type CType D

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low


Type B ProjectsType B ProjectsLLow

y

WHAT

Uncertainty

Concept

U

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low

Dombkins, D. H. (2007). Complex Project Management: Seminal Essays. North Charleston, South Carolina: BookSurge Publishing, pp. 397‐398.


T pe B T pe A

y

Type B Type A

WHAT

Uncertainty

Concept

U

Type CType D

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low


Type C ProjectsType C ProjectsLLow

y

WHAT

Uncertainty

Concept

U

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low



T pe B T pe A

y

Type B Type A

WHAT

Uncertainty

Concept

U

Type CType DDesign

ImplementationHigh

Close

HOW

UncertaintyHigh Low


Type D ProjectType D ProjectLLow

y

WHAT

Uncertainty

Concept

U

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low


Dombkins, D. H. (2007). Complex Project Management: Seminal Essays. North Charleston, South Carolina: BookSurge Publishing, pp. 396=397

Dombkin’s WHOWMatrixDombkin s WHOW Matrix

LLowyFor two of your earlier examples, use the

WHAT

Uncertainty

y p ,WHOW matrix to determine how you might approach development!

Concept

Uapproach development!

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low


Dombkin’s WHOWMatrix TemplateDombkin s WHOW Matrix Template

LLowy

WHAT

Uncertainty

Concept

U

Design

ImplementationHigh

Close

HOW

UncertaintyHigh Low


D l t D li&Development Delivery&

for the Project Complexity Types



Build and Fix Model—“She’ll be Right Mate”She ll be Right Mate

Build first version

Modify as required by customer

Maintenance

Retirement

Build and Fix Model—“She’ll be Right Mate”She ll be Right Mate

Build first version

Modify as required by What are the advantages and disadvantages?customer

g g

Maintenance

Retirement

WaterfallWaterfallSystem Requirements

Software Requirements

Preliminary Design

Detailed Design

Code and Debug

Test and Pre ‐Operations

Operations & Maintenance



Preliminary Design

Wh is it called “Waterfall”?Detailed Design

Why is it called “Waterfall”?

Code and Debug



WaterfallWaterfall

• Description– Two dimensional

– Single entity

– Requirements flow‐down

– Sequential

– Feedback loops between successive phase

– Documentation driven

Czarneck, K. (u/d). Software Life‐Cycle and Process Models. Retrieved 25 May, 2008, from www.swen.uwaterloo.ca/~se2/lecture/02_life‐cycle‐models.pdf



Preliminary Design

What do you think are the Detailed Design

yadvantages and disadvantages!

Code and Debug



WaterfallWaterfall• Advantages

– Documentation and clearly definedphases

– Orderly developmentDi d• Disadvantages– Customer involvement in first phase only– Completed and frozen specification document up‐front

often not possibleoften not possible– Sequential and complete execution of phases is often not

desirable– Product becomes available very late in the process y p

(significant risk of building the “wrong” system)—i.e. verification without validation

– System architecture and the issues of integration, verification and validation are not representedverification, and validation are not represented.

• Applicability– Only appropriate when the requirements are well‐

understoodunderstood


• How might prototyping compare with traditional structured approaches like ppwaterfall?

PrototypingPrototyping

http://www.smashingmagazine.com/2010/06/16/design‐better‐faster‐with‐rapid‐prototyping/

http://www.smashingmagazine.com/2010/06/16/design‐better‐faster‐with‐rapid‐prototyping/

Rationale

• Users may not know what they want until they have it!!!y y y• Traditional specifications often obfuscate rather than clarify• The more people involved the greater the communication

challenges• Documentation associated with traditional approaches is

ti i t d l d i t i– time consuming to develop and maintain– quickly dates

• Traditional approaches appear to deliver an unsuitable pp ppproduct late

What do you think are the yadvantages and disadvantages!

AdvantagesAdvantages

• Fast development

• Early and continuous customer involvement & commitmentEarly and continuous customer involvement & commitment

• Enhances communication between developers and customers

• Development cost typically lessDevelopment cost typically less

• Increases user acceptance

DisadvantagesDisadvantages

• Unreasonable user expectationsp

• Inconsistencies between prototype and final system

• Accumulated inefficiencies—lack of system rationalisationy(especially in large systems)

• Development may meander

• Failure to conduct proper analysis

• May ignore critical human factors issuesy g

• Poor documentation & an unmaintainable system

Rapid or Throwaway PrototypingRapid or Throwaway Prototyping

• Description• Description– Frequent change, then discard– Dynamic specification

D t l th d i h– Does not replace the design phase• Advantages

– Requirements better specified and validatedq p– Early feasibility analysis– Customer involved in prototyping phase

• DisadvantageDisadvantage– Higher development costs– Danger that prototype may become the product


SpiralSpiral

Spiral Model – Dr. Barry Boehm, 1983

Progress Through Steps

Cumulative Cost

Determine Objectives, Alternatives, Constraints

Evaluate Alternatives, Identify, Resolve Risks

Risk Analysis

Proto P t t 2

Risk Analysis

Risk Analysis

Prototype 3

Operational Prototype

RA Proto-type 1

Prototype 2 Prototype 3

Concept of Operation Software

Reqmts. Detailed

Reqmts Plan

.

Commitment

PartitionReview

Life Cycle Plan Waterfall

BenchmarksSimulations, Models,

SoftwareProductDesign

DetailedDesign

Unit Test

Code

Requirements Validation

Design Validation and Verification

Integration and Test

Develop-ment Plan

From:B. W. Boehm, “Spiral Model of Software Development” in

Waterfall

Test


Acceptance Test Implemen-

tation

and Verificationand Test Plan

Software Development ,in Tutorial Software Project Management edited by R. H. Thayer and M. Dorfman, IEEE Press, 1988.

D l V if N tPlan Next Phases Develop, Verify, Next Level Product

Forsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing Project Management (3rd ed.). Hoboken, New Jersey: John Wiley & Sons, p.245

Spiral

• Description– Risk investigation+prototyping phases spiralRisk investigation+prototyping phases spiral around a center point, and then transition towaterfall

– However risk management does not stop after transition

– Radial dimension: cumulative cost to date

– Angular dimension: progress through spiral

– Terminate if all risks cannot be resolved


Spiral Model – Dr. Barry Boehm, 1983

Progress Through Steps

Cumulative Cost

Determine Objectives, Alternatives, Constraints

Evaluate Alternatives, Identify, Resolve Risks

Risk Analysis

Proto P t t 2

Risk Analysis

Risk Analysis

Prototype 3

Operational PrototypeWhat do you think are the

RA Proto-type 1

Prototype 2 Prototype 3

Concept of Operation Software

Reqmts. Detailed

Reqmts Plan

.

Commitment

PartitionReview

Life Cycle Plan Waterfall

BenchmarksSimulations, Models,

yadvantages and disadvantages!

SoftwareProductDesign

DetailedDesign

Unit Test

Code

Requirements Validation

Design Validation and Verification


Develop-ment Plan

From:B. W. Boehm, “Spiral Model of Software Development” in

Waterfall

Test


Acceptance Test Implemen-

tation

and Verificationand Test Plan

Software Development ,in Tutorial Software Project Management edited by R. H. Thayer and M. Dorfman, IEEE Press, 1988.

D l V if N tPlan Next Phases Develop, Verify, Next Level Product


Spiral• Advantages

– Combines strengths of prototyping d f lland waterfall

– Addresses known risks first: - Requirements understanding- Technical feasibility- System operations

- Continuous customer involvement- Progressively definition of customer requirements- Prototype acts as a dynamic specification

• DisadvantagesDisadvantages– System architecture and the issues of integration, verification, and validation

are not represented– Management overhead

• Applicability– Used only on large projects—high management overhead– E.g. US Army Future Combat Systems—for development and upgrades


Adding System IntegrationAdding System Integration, Verification & Validation

• How do verification and validation differ?

Validation vs VerificationValidation vs Verification

• Integration– The successive combining and testing of the system components (e.g. hardware, software, operator tasks etc.) to progressively prove the performance and compatibility of all entities of the systemof all entities of the system

• Verificationf f li i h ifi i– Proof of compliance with specifications

• Validation– Proof of user satisfaction

Forsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing Project Management (3rd ed.). Hoboken, New Jersey: John Wiley & Sons, p. 110

Vee Model—System Decomposition

SystemDevelopment

SystemRealization


SystemDevelopment

SystemRealization

SubsystemDevelopmentDevelopment


SystemDevelopment

SystemRealization


LCILowest

Configuration Item Development


SystemDevelopment

SystemRealization


I, V, and V Planning

LCILowest


LCILowest

Configuration Item Realization


SystemDevelopment

SystemRealization

SubsystemDevelopment

SubsystemRealization

Integration, Verification, d V lid ti Pl iDevelopment Realizationand Validation Planning

LCILowest


LCILowest



SystemDevelopment

SystemRealizationIntegration, Verification, and Validation Planning


SubsystemRealizationDevelopment Realization

LCILowest


LCILowest


Vee Model—Integration, Verification, Validation

SystemDevelopment

SystemRealizationIntegration, Verification, and Validation Planning


SubsystemRealization

Integration, Verification, d V lid ti Pl iDevelopment Realizationand Validation Planning

I, V, and V Planning

LCILowest


LCILowest


Integrated Entity and Architecture Development

Entity Vee


Wave Planningg

Design

GatherGatherInformation

lActivity

Implementation

Activity

Flow PathFlow Path

Dombkins, D. H. (2007). Complex Project Management: Seminal Essays. North Charleston, South Carolina: BookSurge Publishing, p. 409



TerminologyTerminology

Diff i diff i• Different sources assign different meanings to– SpiralE l i– Evolutionary

– IncrementalIterative– Iterative

• E.g. In US DoD 5000.2—Evolutionary has two manifestationsmanifestations– Spiral—end‐state requirements are not known at initiation– Incremental—end‐state requirements known at initiation– Incremental end‐state requirements known at initiation

Multiple Delivery IncrementalMultiple Delivery—IncrementalRelease 1

R

Preliminary DesignPreliminary Design Detailed DesignDetailed Design DevelopmentDevelopment DeploymentDeployment

Release 1

Requireme


Release 2

ents


Release 3

Time


Incremental Delivery

• Description– User requirements established up‐front

– Each release increases or enhances functionality incrementally

– Highest priority user requirements in earlier releases or increments

Incremental Delivery

• Description– User requirements established up‐front– Each release increases or enhances functionality incrementallyincrementally

– Highest priority user requirements in earlier releases or increments

• Advantages– Early delivery of initial operating capability

• Disadvantages– May not be possible to fully establish requirements if scope is ambiguous

Multiple Delivery IterativeMultiple Delivery—IterativeRelease 1

RequirementsRequirements Preliminary DesignPreliminary Design Detailed DesignDetailed Design DevelopmentDevelopment DeploymentDeployment

Release 1


Release 2

FeedbackRelease 3


TiTime

Iterative Delivery

• Description– Each build evolves functional capability and refines requirementsrefines requirements

Iterative Delivery

• Description– Each build evolves functional capability and refines requirements

• Ad anta es• Advantages– Early increments act as a prototype to elicit requirements for later incrementsfor later increments

– Constant customer involvement and validation– Good risk management—lower overall riskGood risk management lower overall risk– Used in agile methodologies

• DisadvantagesDisadvantages– May degenerate into build‐and‐fix

Technology Insertion


Technology Readiness LevelsTechnology Readiness Levels

l b d d d1. Basic principles observed and reported

2. Technology concept and/or application formulated

3 Analytical and experimental critical function and/or characteristic proof of3. Analytical and experimental critical function and/or characteristic proof of concept

4. Component and/or breadboard validation in laboratory environmentd/ b db d l d l5. Component and/or breadboard validation in relevant environment

6. System/subsystem model or prototype demonstration in a relevant environment7. System prototype demonstration in an operational environment8. Actual system completed and 'flight qualified' through test and demonstration9. Actual system 'flight proven' through successful mission operations

Technology Readiness LevelsTechnology Readiness Levels

Laboratory Observation

Technology Concept

1

2h Technology Concept

Proof of Concept

Breadboard in Laboratory

2

3

Hig

h

Breadboard in Relevant Environment

Breadboard in Laboratory4

5

Med

ium

Prototype in Operational Environment

Prototype in Relevant Environment6

7

M

First Article Demonstration

Commodity Usage

8

9

Low

Time

Bringing It TogetherBringing It Together

TimeNow

The solution architecture consists of four increments A, B, C and C

A

, ,

Increment A starts first

B

C

D Later, B and D start at the same time, while C is further delayed

Time and Maturity

Solution InitiationForsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing Project Management (3rd ed.). Hoboken, New Jersey: John Wiley & Sons, p. 117

TimeNow

Increments A, B, and C are straight‐forward linear development requiring no experimentation or version iterations Increments A is completed providing

AProduct Breakdown

Linear

experimentation or version iterations p p gInitial Operating Capability (IOC)

A

LinearBA

Product Breakdown Structure

Linear development continues on increments B and C which will be combined later

LinearCA (BC) D

combined later

The requirements for subsystem D are ill‐

D1 D2B C

Spiral

q ydefined and an evolutionary approach is adopted. Tow iterations have been pursued at this point

Time and Maturity

Increment A completed , providing initial operating capabilityForsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing Project Management (3rd ed.). Hoboken, New Jersey: John Wiley & Sons, p. 117

TimeNow

A AProduct Breakdown

LinearIncrements A is combined with BC to expand functionality of the initial

B BCA


Linear

A(BC)

Increments B & C are integrated to

to expand functionality of the initial system

CA (BC) D

Linear

Evolutionary development continues

Increments B & C are integrated to form subsystem BC

D1 D2 D3 D4B C

Spiral

Evolutionary development continues to produce successive versions D1through D3

Time and Maturity

Solution subsystems A, B and C completeForsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing Project Management (3rd ed.). Hoboken, New Jersey: John Wiley & Sons, p. 118

TimeNow

A AProduct Breakdown

Linear

B BC

A(BC)A


Linear

CA(BC)D4

A (BC) D

Linear

Increments A, BC, & D are integrated into the ultimate solution ABCD4

D1 D2 D3 D4B C

Spiral4

Time and Maturity

All increments are integrated to form the enhanced systemForsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing Project Management (3rd ed.). Hoboken, New Jersey: John Wiley & Sons, p. 118

US DoD 2167A Defense System Software Developmentdated 4 June 1985

What is wrong with this delivery mechanism?

A General Approach

DevelopmentModels

Waterfall Spiral Vee

D l

DevelopmentMethod 1 Incremental

(Modular)Unified(Lump)

Delivery

Linear(Single Pass)

Evolutionary(Experimental)

Development Method 2 Linear

(Single Pass)Evolutionary(Experimental)

MultipleSingle MultipleSingleSingle Multiple SingleDeliveryMethod


A General ApproachStep 1: Map the Project Objective Uncertainty and Process Uncertainty Using the WHOW Matrix


A General ApproachA General ApproachStep 2: Use the project type to define the broad project life‐cycle approach

A General ApproachA General Approach

DevelopmentModels


Step 3: Translate the project life cycle approach into one or a mix of development approaches

A General ApproachStep 3: Translate the project life cycle approach into one or a mix of development & delivery approaches

DevelopmentModels


D l

DevelopmentMethod 1 ModularLump

Delivery

Linear SpiralDevelopment Method 2 Linear Spiral

MultipleSingle MultipleSingleSingle Multiple SingleDeliveryMethod


What Project Development and Delivery Approach?• Building a mouse trap powered vehicle • A new tunnel bypass under a capital city which is subject to a public‐private partnership arrangement• The development of the new bullet train network running the length of Vietnam• Development of a new drug therapy for a particularly aggressive form of cancer• An enterprise‐wide software replacement project for an existing payroll management system. To save

money, a ‘big bang’ approach is proposed—in which the old system will be switched off and the new system switched on simultaneously. There will be no parallel running. S b i l f j h l h i ill d fi d b h i b i l• Substantial software project where not only are the requirements ill‐defined, but there is substantial disagreement amongst key stakeholders;

• An expansive change management program encompassing a global corporation.• Next version of Microsoft Windows operating system (code named Quebec)• Next version of Microsoft Windows operating system (code named Quebec).• Development of a global humanitarian program• A new national transport ticket system similar to Brisbane’s ‘Go Card’ but it will operate throughout

AustraliaAustralia• Designing and producing a new stealth patrol boat with a lead time for the first mature variant of 10

years:– A small number of patrol boats with minimum combat capability must be deployed as soon as possible,

preferably within seven years.– The requirements for the mature variant are only partially defined– The design is to take advantage of new or foreshadowed technological advances (it has not been uncommon in

the recent past that some technologies in the first production patrol boat were already obsolescent if notthe recent past that some technologies in the first production patrol boat were already obsolescent if not obsolete)

– Because of the capital cost, most countries will operate the stealth patrol boat for 20 to 30 years, during which its capability must be progressively refreshed

For Week 3For Week 3

• Complete the ‘Getting to Know the BEN610 Class’• Complete the Getting to Know the BEN610 Class Survey no later than Thursday

Pl d PMB K Ch• Please read PMBoK Chapters:– 1: Introduction

– 5: Project Scope Management

• Read Burke Chaps 8 & 9p• Begin thinking about the first assessment item

– Tutors will discuss this during the Week 2 Tutorial– Tutors will discuss this during the Week 2 Tutorial

• Put ‘Simulation Saturday’ into your calendar

Backup Slides

Supplementary Material OnlySupplementary Material Only

Development Sequence 1

SystemRequirements, Concept, Architecture, Design‐to, Build‐to, and Verification and Validation Plans

SystemVerification and Validation

Solution/System

Architecture

Solution/System

Requirements

Solution/SystemDesign‐toArtifacts

Solution/SystemConcept

SubsystemVerification and

Preparation for System Integration and

Subsystem Requirements, Concept, Architecture, Design‐to, Build‐to, and

Verification and Validation Integration and Verification

Verification and Validation Plans

LCIVerification and

Preparation for Subsystem Integration

LCI Requirements, Concept, Architecture, Design‐to, Build‐to, and Verification and Validation Plans

System RealizationForsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing Project Management (3rd ed.). Hoboken, New Jersey: John Wiley & Sons, p. 343

Development Sequence 2 (Subsystem Level)



Solution/System

Architecture

Solution/System

Requirements






Verification and ValidationSubsystem

R i t

SubsystemRequirements Subsystem

C t

SubsystemConcept

SubsystemArchitecture


SubsystemDesign‐to

SubsystemDesign‐toArtifacts Integration and

VerificationVerification and Validation

PlansRequirementsRequirements ConceptConcept Architecture g

ArtifactsArtifacts

LCIVerification and


LCI Requirements, Concept, Architecture, Design‐to, Build‐to, and Verification and Validation Plans


Development Sequence 3 (lowest CI entity level)



Solution/System

Architecture

Solution/System

Requirements



Desig





R i t


C t

SubsystemConcept




SubsystemDesign‐toArtifacts

gn‐to Gat

Integration and Verification


RequirementsRequirements ConceptConcept Architecture gArtifactsArtifactse Sequence

LCIVerification and


LCI Requirements, Concept, Architecture, Design‐to, Build‐to, and Verification and Validation PlansLCI

Architecture

LCIDesign‐toArtifacts

LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept


Development Sequence 4Development Sequence 4



Solution/System

Architecture

Solution/System

Requirements



Desig





R i t


C t

SubsystemConcept





gn‐to Gat



RequirementsRequirements ConceptConcept Architecture gArtifactsArtifactse Sequen

Design LCI andDesign LCI andB ild t d

ce

LCIVerification and



Architecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

Design LCI andBuild‐to and Code‐to Artifacts



Build‐to and Code‐to Artifacts





Solution/System

Architecture

Design Solution/System andBuild‐to and Code‐to A tif t

Solution/System

Requirements



Artifacts

Desig

Bu





R i t


C t

SubsystemConcept





Design Subsystem

andBuild‐to and

Design Subsystem

andBuild‐to and

gn‐to Gat

uild‐to Gat



RequirementsRequirements ConceptConcept Architecture gArtifactsArtifacts Build‐to and

Code‐to Artifacts

Code‐to Artifacts

e Sequen

te SequenDesign LCI andDesign LCI andB ild t d

ce

nceLCI

Verification and Preparation for Subsystem

Integration


Architecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept









Solution/System

Architecture


Solution/System

Requirements



Artifacts

Desig

Bu





R i t


C t

SubsystemConcept





Design Subsystem

andBuild‐to and

Design Subsystem

andBuild‐to and

gn‐to Gat

uild‐to Gat




Code‐to Artifacts

Code‐to Artifacts

e Sequen


ce

nceLCI


Integration


Architecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept





LCIInterface Build

LCIInterface Build

LCIInterface Build

LCIBuild

LCIIntegration

LCIIntegration

LCIIntegration

LCIIntegration

LCI Verification

LCI Verification

LCI Verification

LCI Verification

LCI Validation

LCI Validation

LCI Validation

LCI Validation





Solution/System

Architecture


Solution/System

Requirements



Artifacts

Desig

Bu





R i t


C t

SubsystemConcept





Design Subsystem

andBuild‐to and

Design Subsystem

andBuild‐to and

SubsystemInterface Build

SubsystemInterface Build Subsystem

I t ti

SubsystemIntegration Subsystem

V ifi ti

Subsystem Verification Subsystem

V lid ti

Subsystem Validation

gn‐to Gat

uild‐to Gat




Code‐to Artifacts

Code‐to Artifacts

IntegrationIntegration VerificationVerification ValidationValidatione Sequen


ce

nceLCI


Integration


Architecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept





LCIInterface Build

LCIInterface Build

LCIInterface Build

LCIBuild

LCIIntegration

LCIIntegration

LCIIntegration

LCIIntegration

LCI Verification

LCI Verification

LCI Verification

LCI Verification

LCI Validation

LCI Validation

LCI Validation

LCI Validation





Solution/System

Architecture


Solution/System

Integration

Solution/System

Verification

Solution/System

Validation

Solution/System

Requirements

Solution/SystemInterface Build



Artifacts

Desig

Bu





R i t


C t

SubsystemConcept





Design Subsystem

andBuild‐to and

Design Subsystem

andBuild‐to and

SubsystemInterface Build

SubsystemInterface Build Subsystem

I t ti

SubsystemIntegration Subsystem

V ifi ti

Subsystem Verification Subsystem

V lid ti

Subsystem Validation

gn‐to Gat

uild‐to Gat




Code‐to Artifacts

Code‐to Artifacts

IntegrationIntegration VerificationVerification ValidationValidatione Sequen


ce

nceLCI


Integration


Architecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept

LCIArchitecture


LCIRequirements

LCIConcept





LCIInterface Build

LCIInterface Build

LCIInterface Build

LCIBuild

LCIIntegration

LCIIntegration

LCIIntegration

LCIIntegration

LCI Verification

LCI Verification

LCI Verification

LCI Verification

LCI Validation

LCI Validation

LCI Validation

LCI Validation


Managing Entity DevelopmentThe Entity Vee provides the sequence for entity development and realization. Decision gates are appropriate at every

Custom

er

Confirmation

User and Stakeholder Requirements

Custom

erCo

nfirmation

Validation

Customer Confirmation

UARphase of this sequence.Gates illustrated are:URR – User Requirements ReviewERR – Entity Requirements ReviewECR – Entity Concept Review

Custom

er

Confirmation

Custom

er

Confirmation

Validation PlanningEntity Requirementsnity and

Risk

stigation

URR

Validation

Investigation

y pPDR – Preliminary Design Review

(May include concept review)CDR – Critical Design ReviewPCA – Physical Configuration AuditTRR – Test Requirements Review

stom

er

nfirmation

tomer

nfirmation

FCAConcept &

gEntity Requirements

d Risk

on

ERROpp

ortun

Inves

Preparation

EAR Ano

maly TRR – Test Requirements Review

FCA – Functional Configuration AuditEAR – Entity Acceptance ReviewUAR – User Acceptance Review.

Cus

Con

Cust

Con Verification – Test,

Demonstration, Analysis

n

TRR

Verification Planning

Concept & Architecture Selection

and Design‐to Specification

k

PDRECR

Opp

ortunity an

Investigatio

Build‐to and

Code‐to Artifacts

Verification PlanningVerification ‐Inspection

PCA

omaly Investigation

portun

ity an

d Risk

Investigation

Buy, Build, ni

ty and

Risk

tigation

CDR

nvestigation

AnoOpp

Entity Realization

,Code

Opp

ortun

Invest

Ano

maly I


Vee Solution Model – Unified/Evolutionary Development –Single or Multiple Version Deliveries

Development evolution through three versions with and without successive version deployment.

PossibleVersion

Deployment

PossibleVersion

Deployment

Version Acceptanceand Deployment

VerificationPDR VerificationUpdatePDR

UpdatePDR Verification

Code, Fab,And Assemble


Vee Solution Model – Incremental/Linear Development –Single or Multiple Increment Deliveries

System PDR

SystemAccept& Deliver

SystemTRR

Each delivery adds preplanned functionality which is typical of highway

d il d t

Increment 3PDR

Increment 2PDR

Incre 1+2Verif.

& PossibleDelivery

Integrate

Incre 1Verif.

& Possible Delivery

Incre 1+2TRR

and railroad system developments.

PDR PDR

Increment 1 PDR

Integrate 1+2+3 Incre 1

TRR

Code, Fab, Assemble Units


Vee Solution Model – Incremental/Linear and Evolutionary Development – Single or Multiple Deliveries

System PDR

SystemAccept& Deliver

SystemTRR

Increment 3PDR

Increment 2PDR

Incre 1+2Verif.

& PossibleDelivery

Incre 1Verif.

& Possible Delivery

Incre 1+2TRR

Integrate

Increment 1 PDR

PDR PDR Incre 1TRR

g1+2+3

Two linear increments and one evolutionary i t b iincrement being integrated for a single delivery.

Version 1 Version 2 Version 3

Code, Fab, AssembleIncrement 3

Evolutionary Development


AgileAgile

Hass, K. B. (2009). Managing Complex Projects. Vienna, Virginia: Management Concepts, p.101

AgileAgile

So What’s New?

Hass, K. B. (2009). Managing Complex Projects. Vienna, Virginia: Management Concepts, p.101

Manifesto for Agile Software DevelopmentManifesto for Agile Software DevelopmentEstablished February 2001 by 17 founding members

We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentationWorking software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a planp g g g p

That is, while there is value in the items on the right, we value the

items on the left more

Lapham, M. A., Williams, R., Hammons, C., Burton, D., & Schenker, A. (2010). Considerations for using agile in DoD acquisition: Carnegie Mellon: Software Engineering Institute, p.3

Agile A DefinitionAgile—A Definition

An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self organizing teams within an effective governancemanner by self‐organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely manner which q y f ff ymeets the changing needs of its stakeholders

… early delivery of business value. That involves early and regular delivery or working software, a focus on team communications, and close interaction with the users

Lapham, M. A., Williams, R., Hammons, C., Burton, D., & Schenker, A. (2010). Considerations for using agile in DoD acquisition: Carnegie Mellon: Software Engineering Institute, p.5

Agile Manifesto Principles• Our highest priority is to satisfy the customer through early and continuous delivery of

valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to and within a• The most efficient and effective method of conveying information to and within a development team is face‐to‐face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity—the art of maximizing the amount of work not done—is essential.

• The best architectures, requirements, and designs emerge from self‐organizing teams.

• At regular intervals the team reflects on how to become more effective then tunes andAt regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.6

Agile Methodologies Example—Scrum

Schwaber, K. (2004). Agile Project Management with Scrum. Redmond, Washington: Microsoft Press.

Project Management Declaration of InterdependenceProject Management Declaration of Interdependence

i i b ki i fl f l f• We increase return on investment by making continuous flow of value our focus.

• We deliver reliable results by engaging customers in frequent interactions and shared ownership.

• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.

• We unleash creativity and innovation by recognizing that individuals are the y y g gultimate source of value and creating an environment where they can make a difference.

• We boost performance through group accountability for results and shared p g g p yresponsibility for team effectiveness.

• We improve effectiveness and reliability through situationally specific strategies, processes, and practices.processes, and practices.

Krebs, J. (2008). Agile Portfolio Management. Redmond, Washington: Microsoft Press.

BEN610-T1-S1-2008

Documents

subsystem

relevant environment

project management

project management

solution system

lciverificationand

development

designto artifacts