Module 3: Process Model THIS PAGE LEFT INTENTIONALLY BLANK 0RGXOH#6=#3URFHVV#0RGHO# 2EMHFWLYHV At the end of this module, you will be able to „ Understand the process model for infrastructure deployment at a high level „ Understand the benefits of versioned releases „ Understand the relationships among project variables „ Understand the concept of managing trade-offs # 6²6 6²7# # 0RGXOH#6=#3URFHVV#0RGHO /HVVRQV Lessons Process Model for Infrastructure Deployment Versioned Releases Managing Project Trade-offs 0RGXOH#6=#3URFHVV#0RGHO# # /HVVRQ#4=#3URFHVV#0RGHO#IRU#,QIUDVWUXFWXUH#'HSOR\PHQW Lesson 1: Process Model for Infrastructure Deployment A high-level overview of the MSF process model for infrastructure deployment 6²8 6²9# # 0RGXOH#6=#3URFHVV#0RGHO 3ULQFLSOHV#RI#WKH#0LFURVRIW#'HSOR\PHQW#3URFHVV „ Schedule for an uncertain future „ Minimize uncertainty through effective risk management „ Use frequent builds and quick tests to maximize product stability and predictability „ Cycle rapidly „ Focus creativity by evolving features and constraining resources „ Establish fixed schedules „ Use small teams working in parallel with frequent synchronization points This slide and the one that follows describe the fundamental concepts and guiding principles that underlie Microsoft’s development process „ Add buffer (additional) time to project schedules to help the project team accommodate unexpected problems and changes „ For most projects, the ability to manage risk is the limiting factor for project success „ A regular solution build is the single most-reliable indicator that the team is functioning and development is progressing „ Versioned releases enable the project team to respond to continuous changes „ Microsoft’s general development approach is to constrain development resources and budget, which focuses creativity, forces decision-making, and optimizes the release date „ Internal time limits keep pressure on the project team to prioritize features (referred to as time-boxing) and activities, as well as to make critical tradeoff decisions „ A large team can work as many small teams in parallel if team members periodically synchronize their activities and deliverables 0RGXOH#6=#3URFHVV#0RGHO# # 6²: 3ULQFLSOHV#RI#WKH#0LFURVRIW#'HSOR\PHQW#3URFHVV#+FRQWLQXHG, „ Break large projects into manageable parts that can be delivered in a few months „ Use vision statements and outline specifications to guide projects—baseline early, freeze late „ Avoid scope creep „ Use proof-of-concept prototyping to allow for predevelopment testing „ Apply zero-defect mindset „ Apply no-blame milestone reviews These are additional principles of the MSF process: „ Microsoft’s fundamental development strategy is to divide large projects into multiple versioned releases, with no separate maintenance phase „ Use high-level vision statements and outline specifications to get projects going, rather than trying to write a complete and detailed specification at the outset „ The vision statement and specifications help the team maintain proper focus and trace critical features to the original requirements, as well as filter out any additional features that creep into plans after the project has been defined „ Prototyping allows predevelopment testing from many perspectives, especially usability, and helps create a better understanding of user interaction It also leads to better product specifications „ To maximize product stability and predictability, the team should be able to bring the solution to a release condition and keep it there indefinitely „ As soon as a milestone is achieved, conduct a milestone review to highlight lessons learned, especially things done well This is the mechanism by which learning is consolidated and institutionalized 6²;# # 0RGXOH#6=#3URFHVV#0RGHO (OHPHQWV#RI#WKH#6ROXWLRQ Support Training Communications Documentation Installation Process Selected Technologies The term “solution” in this course refers to the synthesis of all of these elements, the broad categories for those things the team needs to be successful during the deploying phase Projects may vary in complexity and the amount of effort necessary for development Many of these elements may not be necessary in a relatively simple deployment, although the more complex, larger-scale deployment efforts will most likely require all of these „ Selected technologies may be new to the enterprise or organization, or may be upgrades, updates, or added components Technologies may include hardware, software, peripherals, or network components „ Training applies to everyone who will be using or supporting the new technology being deployed „ Documentation refers to all the information needed to install, maintain, support, and use the solution „ Support processes include the procedures necessary to perform backups, restorations, disaster recovery, troubleshooting, and help desk functions „ External communications involve keeping outside stakeholders apprised of the progress of the deployment and how the solution will affect them „ Installation processes are the steps performed to install, and at times uninstall, the selected technologies 0RGXOH#6=#3URFHVV#0RGHO# # 6²< ,QIUDVWUXFWXUH#'HSOR\PHQW#3URFHVV#0RGHO Deployment Complete Vision/Scope Approved Release Project Plan Approved The process model for infrastructure deployment consists of four phases, each culminating in an externally visible milestone „ The envisioning phase is the period during which the team and the customer define the business requirements and the overall goals of the project The envisioning phase culminates in the vision/scope approved milestone, indicating team and customer agreement on project direction „ The planning phase is the period during which the team and the customer define what will be built and deployed as well as how and when The planning phase culminates in the project plan approved milestone, indicating the project team, customer, and key project stakeholders agree on what will be delivered and when „ The developing phase is the period during which the team builds and tests the solution After testing, the team pilots the technology and stabilizes it in preparation for release The developing phase culminates in the release milestone, indicating that the solution is ready to be deployed in production „ The deploying phase is the period during which the team deploys the solution to all sites and ensures that it is stable and usable The deploying phase culminates in the deployment complete milestone, at which point responsibility for the solution shifts to the operations and support teams 6²43# # 0RGXOH#6=#3URFHVV#0RGHO 0LOHVWRQH0'ULYHQ#3URFHVV „ Milestones are review and synchronization points, not freeze points „ Milestones enable the team to assess progress and make midcourse corrections „ Process model uses two types of milestones „ Major milestones „ Interim milestones „A major milestone achievement represents team and customer agreement to proceed „ Deliverables are physical evidence that the team has reached a milestone Milestones give the project team an opportunity to adjust the scope of the project to reflect changing customer requirements or to react to risks There are two general types of milestones: „ Major milestones serve to transition from one phase to another and to transition responsibility across roles „ Interim milestones serve as early progress indicators and segment large work efforts into workable pieces Major milestones are also called external milestones because they are visible to outside parties, including the customer These milestones create opportunities for team members to synchronize their deliverables and expectations with customers and end users; with operations, support, and help desk personnel; with the distribution channel; and with other key project stakeholders 0RGXOH#6=#3URFHVV#0RGHO# # 6²44 0LOHVWRQH0'ULYHQ#$FFRXQWDELOLW\ Milestone Team role „ Vision/scope approved „ Product management „ Project plan approved „ Program management „ Release „ Development and testing „ Deployment complete „ Logistics management and user education Although program management oversees the overall process, achieving each milestone requires additional attention from different team roles Aligning a team role, or collection of team roles, with each of the four external milestones makes it clear who is individually responsible for achieving each milestone, which creates clear accountability When the project moves to a different phase, part of the process often includes transitioning responsibility to other roles The visible transitioning of responsibility is the hallmark of a healthy project 6²45# # 0RGXOH#6=#3URFHVV#0RGHO THIS PAGE LEFT INTENTIONALLY BLANK 0RGXOH#6=#3URFHVV#0RGHO# /HVVRQ#5=#9HUVLRQHG#5HOHDVHV Lesson 2: Versioned Releases The concept of versioned releases and their benefits # 6²46 6²47# # 0RGXOH#6=#3URFHVV#0RGHO )XQFWLRQDOLW\ 9HUVLRQHG#5HOHDVHV 7LPH Versioned releases allow the team to break up a solution for a large project by dividing it into a succession of versioned releases The first release delivers core functionality to the users Later releases add additional functionality until the deployed solution meets the customer’s needs Versioning allows the team to revalidate product vision as business requirements change Versioned releases not necessarily occur sequentially As project teams mature, they often work with overlapping release cycles 0RGXOH#6=#3URFHVV#0RGHO# # 6²48 %HQHILWV#RI#9HUVLRQHG#5HOHDVHV Versioned releases „ Force closure on project issues „ Set clear and motivational goals with all team members „ Manage the uncertainty and change in project scope „ Encourage continuous and incremental feature delivery „ Enable shorter time to deploy Versioned releases help the project team respond to ongoing changes in scope, schedule, and project risk They improve the team’s relationship with the customer and ensure that the best ideas are reflected in the solution Customers will be more receptive to deferring features until a later release if they trust the team to deliver the initial and subsequent solution releases in a timely fashion 6²49# # 0RGXOH#6=#3URFHVV#0RGHO *XLGHOLQHV#IRU#9HUVLRQHG#5HOHDVHV „ Adopt a product mindset „ Create a multirelease plan reflecting thought beyond the current deployment „ Cycle rapidly to make customers and users confident of your team’s ability to deliver „ Do not automatically push features into the next version; analyze each feature request for impact, feasibility, and priority „ Deliver core functionality first so you can build on it Maintaining a product mindset helps a team think beyond the current version because a product mindset focuses a team on execution and on what is being delivered at the end of the project Thinking beyond the current version enhances a team’s ability to make good decisions about what to build now and what to defer 0RGXOH#6=#3URFHVV#0RGHO# /HVVRQ#6=#0DQDJLQJ#3URMHFW#7UDGH0RIIV Lesson 3: Managing Project Trade-offs The project trade-off triangle and matrix # 6²4: 6²4;# # 0RGXOH#6=#3URFHVV#0RGHO du ce ur so he le Re Sc s 0DNLQJ#3URMHFW#7UDGH0RIIV Features As you develop and deploy a solution, you will inevitably have to make tradeoffs among the project variables—resources (people and money), schedule (time), and features (the solution) Those variables exist in a triangulated relationship and affect the quality of the solution After you have established the triangle, any change to one of its sides requires a correction on any one of the sides to maintain project balance, including, potentially, the same side on which the change first occurred The key to deploying a solution that matches the customer’s needs at the time in which they need it is finding the right balance between resources, deployment date, and features A project is successful when your customer believes you have made the right trade-offs, so ask your customer about priorities early and often 0RGXOH#6=#3URFHVV#0RGHO# # 6²4< le du he Sc Re so ur ce s 3URMHFW#7UDGH0RII#0DWUL[ Features 2SWLPL]H &RQVWUDLQ $FFHSW 5HVRXUFHV 6FKHGXOH )HDWXUHV Microsoft’s Approach Although the development strategy varies considerably by type of deployment, Microsoft’s general infrastructure deployment strategy is to: „ Constrain the project team resources and budget in order to focus creativity „ Optimize the deployment date in order to achieve early deployment „ Deliver features incrementally over multiple releases It is not unusual for the customer’s initial view of the project trade-off matrix to have a check mark in the “optimize” column for all three rows; similarly, the project team is likely to put a check mark in the “accept” column for all three roles Obviously, neither of these views is realistic nor acceptable to the other Although this slide demonstrates Microsoft’s favored approach to infrastructure deployment, bear in mind that customers will have their own specific requirements, and different deployments will necessitate different trade-off strategies 6²53# # 0RGXOH#6=#3URFHVV#0RGHO $FWLYLW\=#0DQDJLQJ#7UDGH0RIIV ,Q#VPDOO#WHDPV=# „ Read the scenario „ Use the trade-off triangle and matrix to resolve the challenge presented with the scenario „ Present your results to the class Activity 0RGXOH#6=#3URFHVV#0RGHO# # 6²54 6XPPDU\ „ What are the four phases of the process model for infrastructure deployment, and what are the milestones with which they culminate? „ What are the benefits of versioned releases? „ What are the main project variables, and how they relate to each other? Summary Now is the time to ask any further questions you may have about the material presented in this module 0RGXOH#6=#3URFHVV#0RGHO# THIS PAGE INTENTIONALLY LEFT BLANK # 6²55 ... Process Model for Infrastructure Deployment Versioned Releases Managing Project Trade-offs 0RGXOH#6=#3URFHVV#0RGHO# # /HVVRQ#4=#3URFHVV#0RGHO#IRU#,QIUDVWUXFWXUH#''HSOR\PHQW Lesson 1: Process Model. .. INTENTIONALLY BLANK 0RGXOH#6=#3URFHVV#0RGHO# 2EMHFWLYHV At the end of this module, you will be able to „ Understand the process model for infrastructure deployment at a high level „ Understand the... /HVVRQ#4=#3URFHVV#0RGHO#IRU#,QIUDVWUXFWXUH#''HSOR\PHQW Lesson 1: Process Model for Infrastructure Deployment A high-level overview of the MSF process model for infrastructure deployment 6²8 6²9# # 0RGXOH#6=#3URFHVV#0RGHO 3ULQFLSOHV#RI#WKH#0LFURVRIW#''HSOR\PHQW#3URFHVV