微软项目管理ppt课件

1、Microsoft Solution Framework (Overview)微软中国开发协作部软件开发首席专家李东方AgendaOverviewTeam ModelRisk ManagementProcess Vision approved milestoneProject plan approved milestoneScope complete milestoneRelease milestoneProject Failure RatesApplication Development ProjectsChallengedSucceeded Failed28%46%26%“When pro

2、jects fail, its rarely technical. Jim Johnson, The Standish GroupRoot Causes of FailureSeparation of goal and functionSeparation of business and technologyLack of common language and processFailure to communicate and act as a teamProcesses that are inflexible to changeAgendaOverviewTeam ModelRisk Ma

3、nagementProcess Vision approved milestoneProject plan approved milestoneScope complete milestoneRelease milestoneLesson 2: Team Model for Application DevelopmentA high-level overview of the team model roles and responsibilities in an application development projectTeam Goals for SuccessSatisfied cus

4、tomersDelivery within project constraintsDelivery to specifications that are based on user requirementsRelease after addressing all known issuesEnhanced user performanceSmooth deployment and ongoing managementTeam of PeersIs a team whose members relate as equalsHas specific roles and responsibilitie

5、s for each memberEmpowers individuals in their rolesHolds members accountable for the success of their rolesDrives consensus-based decision-making Gives all team members a stake in the success of the project ProgramManagementDevelopmentTestingLogisticsManagementUserEducationProductManagementTeam Mod

6、el for Application DevelopmentCommunicationProduct Management RoleActs as customer advocate to the teamActs as team advocate to the customerDrives shared project visionManages customer expectationsDevelops, maintains, and executes the business caseDrives feature identification and prioritizationDeve

7、lops, maintains, and executes the communications planProductManagementProgram Management RoleDrives the overall processManages resource allocationManages the project schedule and reports project statusManages the product scope and specificationFacilitates team communication and negotiationDrives ove

8、rall critical trade-off decisionsProgramManagementDevelopment RoleBuilds and tests features to meet the specification and customer expectationsParticipates in designEstimates time and effort to complete each featureServes the team as a technology consultantDevelopmentTestingTesting RoleDevelops test

9、ing strategy, plans, and scriptsManages the build processConducts tests to accurately determine the status of product developmentParticipates in setting the quality barUser Education RoleActs as team advocate to the end userActs as end-user advocate to the teamParticipates in defining user requireme

10、ntsParticipates in designing featuresDesigns and develops user support systemsDrives the usability processUserEducationLogisticsManagementLogistics Management RoleActs as team advocate to operations Acts as operations advocate to the teamPlans and manages product deploymentParticipates in design, fo

11、cusing on manageability, supportability, and deployabilitySupports the product during beta testingTrains operations and help desk personnel for product releaseTeam and Goal AlignmentTeam roleProduct managementProgram management DevelopmentTestingUser educationLogistics managementGoalSatisfied custom

12、ersDelivery within project constraintsDelivery to product specificationsRelease after addressing all known issuesEnhanced user performanceSmooth product deploymentNot a Traditional Organizational ChartTestingDeveloperProjectManagerLogisticsDeveloperAnalystUser EducationCoordination with External Tea

13、msTechnology FocusBusiness FocusEnd UsersBusinessArchitectsandPlannersCustomerTechnology Architectsand Steering CommitteesOperations and SupportGroupsEndUsersProject TeamUserEducationDevelopmentTestingLogisticsManagementProductManagementProgramManagementLesson 3: Underlying Team Model PrinciplesSome

14、 of the principles and practices that make the team model successfulPrinciples of a Successful TeamShared project visionProduct mindsetZero-defect mindsetCustomer-focused mindset Willingness to learnWhat it meansClearly understanding project goals and objectivesUnderstanding and buying into a vision

15、 that is held by all team members and the customerWhy it is importantProvides the team a uniform sense of purposeResolves conflicting and contradictory visionsClarifies project goals and objectivesEnsures that team members are working toward the same goalShared Project VisionProduct MindsetWhat it m

16、eansTreating all work as part of a projectTreating the final deliverable of the project as a productWhy it is importantFocuses the team on execution rather than processEnables the team to use product development techniquesIncreases team identity and accountabilityZero-Defect MindsetWhat it meansComm

17、itting to qualityPerforming work at the highest possible level of qualityFocusing on achieving the quality bar set by the teamWhy it is importantIncreases product stabilityIncreases schedule predictabilityImproves accountabilityCustomer-Focused MindsetWhat it meansCommitting to understanding and sol

18、ving the business problemFocusing on the alignment of business and technologyInvolving the customer throughout the processWhy it is importantIncreases focus on customer needs, which improves ability to solve the business problemFocuses innovation on solving the business problemWillingness to LearnWh

19、at it meansCommitting to improvement through gathering and sharing knowledgeInstitutionalizing learning through such techniques as reviews and postmortems Why it is importantAllows team members to benefit from mistakesHelps team members to repeat successesMandates time for the team to learnLesson 4:

20、 Scaling the Team ModelHow to scale the team model to accommodate projects of varying sizesScaling for Small ProjectsProgramManagementDevelopmentTestingLogisticsManagementUserEducationProductManagementProgramManagementDevelopmentTestingLogisticsManagementUserEducationProductManagementNoNPossiblePUnl

21、ikelyUPPPPPPPPPPUUUUUUUUNNNNNNNNNNNNProductManagementExample: Combined RolesProgramManagementDevelopmentTestingLogisticsManagementUserEducationScaling for Large ProjectsDivide large teams into smaller teams, which have Lower process overheadLower management overheadLower communication overhead Faste

22、r implementationCreate feature teamsmultidisciplinary subteams organized around product feature setsCreate function teamsunidisciplinary subteams organized by functional roleExample: Feature Teams DevelopmentTestingUserEducationProgramManagementDevelopmentTestingUserEducationProgramManagementDevelop

23、mentTestingUserEducationProgramManagementProgramManagementDevelopmentTestingLogisticsManagementUserEducationProductManagementLeadTeamUITeamPrinting TeamCoreTeamExample: Function TeamGroup ProductManagementEvangelismPublicRelationsMarketingProduct PlanningProductManagementAgendaOverviewTeam ModelRisk

24、 ManagementProcess Vision approved milestoneProject plan approved milestoneScope complete milestoneRelease milestoneLesson 2: Risk Management OverviewThe MSF approach to risk managementRetired RisksRisk Assessment DocumentTop 103. Plan 5. Control2. Analyze1. IdentifyRiskStatements4. TrackRisk Manage

25、ment ProcessThe ongoing deliverable of this process is a living risk assessment documentAgendaOverviewTeam ModelRisk ManagementProcess Vision approved milestoneProject plan approved milestoneScope complete milestoneRelease milestoneLesson 1: Process Model for Application DevelopmentA high-level over

26、view of the MSF process model for application developmentProcess Models Life cycle models establish the order for project activitiesTwo models are popularThe waterfall modelThe spiral (or rapid application development) modelMSFs process model for application development combines the benefits of both

27、Milestone-based processFlexible and iterative processProcess Model for Application DevelopmentIENVSOGINNIPLANIGNNDEVLOPIGENSTABILZNGIIVision ApprovedProject PlanApprovedScope CompleteReleaseMilestone-Driven AccountabilityMilestoneVision approvedProject plan approvedScope completeReleasePrimary drive

28、rProduct managementProgram managementDevelopment and user educationTesting andlogistics managementPrinciples of a Successful ProcessCreating living documents Using versioned releasesMaking project trade-offsResourcesFeaturesScheduleBenefits of Versioned ReleasesForce closure on project issuesSet cle

29、ar and motivational goals with all team membersManage the uncertainty and change in project scopeEncourage continuous and incremental feature deliveryEnable shorter time to marketMaking Project Trade-offsResourcesFeaturesScheduleProject Trade-off MatrixConstrainOptimizeAcceptScheduleFeaturesResource

30、sResourcesFeaturesScheduleAgendaOverviewTeam ModelRisk ManagementProcess Vision approved milestoneProject plan approved milestoneScope complete milestoneRelease milestoneEnvisioning PhaseAchieving the vision approved milestoneEnvisioningCreating a high-level view of the projects goals and constraint

31、sServes as an early form of planningHelps the team pull different perspectives into a common understandingProvides the basis for future planning Captures what the customer and key stakeholders deem essential for successDefining the ScopeResourcesFeaturesScheduleEnvisioningVision Approved MilestoneIE

32、NVSOGINNIPLANIGNNDEVLOPIGENSTABILZNGIIProject PlanApprovedReleaseVision ApprovedScope CompleteSignals agreement onThe reason for the projectThe expected outcomeProject feasibilityProject goals and constraintsOpportunities and risksProject structureTesting strategies; acceptance criteria; implication

33、s Team Focus During EnvisioningProduct managementProgram managementDevelopmentUser educationTestingLogistics managementVision documentDesign goals; solution concept; project structurePrototypes; development options; implicationsDeployment implications; support implicationsUser performance needs and

34、implicationsRoleFocusSuggested Interim MilestonesRisk Assessment Document DraftedVision Document DraftedVision ApprovedAre visible at the team level Provide an opportunity for team members to synchronize their workProvide an opportunity for team members to assess project progress and statusCore Team

35、 FormedDeliverablePurposeVision documentRisk assessment documentProject structure documentDescribes what you want to do and how you plan to do itDescribes the risks the project entailsDescribes the projects organizational structureDeliverables for Vision ApprovedOwnerProduct managementProgram manage

36、mentProgram managementContentPurposeProblem statementVision statementSolution conceptUser profilesBusiness goalsDesign goalsWhy you want to do itWhat you want the product to beWhat you will doWho will use the productWhat you want to accomplishHow you plan to accomplish itContents of the Vision Docum

37、entRisk Assessment DocumentAssessing preliminary project risks and planning their managementIs created during the five-step risk management processIs the initial assessment of project riskLays the groundwork for ongoing risk managementProvides a basis for scheduling and decision-makingProject Struct

38、ure DocumentDescribing the projects organizational structure and project management processLists information on team members Includes team logistical information Describes team processes Acts as a repository for project documentation templatesAgendaOverviewTeam ModelRisk ManagementProcess Vision app

39、roved milestoneProject plan approved milestoneScope complete milestoneRelease milestoneLesson 1: Planning PhaseAchieving the project plan approved milestoneImportance of PlanningRepair Cost of Design Defects by Phase10080604020EnvisioningPlanningDevelopingStabilizingFurther Defining the ScopeResourc

40、esFeaturesSchedulePlanningProject Plan Approved MilestoneIENVSOGINNIPLANIGNNDEVLOPIGENLSTABIZNGIIVision ApprovedProject PlanApprovedScope CompleteReleaseSignals agreement onProject trade-off strategyProject risksWhat will be builtWhen it will be builtHow it will be builtWho will build itTeam Focus D

41、uring PlanningProduct managementProgram managementDevelopmentUser educationTestingLogistics managementRoleFocusDesign; communications plan and scheduleDesign; functional specification; master project plan and master project scheduleDesign; development plan and schedule; proof of concept developmentD

42、esign evaluation; testing plan and scheduleDesign evaluation; logistics plan and scheduleDesign; user performance support; user education plan and scheduleSuggested Interim MilestonesFunctional Specification DraftedProject PlanApprovedMaster Project Schedule DraftedMaster Project Plan DraftedDesign

43、Process OverviewLogical DesignConceptual DesignScenariosPhysical DesignComponents,User Interface, and Physical DatabaseObjects and Services,User Interface, and Logical DatabaseRelationship to PlanningProject PlanApprovedPhysical Design BaselineConceptual DesignLogical DesignPhysical DesignVisionAppr

44、ovedLogical Design BaselineConceptual Design BaselineMSF Application ModelBusiness ServicesUser ServicesData ServicesApplication 1Application 2DeliverablePurposeFunctional specificationMaster project planMaster project scheduleRevised master risk assessment documentDescribes what will be builtDescri

45、bes how it will be builtDescribes when it will be builtDescribes any issues in building itDeliverables for Project Plan ApprovedOwnerProgram managementProgram managementProgram managementProgram managementContents of the Functional SpecificationContentPurposeVision summaryDesign goalsRequirementsUsa

46、ge summaryFeaturesDependenciesSchedule summaryIssuesAppendixesWhat you want the product to be, justification for it, and key high-level constraintsWhat you want to achieve with the productWhat you require from the productWhen the product will be used and who will use itWhat exactly the product doesO

47、ther factors the product depends onKey dates and deliverablesWhat risks might impact the projectDesign process outputMaster Project PlanConsolidating feature team and role work plansDescribes how feature teams and roles will execute their tasksSynchronizes the plans across the teamIncludesDevelopmen

48、t planTest planTraining planUser support planCommunications planDeployment planMaster Project ScheduleConsolidating feature team and role work schedulesDescribes when feature teams and roles will execute their tasks Synchronizes the schedules across the team IncludesProduct ship dateDevelopment sche

49、duleTest scheduleTraining scheduleUser support scheduleCommunications scheduleDeployment scheduleMaster Risk Assessment DocumentConsolidating feature team and role risk assessmentsProvides an overall view of project riskSynchronizes the assessments across the teamDrives high-level decision-making an

50、d prioritization of effortLesson 3: Scheduling PrinciplesSome of the principles and practices that help make scheduling more accuratePrinciples of Accurate SchedulingBottom-up estimating Fixedship date mindsetRisk-driven schedulingScheduling for an uncertain futureAdding buffer timeUsing interim dev

51、elopment milestonesUsing discrete tasksBottom-up EstimatingWhat it meansHaving those who do the work estimate the effortRolling up task-level estimatesRecognizing that experience is the best estimating techniqueWhy it is importantIncreases the accuracy of the estimateFosters team buy-in of the sched

52、uleMotivates efficient workFixedShip Date MindsetWhat it meansTreating a projects projected ship date as unchangeableCommitting to a ship date because its realisticWhy it is importantForces creativity by removing the option of delaying the ship date Empowers the team by giving it an effective decisi

53、on-making toolProvides a motivational team goal What it meansPrioritizing tasks based on the level of risk involvedPrioritizing features based on their importance to key stakeholders Why it is importantMinimizes wasted effortAllows the greatest amount of reaction time for risk mitigationManages cust

54、omer expectations more productivelyEncourages early proof-of-concept prototypesRisk-Driven SchedulingScheduling for an Uncertain FutureWhat it meansRecognizing that the future really is uncertainCreating schedules that are designed to adjust to the unexpectedWhy it is importantCreates a more accurat

55、e schedule by building in buffer time to accommodate the unknownCreates a more accurate schedule by breaking large projects into smaller subprojects through interim development milestonesCreates a more accurate schedule by using discrete tasks for increased visibilityAdding Buffer TimeRecognize the

56、critical need for buffer timeUse confidence in team estimates to help determine the amount of bufferExternally communicate the milestone date, not the team-estimated dateKeep buffer ownership at the program management levelDevelopment TimeBuffer TimeTeam-Estimated DateMilestoneInternal Release 1Inte

57、rnal Release 26 to 8 weeksFeature Development2 to 4 weeks2 to 3 weeksTesting andStabilizingBuffer TimeAcceptanceTestingMilestoneReviewUsing Interim Development MilestonesSegment large feature sets into smaller chunksMake the chunks as independent as possibleAssess progress at interim milestones and

58、adjust for plan variationsTreat each interim milestone as a practice releaseUsing Discrete TasksHave team leads break down and prioritize product functionality and associated tasksDefine tasks clearly, with a beginning and end point, a single output, and a single ownerLimit task size to efforts that

59、 require one to two weeksHave team members use bottom-up estimating to determine task durationAssess estimated and actual task durations and make necessary course correctionsAgendaOverviewTeam ModelRisk ManagementProcess Vision approved milestoneProject plan approved milestoneScope complete mileston

60、eRelease milestoneLesson 1: Developing PhaseAchieving the scope complete milestoneSignals agreement onThe planned feature setWhether the planned featureset has been developedBaselined materials to support user performanceThe stabilization process, including betas and testingIENVSOGINNIPLANIGNNDEVLOP