Project Management CSC 310 Spring 2017 Howard Rosenthal · Flexibility In Project Management...
Transcript of Project Management CSC 310 Spring 2017 Howard Rosenthal · Flexibility In Project Management...
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