Project Management CSC 310 Spring 2017 Howard...

40
Project Management CSC 310 Spring 2017 Howard Rosenthal

Transcript of Project Management CSC 310 Spring 2017 Howard...

ProjectManagementCSC310

Spring2017HowardRosenthal

No?ce� Thiscourseisbasedonandincludesmaterialfromthetext:EffectiveProjectManagement-Traditional,Agile,Extreme7THEditionAuthors:RobertK.WysockiPublisher:WileyISBN:978-1-118-72916-8,Copyright2014

� Thecourseincludesandinterspersessomematerials,mostoftendiagrams,providedbyMr.Wysocki’sPowerPointslides,atthewebsite:www.wiley.com/go/epm7e

�  ItalsoutilizesgeneralinformationandfiguresfromthePMBOK:AGuidetotheProjectManagementBodyofKnowledge(PMBOK5THEdition)Publisher:ProjectManagementInstituteISBN:978-1-935589-67-9,Copyright2013

2

LessonGoals

�  Understandwhatprojectmanagementis�  Characteristicsofgoodprojectmanagement

�  Whatarescopeandscopecreep�  Whatarerequirements�  Whataretheimmutableprocessesinanyproject�  Whatarethedifferentprojectmanagementmodels

�  Traditional Project Management (TPM) �  Agile Project Management (APM) �  Extreme Project Management (xPM) �  Emertxe Project Management (MPx)

�  How do you pick the best lifecycle models within a project management framework �  Linear �  Incremental �  Iterative �  Adaptive �  Extreme

�  Note: The terms incremental and iterative are used interchangeably in the PMBOK, and Adaptive and Agile are often used synonymously

3

WhatDoesProjectManagementDo?�  Projectmanagementisanorganizedcommon-senseapproachthat

utilizestheappropriateclientinvolvementinordertodeliverclientrequirementsthatmeetorexceedexpectedincrementalbusinessvalue

�  Goodprojectmanagersare�  Flexible�  Proactive�  Understandtheircustomers�  Understandtheirorganizationsandtheorganizationalgoalsand

priorities�  Understandwhattheirprojectsareaboutandatleastthebasicsofthe

underlyingproductsortechnologiesbeingcreated�  Manageallthestakeholders�  Aregoodteambuilderswhocanlisten�  Arewillingtomakedecisionsafterlistening

�  Thereisadifferencebetweenbeingaprojectmanagerandbeingamanager,althoughthereissomeoverlapinskills,especiallyinhumanresourcesmanagement

4

ABossvs.ALeader

5

WhatDoesProjectManagementAnswer?(1)�  Projectmanagementisasetoftools,templates,andprocessesdesignedtoanswersixquestions

1.  Whatbusinesssituationisbeingaddressedbythisproject?�  Itcanbeaproblemthatneedssolvingoranopportunitythatneedstobe

exploited2.  Whatdoesthebusinessneedtodo?

�  Needstobedocumentedtotheextentpossible3.  Whatwillyoudo?

�  DefineyourgoalandobjectivesintheProjectOverviewStatement(POS)

4.  Howwillyoudoit?�  Therearemanyoptionsincluding:

�  In-housevs.out-sourcing�  Newsolutionversusadaptionofexistingtechnologies�  Newprocessvs.newtools

5.  Howwillyouknowyoudidit?�  Needobjectivemeasurements

6

WhatDoesProjectManagementAnswer?(2)6.  Howwelldidyoudo?

�  Howwelldidyourdeliverablesmeetthestatedsuccesscriteria?�  Theprojectwassoldtomanagementbasedontheincremental

businessvaluethatwouldbereturnedtotheorganizationiftheprojectweresuccessful.

�  Didtheprojectdeliverthoseresultsandtowhatextent?�  Howwelldidtheprojectteamperform?

�  Theprojectteamwasfollowingsomeprojectmanagementlifecycle(PMLC)modelandthereneedstobesomeassessmentofhowwelltheyfollowedthatmodel.

�  Howwelldidtheprojectmanagementapproachworkforthisproject?

�  Whatlessonswerelearnedthatcanbeappliedtofutureprojects�  Thisprocessisrequiredforeveryprogramandisansweredthroughthepost-implementationaudit.

7

FlexibilityInProjectManagement

�  Wysockiemphasizesflexibilityasanimportantprojectmanagementskill�  Hesaysthatifitdoesn’tmakesense,don’tdoit

�  Youdohaveareasofflexibility�  Youwanttotailoryourprojectbasedonitscharacteristics�  Youcanselectthecorrectlifecyclemodel(s)�  Youcantailortheprocessestomeettheproject’sneeds�  Youcandeterminethedepthandformalityofsomestepsinthe

process�  Aprojectmanagercannot

�  Circumventorignorethelaw,evenifitdoesn’tmakesense�  Ignoregovernmentregulations,inparticularongovernment

contracts�  Ignorecompanypoliciesandprocesses�  Ignoreanyelementofyourcontract

8

FlexibilityandChangeControl

�  Whileitiswouldbeniceifeveryprojecthadperfectlydefinedrequirementsandperfectresourceavailabilitythisisnotalwaysthecase�  Newrequirementsareoftendiscoveredduringthedesignprocess�  Thereareconflictsinresources

�  Youdon’talwaysgettheA-Teamateveryposition�  Youneedtopickyourresourcebattles�  Sometimesalesserexperiencedplayercandotheneededworkatalowercost

�  Newrequirementsevolve�  Marketconditionschange�  Organizationalchangescanreviseorganizationalpriorities

�  Asponsorintheorganizationcandisappear�  Opportunitiesmayarisethatrequireanimmediateresponse

�  Theprojectmanagerneedstohaveaplanformanagingchange�  Theirontrianglesaysthatasonesideofthetriangle(ordiamond,

etc.)changes,youneedtomakechangesoradjustmentstotheothersides

�  Eachsignificantchangesrequiresanalysisandimpactstatements

9

ThereAreFiveMajorProcessesAssociatedWithEveryProject

10

�  Allprojectsbeginafteraninitialstatementofworkwithabusinesscaseispreparedbythesponsor

�  Theseprocessesmaybeexecutedsequentiallyorinsomeiterativepatternbasedonthecharacteristicsoftheproject

PMP Wysocki Description

Initiate Scope CharterDevelopedStakeholdersIdentified

Plan Plan DevelopProjectPlansDevelopSchedulesandBudgets

Execute Launch ManageTheWorkPerformQualityAssuranceConductProcurementsManageStakeholders

MonitorandControl MonitorandControl WorkChangeScheduleCostsQualityProcurementsStakeholderEngagement

Close Close CloseProjectorProjectPhaseCloseProcurements

TheCostandStaffingForaProjectIsNotLinear�  Thehigheststaffinglevelsarefoundwhenactuallycarryingoutthework

�  Matrixorganizationsworkwellinstaffingprojectsifthecompanycanphaseprograms

11

39©2013 Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition

2

2 - ORGANIZATIONAL INFLUENCES AND PROJECT LIFE CYCLE

Starting the project,

Organizing and preparing,

Carrying out the project work, and

Closing the project.

This generic life cycle structure is often referred to when communicating with upper management or other entities less familiar with the details of the project. It should not be confused with the Project Management Process Groups, because the processes in a Process Group consist of activities that may be performed and recur within each phase of a project as well as for the project as a whole. The project life cycle is independent from the life cycle of the product produced by or modified by the project. However, the project should take the current life-cycle phase of the product into consideration. This high-level view can provide a common frame of reference for comparing projects—even if they are dissimilar in nature.

Time

Cos

t an

d S

taffi

ng L

evel

ProjectManagementOutputs

ProjectCharter

Startingthe

project

Organizing andpreparing

Closingthe

project

Carrying out the work

ProjectManagement Plan

AcceptedDeliverables

ArchivedProject

Documents

Figure 2-8. Typical Cost and Staffing Levels Across a Generic Project Life Cycle Structure

Licensed To: Howard Rosenthal PMI MemberID: 2552551This copy is a PMI Member benefit, not for distribution, sale, or reproduction.

PMBOKFig.2-8

CostOfChangeInATradi?onalProgram�  Intraditionalprogrammanagementlatechangeshaveagreaterimpactoncosts

�  Giventherealizationthatthereisalmostalwayschangeintheproject,differentmodelshavebeendevelopedtocontroltheimpactofthosechangesthatwewilldescribeinsubsequentslides

12

40 ©2013 Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition

2 - ORGANIZATIONAL INFLUENCES AND PROJECT LIFE CYCLE

The generic life cycle structure generally displays the following characteristics:

Cost and staffing levels are low at the start, peak as the work is carried out, and drop rapidly as the project draws to a close. Figure 2-8 illustrates this typical pattern.

The typical cost and staffing curve above may not apply to all projects. A project may require significant expenditures to secure needed resources early in its life cycle, for instance, or be fully staffed from a point very early in its life cycle.

Risk and uncertainty (as illustrated in Figure 2-9) are greatest at the start of the project. These factors decrease over the life of the project as decisions are reached and as deliverables are accepted.

The ability to influence the final characteristics of the project’s product, without significantly impacting cost, is highest at the start of the project and decreases as the project progresses towards completion. Figure 2-9 illustrates the idea that the cost of making changes and correcting errors typically increases substantially as the project approaches completion.

While these characteristics remain present to some extent in almost all project life cycles, they are not always present to the same degree. Adaptive life cycles, in particular, are developed with the intent of keeping stakeholder influences higher and the costs of changes lower throughout the life cycle than in predictive life cycles.

Risk and uncertainty

Cost of changes

Project TimeLow

High

Deg

ree

Figure 2-9. Impact of Variable Based on Project Time

Licensed To: Howard Rosenthal PMI MemberID: 2552551This copy is a PMI Member benefit, not for distribution, sale, or reproduction.

PMBOKFig.2-9

ScopeCreep

� Theauthormakesthepointthateventhemoststableofprojectsislikelytohavesomechangesinthescope

� ThePMmusthavemechanismsforcopingwithchange�  AChangeManagementPlanandandassociatedprocessesareessentialtothistask

�  Eachchangeislikelytohaveanimpactoncostandschedule–usually,butnotalwayslengtheningtheprogramorincreasingthecost

�  Scopecanbeimpactedbychangingmarketfactorsorthecompetition

13

OtherTypesOf“Creeps”�  FeatureCreep

�  Anemployeeormanageragreestoacustomerrequestwithoutgoingthroughachangeprocess

�  Featurecreepcanoccurattherequirements,designordevelopmentphaseofaproject,asitmaychangethescopeortheplanning

�  Usuallydonetokeepthecustomerhappy�  Howeverthecustomerismuchlesshappyafterthecostgoesupand/orthescheduleslips

�  HopeCreep�  Usuallyoccurswheneitheranemployeeorcontractorfallsbehindschedulebutfailsto

reportthefact�  Hopeisthattheproblemwillbesolvedandtimecanbemadeup�  Sometimesemployeespushthemselvestoverylongworkdaystotrytodisguiseschedule

slips�  Employeesandmanagersoftenfeelthattheircareerscanberuinediftheyadmittoslips�  Projectsshouldbescheduledbasedonahistoricalrecord,ratherthantheideathat

everythingwillproceedperfectly�  EffortCreep

�  Workprogressisnotequaltoeffortputin�  Youputinafulldayofworkbutareproducingonlythreelinesofcodeinsteadoffivelinesofcode

eachday�  Youwillhavealargeschedulevarianceeventhoughyouareonplanwithrespecttocost�  Needtoisolatetheproblemand/orbringonahigherlevelofexpertise

14

WhatAreRequirements?(1)

�  AccordingtotheInternationalInstituteofBusinessAnalysis(IIBA)arequirementis:�  Aconditionorcapabilityneededbyastakeholdertosolveaproblem

orachieveanobjective.�  Aconditionorcapabilitythatmustbemetorpossessedbyasolution

orsolutioncomponenttosatisfyacontract,standard,specification,orotherformallyimposeddocuments.

�  Adocumentedrepresentationofaconditionorcapabilityasintheabovetwobullets.

�  Thisdefinitioncanleadtothousandsofrequirementsbeinggeneratedearlyintheproject�  Notwellconnectedtobusinessvalues�  Theserequirementsareusuallynotgathereduntilafterproject

initiationanditeratedonastheprojectprogresses�  TheIIBAdefinitionisthemostusualdefinitionofrequirements,and

leadstorequirementsspecificationsatmultiplelevelsofdetail�  Atsomepointtherequirementsspecifiesdesignanddesignfeature�  Lowerlevelspecificationsbecomerequirementsandaretracedfor

completionasapartofthecontract

15

WhatAreRequirements?(2)�  Theauthorprovidesanalternatedefinition

�  Arequirementisadesiredend-statewhosesuccessfulintegrationintothesolutionmeetsoneormoreneedsanddeliversspecific,measurable,andincrementalbusinessvaluetotheorganization.

�  Furthermorethesetofhigh-levelrequirementsformsanecessaryandsufficientsetfortheattainmentofincrementalbusinessvalue

�  Itisveryhardtogetthegovernmenttoagreetothistypeofanapproachonanythingbutapureresearchproject�  GovernmentmightconsiderthisasaFunctionalDescriptionDocument

�  Leadstofarfewer(under20)highlevelrequirements�  Requirementsareseparatedfromtheimplementation�  Requirements(andthereforeprojectsuccess)connectdirectlytocustomer

satisfactionratherthantospecificationsthatinsomecasesareirrelevanttoprojectsuccess

�  Especiallyimportantwhenthesolutionisnotknownfromtheoutset�  CanbeusedintheStatementofWorkthatkicksoffaprojectsandwouldbe

includedintheProjectCharter�  Theauthorusesanalternatesetofdefinitionstodecomposerequirements

�  Allofthestakeholderscanbeinvolvedintheselowerleveldefinitions�  Asanexample,end-userswillwanttobeinvolvedintheuserinterfacesdefinedatthe

featurelevel

16

RequirementsBreakdownStructureIntoLowerLevelEn??es

17

Project

Requirement1

Function1

Sub-function1

Process1

Activity1

Feature1

Feature2

FeatureT

Activity2 ActivityS

Process2 ProcessR

Sub-function2

Sub-functionP

Function2 FunctionM

Requirement2 RequirementNOOO

OOO

OOO

OOO

OOO

TheLowerLevelsWillS?llHaveSpecifica?ons�  Eachfunctionwillhaveinputs,processingandoutputs

�  Thisiscalledthehighorderinput-processing-output(HIPO)specification

�  Designisfilledinasthesolutionbecomesbetterknown�  Theuserhasmoreinputintothelowerleveldesignoftheactivitiesandfeaturesespeciallytheuserinterfacesandoutputformats�  ThisisknownasRapidApplicationDesign(RAD)andJointApplicationDevelopment(JAD)�  Incorporationofthecustomer’sneedsatthephaseviaprototyping

andsimulationshasbeenshowntosignificantlyimproveprojectsuccessrates

�  Expertsareemployedspecificallytomanagecustomersandtheirexpectationsduringthisphase

�  MeetsWysocki’sobjectivesthatasuccessfulprojectcreatesbusinessvalueandgeneratescustomersatisfaction

�  Stillneedtoguardagainstscopecreep

18

ProjectManagementLifeCycles�  AProjectManagementLifeCycleisaseriesofstepsthatincludes:

�  Scoping/Initiating�  Planning�  Launching/Executing�  MonitoringandControlling�  Closing

�  Theorderofthestepsandthenumberofiterationsdependsonthelifecyclethatischosen

�  Therearefivedifferentlifecyclemodelsdefinedbytheauthorencompassingfourdifferentprogramtypes�  TraditionProgramManagement(TPM)—LinearandIncrementalModels

�  Usedwhenthegoalandsolutionareclear�  20%ofallprojects�  Example–Installanetworkinabuilding

�  AgileProgramManagement—IterativeandAdaptiveModels�  Usedwhenthegoalisclearbutthesolutionisnot�  70%ofallprojects�  Example–Sendacrewof5toMarsandreturnthemsafelytoEarthbefore2030

�  ExtremeProjectManagement(xPM)—ExtremeModel�  Usedwhenneitherthegoalnorthesolutionisclear�  5%ofallprojects�  Example–Curethecommoncold

�  EmertxeProjectManagement(MPx)—ExtremeModel�  Usedwhenthegoalisnotclearbutthesolutionis–thissometimeshappenswhenbasicresearch,

oreventechnologyisinventedbeforeunderstandinghowitwillbeused�  5%ofallprojects�  Example–Theinternet–wascreatedwithhardlyanyideaofhowitwouldultimatelybeused

19

TheSolu?onSetofProjectLifeCycles

20

GOAL

REQUIREMENTS and SOLUTION

Clear

Not Clear

Not Clear Clear

TPMLinearIncremental

APMIterativeAdaptive

xPMExtreme

MPxExtreme

Tradi?onalProgramManagement

21

LinearProgramManagementLifeCycleModel

IncrementalProgramManagementLifeCycleModel

Characteristics

•  Low complexity •  Low risk

•  Widely used •  Experienced and skilled project Teams

•  Well-understood technology infrastructure

•  Plan-driven projects

AdvantagesAndDisadvantagesofTPMProjects

�  Advantages�  Easytounderstandandimplement.�  Widelyusedandknown(intheory!).�  Reinforcesgoodhabits:define-before-design,design-before-code.�  Identifiesdeliverablesandmilestones.�  Documentdriven,URD,SRD,...etc.withpublisheddocumentationstandards�  Workswellonmatureproductsandweakteams.

�  Disadvantages�  Idealizedview

�  Doesn’tmatchrealitywell�  Doesn’treflectiterativenatureofexploratorydevelopment.�  Unrealistictoexpectaccuraterequirementssoearlyinproject�  Replanningandrebaseliningnotincluded�  Softwareisdeliveredlateinproject,delaysdiscoveryofseriouserrors�  Difficulttointegrateriskmanagement�  Difficultandexpensivetomakechangestodocuments,�  Significantadministrativeoverhead,costlyforsmallteamsandprojects.

22

DifferencesBetweenTheLinearAndIncrementalModels�  Scopechangerequests

�  IntheLinearPMLCmodel,thesearenotexpectedorencouraged.Managementreserveisoftenaddedtotheendoftheschedule.

�  ThestructureoftheIncrementalPMLCmodelencourageschange�  Theinitialreleaseofapartialsolutiongivestheclientandtheend

useranopportunitytoexperimentwiththepartialsolutioninaproductionscenarioandfindareasthatcouldbeimprovedencouragingchangerequests.

�  Asmartprojectmanagerwillbuildschedulecontingenciesintotheplanintheeventofthesescopechangerequests.

�  Incrementalapproach�  Thefullsolutionisdecomposedintopartialsolutionswhose

developmentwouldthenbeplannedinasequentialfashionandreleasedinthatsameorder.

�  Thereleasescheduleneedstobeconsistentwiththedependenciesthatexistbetweeneachpartialsolutionespeciallyifthereisparalleldevelopment

23

ClassicTPMIsTheWaterfallModel

24

TheWaterfallInReality

25

InrealitytherearealmostalwaysunknownsandchangesThisleadstothepotentialtocirclebackatanysteptoapriorstepinthelifecycle

TheV-ShapedModelIsATPMVaria?onOnTheWaterfall

26

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814 www.IJCSI.org

98

development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in requirements gathering.

The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase in order to test the pieces of the software systems ability to work together. However, the low-level design phase lies where the actual software components are designed, and unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

x Advantages

1. Simple and easy to use. 2. Each phase has specific deliverables. 3. Higher chance of success over the waterfall model

due to the early development of test plans during the life cycle.

4. Works well for small projects where requirements are easily understood.

Fig. 5 V-Model [3]

x Disadvantages

1. Very rigid like the waterfall model. 2. Little flexibility and adjusting scope is difficult and

expensive. 3. Software is developed during the implementation phase, so no early prototypes of the software are produced. 4. This Model does not provide a clear path for problems

found during testing phases [7].

Fig. 6 V-Shaped Life Cycle Model[7].

3.4 Spiral Model

The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

x Advantages 1. High amount of risk analysis. 2. Good for large and mission-critical projects. 3. Software is produced early in the software life cycle.

x Disadvantages 1. Can be a costly model to use. 2. Risk analysis requires highly specific expertise. 3. Project’s success is highly dependent on the risk

analysis phase. 4. Doesn’t work well for smaller projects [7].

Requirements System Test Planning

System Testing

High Level Design

Integration Test

Planning

Unit Test Planning

Implementation

Low Level Design

Unit Testing

Integration Testing

Advantages Disadvantages

•  Higher chance of success over the waterfall model due to the early development of test plans during the life cycle

•  Software is developed during the implementation phase, so no early prototypes of the software are produced

•  Each phase has specific deliverables •  Little flexibility and adjusting scope is difficult

•  Simple and easy to use •  Very rigid like the waterfall model

•  Works well for small projects where requirements are easily understood

•  This model does not provide a clear path for problems found during testing phases

AgileProjectManagement

27

IterativeProgramManagementLifeCycleModel

AdaptiveProgramManagementLifeCycleModel

Characteristics

•  A critical problem without a known solution

•  Critical to the organization

•  A previously untapped business opportunity

•  Meaningful client involvement is essential

•  Change-driven APM Projects •  Use small co-located teams

AdvantagesAndDisadvantagesOfTheAgileModel�  Advantages

�  Customersatisfactionbyrapid,continuousdeliveryofusefulsoftware.�  Peopleandinteractionsareemphasizedratherthanprocessandtools.

Customers,developersandtestersconstantlyinteractwitheachother.�  Workingsoftwareisdeliveredfrequently(weeksratherthanmonths).�  Face-to-faceconversationisthebestformofcommunication.�  Close,dailycooperationbetweenbusinesspeopleanddevelopers.�  Continuousattentiontotechnicalexcellenceandgooddesign.�  Regularadaptationtochangingcircumstances.�  Evenlatechangesinrequirementsarewelcomed

�  Disadvantages�  Incaseofsomesoftwaredeliverables,especiallythelargeones,itisdifficultto

assesstheeffortrequiredatthebeginningofthesoftwaredevelopmentlifecycle.

�  Thereislackofemphasisonnecessarydesigninganddocumentation.�  Theprojectcaneasilygettakenofftrackifthecustomerrepresentativeisnot

clearwhatfinaloutcomethattheywant.�  Onlyseniorprogrammersarecapableoftakingthekindofdecisionsrequired

duringthedevelopmentprocess.Henceithasnoplacefornewbieprogrammers,unlesscombinedwithexperiencedresources.

28

DifferencesBetweenTheItera?veandAdap?veModels�  Inbothcaseseachiteration/cycleinfluencesthenextone

� Adaptivecaseislessclearaboutthefunctionalityandsolution

29

Note:RememberthatPMBOKandothersuseiterativeandincrementalinterchangeably

TheSpiralModelIsOnePopularExampleOfAnItera?veAgileProcess–SomeConsiderItATPM

30

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814 www.IJCSI.org

99

x Spiral model sectors 1. Objective setting :Specific objectives for the phase are

identified. 2. Risk assessment and reduction: Risks are assessed and

activities are put in place to reduce the key risks. 3. Development and validation: A development model

for the system is chosen which can be any of the general models.

4. Planning: The project is reviewed and the next phase of the spiral is planned [1].

Fig. 7 Spiral Model of the Software Process[1].

x WinWin Spiral Model The original spiral model [Boehm 88] began each cycle of the spiral by performing the next level of elaboration of the prospective system's objectives, constraints and alternatives. A primary difficulty in applying the spiral model has been the lack of explicit process guidance in determining these objectives, constraints, and alternatives. The Win-Win Spiral Model [Boehm 94] uses the theory W (win-win) approach [Boehm 89b] to converge on a system's next-level objectives, constraints, and alternatives. This Theory W approach involves identifying the system's stakeholders and their win conditions, and using negotiation processes to determine a mutually satisfactory set of objectives, constraints, and alternatives for the stakeholders. In particular, as illustrated in the figure, the nine-step Theory W process translates into the following spiral model extensions: 1. Determine Objectives: Identify the system life-cycle stakeholders and their win conditions and establish initial system boundaries and external interfaces. 2. Determine Constraints: Determine the conditions

under which the system would produce win-lose or lose-lose outcomes for some stakeholders. 3. Identify and Evaluate Alternatives: Solicit suggestions from stakeholders, evaluate them with respect to stakeholders' win conditions, synthesize and negotiate candidate win-win alternatives, analyze, assess, resolve win-lose or lose-lose risks, record commitments and areas to be left flexible in the project's design record and life cycle plans. 4. Cycle through the Spiral: Elaborate the win conditions evaluate and screen alternatives, resolve risks, accumulate appropriate commitments, and develop and execute downstream plans [8]. 3.5 Extreme Programming

An approach to development, based on the development and delivery of very small increments of functionality. It relies on constant code improvement, user involvement in the development team and pair wise programming . It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development.

Fig. 8 The XP Release Cycle

x Extreme Programming Practices Incremental planning: Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development "Tasks". Small Releases: The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.

AdvantagesAndDisadvantagesOfTheSpiralModel

� Advantages� Highamountofriskanalysis.�  Goodforlargeandmission-criticalprojects.�  Softwareisproducedearlyinthesoftwarelifecycle.

� Disadvantages�  Canbeacostlymodeltouse.�  Riskanalysisrequireshighlyspecificexpertise.�  Project’ssuccessishighlydependentontheriskanalysisphase.

� Doesn’tworkwellforsmallerprojects

31

ExtremeProjectManagement

32

ExtremeProgramManagementLifeCycleModel

Characteristics

Extreme (xPM) Project Type Emertxe (MPx) Project Type

•  Research and development •  New technology without a known application

•  Very high risk •  A solution looking for a problem to solve

FeaturesOfExtremeProgramming�  Incrementalplanning

�  RequirementsarerecordedonStoryCardsandtheStoriestobeincludedinareleasearedeterminedbythetimeavailableandtheirrelativepriority.Thedevelopersbreakthesestoriesintodevelopment"Tasks”.

�  SmallReleases�  Theminimalusefulsetoffunctionalitythatprovidesbusinessvalueisdevelopedfirst.Releasesofthesystemarefrequent

andincrementallyaddfunctionalitytothefirstrelease.�  SimpleDesign

�  Enoughdesigniscarriedouttomeetthecurrentrequirementsandnomore.�  Testfirstdevelopment

�  Anautomatedunittestframeworkisusedtowritetestsforanewpieceoffunctionalitybeforefunctionalityitselfisimplemented.

�  Refactoring�  Coderefactoringistheprocessofrestructuringexistingcomputercode—changingthefactoring—withoutchangingits

externalbehavior.�  Refactoringimprovesnonfunctionalattributesofthesoftware.�  Alldevelopersareexpectedtore-factorthecodecontinuouslyassoonaspossiblecodeimprovementsarefound.This

keepsthecodesimpleandmaintainable.�  PairProgramming

�  Developersworkinpairs,checkingeachother’sworkandprovidingsupporttodoagoodjob.�  CollectiveOwnership

�  Thepairsofdevelopersworkonallareasofthesystem,sothatnoislandsofexpertisedevelopandallthedevelopersownallthecode.Anyonecanchangeanything.

�  ContinuousIntegration�  Assoonasworkonataskiscomplete,itisintegratedintothewholesystem.�  Afteranysuchintegration,alltheunittestsinthesystemmustpass.

�  Sustainablepace�  Largeamountsofover-timearenotconsideredacceptableastheneteffectisoftentoreducecodequalityandmedium

termproductivity.�  On-siteCustomer

�  Arepresentativeoftheend-userofthesystem(theCustomer)shouldbeavailablefulltimefortheuseoftheXPteam.�  Inanextremeprogrammingprocess,thecustomerisamemberofthedevelopmentteamandisresponsibleforbringing

systemrequirementstotheteamforimplementation.

33

AdvantagesAndDisadvantagesOfTheExtremeModel(1)�  Advantages

�  Robustness�  Leveragesthepowerofsimplicity.�  Thedesignresemblesajigsawpuzzlewithdevelopersworkingonmanysmallpiecesoriterations

withthecombinationofsuchiterationsgivingtheendproduct.�  Createsworkingsoftwarefasterwithveryfewdefects.

�  Regulartestingatthedevelopmentstageensuresdetectionofallbugs�  Theuseofcustomerapprovedvalidationtestsdeterminethesuccessfulcompletionofacoding

block,ensuringthatonlywhatthecustomerwantsandnothingmoreisimplemented.�  Allowsforcostestimates-basedsoftwarefeaturesinsteadofdeveloperactivity.

�  Customersmakeintelligentdecisionsonwhatneedsinclusionandwhatneedsexclusiondependingonthebudget.Byselectingtheimportantrequirementfirst,thecustomerobtainsmaximumvaluewiththeleastamountspent

�  Resilience�  Requirementskeepchangingeitherbecauseofemergenceofnewbusinessopportunitiesorsimply

becausetheinitialrequirement-gatheringphasewasincomplete�  Extremeprogrammingaccommodatessuchchangedrequirementsthroughgettinguserstories

atthestartofiterations,andthroughfeedbackduringthecourseofiterations.�  CostSavings

�  Trimsunproductiveactivitiestoreducecosts�  Developerstofocusoncodinginsteadofwastingtimeonneedlesspaperworkandmeetings�  Thecostofmakingchangesincreasesasthesoftwareadvancesinitslifecycle,withthecostof

makingchangesafterdeliveryanywherebetween5and100timesmorethanthecostsofmakingachangeatthedesignstage.�  Conventionalprogrammingmethodsmakechangesbasedoncustomerfeedbackattheendof

theproductlifecycle,whereasExtremeProgrammingallowschangesatthedevelopmentstage.�  LesserRisks

�  Conventionalprogrammingdependsalotonindividual‘superstars’orcriticalmembersintheteamwhileextremeprogramming,spreadstheriskandreducesthedependenceonanyonearchitect,projectmanager,orindividualcoder. 34

AdvantagesAndDisadvantagesOfTheExtremeModel(2)

�  Disadvantages�  Programmingishardtodo.

�  YoumayhavedifficultygettingdeveloperstoaccepttheExtremeModel,andittakesalotofdisciplinetofollowthemodelconsistently.

�  Yourcustomersmaynotliketheideaofsomuchinvolvement.�  Managementmayalsofindproblemswithsomanydynamicchangesduringtheprojectlifecycle.

�  XPteamdoesnotbelievetheideaoffixedprice,fixedscope–ratheritisincrementalandisbasedontheconceptofcontinuouschange.�  Otherprocessesaremorelikelytoencouragethecreationofdetailedplanningfromthebeginning.

�  XPiscodecentricratherthandesigncentricdevelopment.�  Thelackofadesignconceptmaynotbeseriousforsmallprograms,butitcanbeproblematicwhen

programsarelargerthanafewthousandlinesofcodeorwhenmanypeopleareassociatedwiththeproject.

�  XPdoesnotmeasureorplanthequalityaspectofdevelopment.�  Managersofbigprojectsbelievethatqualityplanninghelpsproperlytrainedteamsproducehigh-

qualityproducts.�  Itishardtodesigntoday’ssoftwareproducts,whichareverylargeandcomplexby

nature,usingXP’sincrementalapproach.�  Refactoringmaynotbethatimportantallthetimeandcanbeawasteoftimeratherthan

beingproductiveinpositivesense.�  Somedevelopersfallinlovewithperfectingtheirownsoftware

�  SinceXPprogrammingisnotstructured,itmaybedifficulttofindsignificantnumberofdefectsfortestersbyjustmerelookingatthescreen.�  Traditionalprogrammingenablestesterstofinddefectsmoreeasilybecausethetestcasesarewell

documentedandtiedbacktotherequirements.

35

AsTheDegreeOfUncertaintyIncreasesTheSelectedModelEvolvesFromtheLinearToTheExtreme

�  Themodelsformanaturalordering(Linear,Incremental,Iterative,Adaptive,Extreme)bydegreeofsolutionuncertainty

�  Theprocessesthatformrepetitivegroupsrecognizetheeffectofincreasinguncertaintyasyoutraversethenaturalordering�  Thosegroupsmovemoretowardthebeginningofthelifecycleas

uncertaintyincreases�  Completeprojectplanningisreplacedbyjust-in-timeprojectplanningasthedegreeofuncertaintyincreases

�  Riskmanagementbecomesmoresignificantasthedegreeofsolutionuncertaintyincreases

�  Theneedformeaningfulclientinvolvementincreasesasthedegreeofsolutionuncertaintyincreases.

36

Selec?ngTheRightPMLC�  Linear(TPM)

�  Clearly defined solution and requirements �  Not many scope change requests expected �  Routine and repetitive projects �  Uses established templates

�  Incremental (TPM) �  Same as linear but delivers business value early and often �  Some likelihood of scope change requests

�  Iterative (Agile) �  Unstable or or incomplete requirements and functionality �  Learn by doing and by discovery

�  Adaptive (Agile) �  Goal known but solution not known �  Solution highly influenced by expected changes �  New product development and process improvement projects

�  Extreme (xPM and MPx) �  Goal and solution not known �  Through repetitive phases converge on a final scope/goal and solution �  Typically for R&D projects

37

Addi?onalFactorsInSelec?ngTheRightPMLC(1)�  TotalCost

�  Asthetotalcostoftheprojectincreases,sodoesitsbusinessvalueandsodoesitsrisk.�  Lossesarepositivelycorrelatedwiththetotalcost,soyoushouldbeabletojustifyspendingmoreonyour

mitigationeffortsthanyouwouldforaprojectoflessercost.�  Needtoplacemoreemphasisontheriskmanagementplanthaniscalledforinthechosenmodel.

�  AppointaseparateRiskManager�  Duration

�  Alongerdurationprojectbringswithitahigherlikelihoodofchange,staffturnover,andprojectpriorityadjustments.

�  PaymoreattentiontoyourscopechangemanagementplanandtheScopeBank�  TheScopeBankcontainsallofthesuggestedideasforchangethathavenotbeenacteduponandthetotal

labortimeavailablefortheirintegrationintothesolution.�  Putmoreemphasisonthemitigationplansfordealingwithstaffturnover.

�  MarketStability�  Onewaytoprotecttheprojectwouldbetoimplementdeliverablesincrementally.�  Shorterincrementsmightmakesense.�  Aseachincrementisimplemented,revisitthedecisiontocontinueorpostponetheproject.�  Ultimatelydetermineifearlierproductreleasemakessense.

�  Technology�  Technologyischangingatanincreasingrate

�  Difficulttokeepupwithit�  Difficulttoleverageittoyourbestadvantage

�  Ifthenewtechnologywillleverageyouinthemarket,youmightwanttowaitbutmakesureyoucanintegrateitwhenitisavailable.

�  Rapidresponseistoyouradvantage.

38

Addi?onalFactorsInSelec?ngTheRightPMLC(2)�  BusinessClimate

�  Themorevolatilethebusinessclimate,theshorterthetotalprojectdurationshouldbe.

�  ForAPMprojects,thecycletimeboxescouldalsobeshorterthantypicallyplanned.

�  Partialsolutionreleaseswillhaveahigherprioritythantheywouldinbusinessclimatesthataremorestable.

�  Number of Departments Affected �  As the number of departments that affect or are affected by the project

increases, the dynamics of the project change. �  The requirements needs of several departments will have to be taken into account.

�  Could lead to scope creep during the project scoping process as each department will have its list of “must haves” and “wouldn’t it be nice to haves.”

�  Higher incidence of “needs contention,” which means the needs from two or more departments may contradict one another. �  Must resolve the conflicts as part of validating requirements.

�  Organizational Environment �  If your company announces reorganizations and changes in senior-

management responsibilities quite frequently you have a problem. �  The single most-frequent reason for project failures as reported in the past several

Standish Group surveys is lack of executive-level support, including loss of support resulting from company reorganization. �  If you had a sponsor who was very enthusiastic about your project, and a strong and

visible champion for you, who has been replaced, how the new sponsor feels is critical the same?

39

SummaryOfAgilev.Waterfall

40