Microsoft framework solutions team process model

This team member often is the interface to the Microsoft Operations Framework MOF team that will operate the solution. Development is a unique role because it cannot be shared with other roles. Developers are tasked with making sure the solution meets specifications. The model is scalable. On small teams, as few as three members can cover all the roles.

On large teams, groups of people can be assigned a single role. Beware of trying to take on too many roles yourself; recruit the appropriate people to fill out your team. The Envisioning phase creates an overall vision and scope for the project. Its milestone is the delivery of a vision statement that both customer and project team can agree on. The associated milestone is Project Plan Approved, which equates to customer approval to tackle the project as outlined.

The Development phase follows through on the plan and includes tests for coverage all specs delivered and usability. All known issues must either be fixed or made part of a future cycle.

The Stabilizing phase starts with beta testing and ends with customer approval and release to operations. Conceptual design; business requirements analysis; communications plan.

Conceptual and logical design; functional specification; master project plan and master project schedule, budget. During technology validation, the team evaluates the products or technologies that will be used to build or deploy the solution to ensure that they work according to vendor's specifications.

This is the initial iteration of an effort that later produces a proof of concept and, ultimately, the development of the solution itself. Often, technology validation involves competitive evaluations sometimes called "shoot outs" between rival technologies or suppliers. Another activity that must be completed at this milestone is baselining the customer environment. The team conducts an audit also known as "discovery" of the "as is" production environment the solution will be operating in.

This includes server configurations, network, desktop software, and all relevant hardware. At this milestone, the functional specification is complete enough for customer and stakeholder review. At this point the team baselines the specification and begins formally tracking changes.

The functional specification is the basis for building the master project plan and schedule. The functional specification is maintained as a detailed description, as viewed from the user perspective, of what the solution will look like and how it will behave. The functional specification can only be changed with customer approval.

The results of the design process are often documented in a design document that is separate from the functional specification. The design document is focused on describing the internal workings of the solution. The design document can be kept internal to the team and can be changed without burdening the customer with technical issues.

In MSF, the master project plan is a collection or "roll up" of plans from the various roles. It is not an independent plan of its own. Depending on the type and size of project, there will be various types of plans that are merged into the master project plan. Some of these plans are shown in Figure 9. Figure 9: Master Project Plan See full-sized image. The benefits of having a plan made up of smaller plans are that it facilitates concurrent planning by various team roles and provides for clear accountability because specific roles are responsible for specific plans.

The benefits of presenting these plans as one are that they facilitate synchronization into a single schedule, facilitate reviews and approvals, and help to identify gaps and inconsistencies. The master project schedule includes all of the detailed project schedules, including the release date. Like the master project plan, the master project schedule combines and integrates all the schedules from each team lead.

The team determines the release date after negotiating the functional specification draft and reviewing the master project plan draft. Although features, resources, and release date may vary, a fixed release date will cause the team to prioritize features, assess risks, and plan adequately. A working development environment allows proper development and testing of the solution so that it has no negative impact on production systems.

It is generally a good idea to set up separate development servers that developers can use. The entire team should be informed that anything on such servers could become unstable and require re-installation. This is also the environment where infrastructure components are developed, such as server configurations, deployment automation tools and hardware.

In order to avoid delay, the development and testing environment should be set up even as plans are being finalized and reviewed. This includes development workstations, servers, and tools. The backup system should be established if it is not already in place.

CD-ROM images of standard server configurations are often used as machines are often "wiped or reformatted. If the organization does not already have a suitable test lab in place, the team must build one. The test environment must be as close a simulation to the live environment as is feasible.

While this can be expensive, it is very important. Otherwise, certain bugs may go undetected until the solution is deployed "live" to production.

Organizations using MOF can take advantage of information contained in the enterprise Configuration Management Database CMDB as a kind of bill of materials for replicating the production environment.

During the developing phase the team accomplishes most of the building of solution components documentation as well as code. However, some development work may continue into the stabilization phase in response to testing. The developing phase involves more than code development and software developers.

The infrastructure is also developed during this phase and all roles are active in building and testing deliverables. The developing phase culminates in the scope complete milestone. At this milestone, all features are complete and the solution is ready for external testing and stabilization. This milestone is the opportunity for customers and users, operations and support personnel, and key project stakeholders to evaluate the solution and identify any remaining issues that must be addressed before the solution is released.

The following table describes the focus and responsibility areas of each team role during developing. Functional specification management; project tracking; updating plans. Code development; infrastructure development; configuration documentation. Training; updated training plan; usability testing; graphic design. Functional testing; issues identification; documentation testing; updated test plan. Rollout checklists, updated rollout and pilot plans; site preparation checklists.

The proof of concept tests key elements of the solution on a non-production simulation of the existing environment. The team walks operations staff and users through the solution to validate their requirements. Because the developing phase focuses on building the solution, the project needs interim milestones that can help the team measure build progress. Developing is done in parallel and in segments, so the team needs a way to measure progress as a whole. Internal builds accomplish this by forcing the team to synchronize pieces at a solution level.

How many builds and how often they occur will depend on the size and duration of the project. Often it makes sense to set interim milestones to achieve a visual design freeze and a database freeze because of the many dependencies on these. For example, the screens that are needed to create documentation and the database schema form a deep part of the overall architecture.

The stabilizing phase conducts testing on a solution whose features are complete. Testing during this phase emphasizes usage and operation under realistic environmental conditions.

The team focuses on resolving and triaging prioritizing bugs and preparing the solution for release. Early during this phase it is common for testing to report bugs at a rate faster than developers can fix them. There is no way to tell how many bugs there will be or how long it will take to fix them. There are, however, a couple of statistical signposts known as bug convergence and zero-bug bounce that helps the team project when the solution will reach stability.

These signposts are described below. MSF avoids the terms "alpha" and "beta" to describe the state of IT projects. These terms are widely used, but are interpreted in too many ways to be meaningful in industry. Teams can use these terms if desired, as long as they are defined clearly and the definitions understood among the team, customer, and stakeholders. Once a build has been deemed stable enough to be a release candidate, the solution is deployed to a pilot group.

The stabilizing phase culminates in the release readiness milestone. Once reviewed and approved, the solution is ready for full deployment to the live production environment. The release readiness milestone occurs at the point when the team has addressed all outstanding issues and has released the solution or placed it in service.

At the release milestone, responsibility for ongoing management and support of the solution officially transfers from the project team to the operations and support teams.

The following describes the focus and responsibility areas of each team role during the stabilizing phase. Pilot setup and support; deployment planning; operations and support training. Bug convergence is the point at which the team makes visible progress against the active bug count. That is, the rate of bugs resolved exceeds the rate of bugs found.

Figure 10 illustrates bug convergence. After bug convergence, the number of bugs should continue to decrease until zero-bug release. Bug convergence tells the team that the end is actually within reach. Figure Bug Convergence See full-sized image. Figure 11 illustrates a zero-bug bounce.

After zero-bug bounce, the bug peaks should become noticeably smaller and should continue to decrease until the solution is stable enough for the team to build the first release candidate. Figure Zero Bug Bounce See full-sized image. Careful bug triaging is vital because every bug that is fixed risks the creation of a new bug. Achieving zero-bug bounce is a clear sign that the team is in the endgame as it drives to a stable release candidate. Note that new bugs will certainly be found after this milestone is reached.

A series of release candidates are prepared and released to the pilot group. Each release candidate is an interim milestone. Other features of a release candidate are:. Building a release candidate tests its fitness for release, that is, whether all necessary pieces are present.

The test period that follows generation of a release candidate determines whether a release candidate is ready to release to production or whether the team must generate a new release candidate with the appropriate fixes.

Testing release candidates, which is done internally by the team, requires highly focused and intensive efforts, and focuses heavily on flushing out showstopper bugs. It is unlikely that the first release candidate will be the one that is released. Typically, show stopping bugs will be found during the intensive testing of a release candidate. The focus of this interim milestone is to prepare for a pilot release.

This interim milestone is important because the solution is about to "touch" the live production environment. For this reason the team must test as much of the entire solution as possible before the pilot test begins.

The pre-production test complete interim milestone is not complete until the team ensures that everything developed to deploy the solution is fully tested and ready. User acceptance testing and usability studies begin during the development phase and continue during stabilization. These are conducted to ensure that the new system is able to successfully meet user and business needs.

This is not to be confused with customer acceptance , which occurs at the end of the project. When this milestone has been achieved, users have tested and accepted the release in a non-production environment and verified that the system integrates with existing business applications and the IT production environment.

The rollout and backout procedures should also be confirmed during this period. Upon approval of release management, software developed in-house and any purchased applications are migrated from secure storage to a pristine archive location. Release management is responsible for building releases assembling the release components in the test environment from the applications stored in the DSL.

User acceptance testing gives support personnel and users the opportunity to understand and practice the new technology through hands-on training. The process helps to identify areas where users have trouble understanding, learning, and using the solution. Release testing also gives release management the opportunity to identify issues that could prevent successful implementation. During this interim milestone, the team will test as much of the entire solution in as true a production environment as possible.

In MSF, a pilot release is a deployment to a subset of the live production environment or user group. Depending on the context of the project, a pilot release can take the following forms:. In an enterprise, a pilot can be a group of users or a set of servers in a data center. In Web development, pilot release takes the form of hosting site files on staging server s or folders that are live on the Internet, only with a test Web address. Commercial software vendors, such as Microsoft, often release products to a special group of early adopters prior to final release.

What all these forms of piloting have in common is that they are instances of testing under live conditions. The pilot complete interim milestone is not complete until the team ensures that the proposed solution is viable in the production environment and every component of the solution is ready for deployment. In addition, the following actions must be followed:.

Prior to beginning a pilot, the team and the pilot participants must clearly identify and agree upon the success criteria of the pilot. These should map back to the success criteria for the development effort. Any issues identified during the pilot must be resolved either by further development, by documenting resolutions and work-arounds for the installation teams and production support staff, or by incorporating them as supplemental material in training courses.

Before the pilot is started, a support structure and issue-resolution process must be in place. This may require that support staff be trained. The procedures used for issue resolution during a pilot may vary significantly from those used during deployment and when the solution is in full production. In order to determine if the deployment process will work, it is necessary to implement a trial run or a rehearsal of all the elements of the deployment so that you may identify issues prior to the actual deployment.

Once enough pilot data has been collected and evaluated, the team is at a point of decision. It is at this point that one of the following strategies must be selected:. The pilot is tried again with a more stable release. During this phase, the team deploys the core technology and site components, stabilizes the deployment, transitions the project to operations and support, and obtains final customer approval of the project.

After the deployment, the team conducts a project review and a customer satisfaction survey. Stabilizing activities may continue during this period as the project components are transferred from a test environment to a production environment.

The deployment complete milestone culminates the deploying phase. By this time, the deployed solution should be providing the expected business value to the customer and the team should have effectively terminated the processes and activities it employed to reach this goal. The customer must agree that the team has met its objectives before it can declare the solution to be in production and close out the project.

This requires a stable solution, as well as clearly stated success criteria. In order for the solution to be considered stable, appropriate operations and support systems must be in place. Documentation repository for all versions of documents, load sets, and code developed during the project. The following describes the focus and responsibility areas of each team role during the deploying phase.

Most infrastructure solutions include a number of components that provide the framework or backbone for the entire solution. These components do not represent the solution from the perspective of a specific set of users or a specific site. However, the deployment of sites or users generally depends on this framework. In addition:. Components are the enabling technology of the enterprise solution.

Examples include domain controllers, mail routers, remote access servers, database servers. Depending on the solution, the core technology may need to be deployed before or in parallel with site deployments. To avoid delays, core components may be reviewed and approved for deployment in advance of other parts of the solution still being stabilized.

The operations staff must feel confident making this commitment before the whole solution has been proved to be stable.

At the completion of this milestone, all targeted users have access to the solution. Each site owner has signed off that their site is operating, though there may be some issues. Customer and user feedback might reveal some problems. The training may not have gone well, or a part of the solution may have malfunctioned after the team departed the site.

Some sites may need to be revisited based on feedback from site satisfaction surveys. At this point, the team makes a concentrated effort to finish deployment activities and close out the project.

Many projects, notably in web development, do not involve client-side deployments and therefore this milestone is not applicable. At the deployment stable interim milestone, the customer and team agree that the sites are operating satisfactorily.

However, it is to be expected that some issues will arise with the various site deployments. These continue to be tracked and resolved. It can be difficult to determine when a deployment is "complete" and the team can disengage.

Newly deployed systems are often in a constant state of flux, with a continuous process of identifying and managing production support issues. The team can find it difficult to close out the project because of the ongoing issues that will surface after deployment. For this reason, the team will need to clearly define a completion milestone for the deployment rather than attempt to reach a point of absolute finality. If the customer expects members of the project team to be involved in ongoing maintenance and support, those resources should transition into a new role as part of the operations and support structure after project close-out.

At this late stage, team members and external stakeholders will likely begin to transition out of the project. Part of disengaging from the project includes transitioning operations and support functions to permanent staff. In many cases, the resources to manage the new systems will already exist. In other cases, it may be necessary to design new support systems.

Given the scope of the latter case, it may be wise to consider that as a separate project. The period between the deployment stable and deployment complete milestones is sometimes referred to as a "quiet period.

Typical quiet periods are 15 to 30 days long. The purpose of the quiet period is to measure how well the solution is working in normal operation and to establish a baseline for understanding how much maintenance will be required to run the solution. Organizations using MOF will measure the number of incidents, the amount of downtime, and collect performance metrics of the solution. This data will help form the assumptions used by the operations Service Level Agreement SLA on expected yearly levels of service and performance.

The following supporting practices help teams apply the MSF process model to their project. 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 a technique known as "time-boxing" keep pressure on the project team to prioritize features and activities. Add buffer additional time to project schedules to permit the team to accommodate unexpected problems and changes. The amount of buffer to apply depends on the amount of risk.

By assessing risks early in the project, the likeliest risks can be evaluated for their impact on the schedule and compensated for by adding buffer time to the project schedule. One way to think of buffer time is as an estimate for unknown tasks and events. No matter how experienced the team, not all project tasks can be known and estimated in advance. Yet, be assured that some project risks occur and impact the project. The corrective actions required to respond to these risks will take time.

Buffer time should not be added by padding estimates for individual tasks. Since work expands to fill the time scheduled to do it Parkinson's Law , the buffer will be absorbed by planned tasks, not unplanned events. Buffer time should be scheduled as if it were another task. Typically, buffer is allocated immediately before major milestones, especially the later ones. It always should lie on the project's critical path. The critical path is the longest chain of dependent tasks in a project and directly determines the duration of the project.

As buffer time is expended over the course of the project, the remaining amount should be carefully tracked and conserved. If a feature is added, or resources removed from the project, do not compensate by using buffer time. If you do, your ability to compensate for risk has been correspondingly reduced. Negotiate features, resources, and schedule using the tradeoff triangle shown in Figure 5. If all of the buffer time has been used, make the whole team aware that any disruption or delay is very likely to have a "knock on" effect and jeopardize the end date.

Even a large and complex project may be divided into smaller, more efficient teams that work in parallel, if the teams periodically synchronize their activities and deliverables.

This maintains a focus on consistent quality across the project, helps the program manager in charting overall progress, and emphasizes accountability within each of the teams. A fundamental development strategy at Microsoft is to divide large projects into multiple versioned releases, with little or no separate maintenance phase. At each major milestone the team, customer and key stakeholders meet to review the deliverables for that milestone and assess the overall progress of the project.

For large projects, this is also done at selected interim milestones as well. After these meetings, the team conducts an internal team-facing review to evaluate team project performance. This review should be considered a Quality Assurance activity that can in turn trigger changes in how the project is being conducted.

The composition of individual team members often changes over the course of the project. Be sure to capture the input and learning of departing team members at major milestones before they move on. Prototyping allows pre-development testing from many perspectives, especially usability, and helps create a better understanding of user interaction.

It also leads to improved product specifications. Regular builds of the solution are the most reliable indicator available that the project is on track with development and that the team is functioning well together.

Within the deployment phase, pilot testing cycles serve a similar purpose. Enterprise solutions must emphasize business agility. To do this they must accommodate continuous change in customer needs.

Rapid development and deployment cycles will facilitate the creation of versioned releases, which allow the evolving solution to respond to changing needs and requirements. Use the vision statement and specifications to maintain focus on the stated business goals and to trace critical features back to the original requirements. Apply the vision statement and specifications as filters to identify, discuss, and remove additional features that may have been added without proper consideration after the project had been defined.

Estimates for IT projects should be made by those who will do the work. Elements of MSF are based on well-known industry best practices and incorporate Microsoft's more than 25 years of experience in the high-tech industry. Most of the previous obstacles could be expressed visually by the following dialogue between Alice ant the Cat from the book: Alice in Wonderland , by Lewis Carroll. MSF is a collection of guidance for successfully delivering information technology solutions faster and with fewer people and less risk, while enabling higher quality results.

MSF is called a framework for specific reasons. The MSF philosophy holds that there is no single structure or process that applies to all requirements and environments, and recognizes that, nonetheless, the need for guidance still exists. As a framework, MSF provides this guidance without imposing so much prescriptive detail that it becomes impossible to comprehend, or useful only within a narrow band of scenarios.

MSF has the following characteristics which make it applicable in a broad range of IT organizations and scenarios. All these principles express the MSF philosophy, forming the basis of a coherent approach to organizing people and processes for projects undertaken to deliver technology solutions.

They underlie both the structure and the application of MSF. Although each principle has been shown to have merit on its own see literature references at end of white paper , many are interdependent in the sense that the application of one supports the successful application of another. When applied in tandem, they create a strong foundation that enables MSF to work well in a wide range of projects varying in size, complexity, and type.

MSF proposes an open and inclusive approach to communications, both within the team and with key stakeholders, subject to practical restrictions such as time constraints and special circumstances.

A free flow of information not only reduces the chances of misunderstandings and wasted effort, but also ensures that all team members can contribute to reducing uncertainties surrounding the project by sharing information that belongs to their respective domains. Shared vision is one of the key components of the MSF Team and Process models, emphasizing the importance of understanding the project goals and objectives.

When all participants understand the shared vision and are working toward it, they can align their own decisions and priorities representing the perspectives of their roles with the broader team purpose represented by that vision.

The iterative nature of the MSF Process Model requires that a shared vision exist to guide a solution toward the ultimate business result. Without this vision, the business value of a solution will lean toward mediocrity. A shared vision for the project is fundamental to the work of the team. The process of creating that vision helps to clarify goals and bring conflicts and mistaken assumptions to light so they can be resolved.

Once agreed upon, the vision motivates the team and helps to ensure that all efforts are aligned in service of the project goal. It also provides a way to measure success. Clarifying and getting commitment to a shared vision is so important that it is the primary objective of the first phase of any MSF project. Empowerment has a profound impact on MSF. The MSF Team Model is based on the concept of a team of peers and the implied empowered nature of such team members.

Empowered team members hold themselves and each other accountable to the goals and deliverables of the project. Empowered teams accept responsibility for the management of project risks and team readiness and therefore proactively manage such risk and readiness to ensure the greatest probability of success.

Creating and managing schedules provides another example of team empowerment. MSF advocates bottom-up scheduling, meaning that the people doing the work make commitments as to when it will be done.

The result is a schedule that the team can support because it believes in it. MSF team members are confident that any delays will be reported as soon as they are known, thereby freeing team leads to play a more facilitative role, offering guidance and assistance when it is most critical. The monitoring of progress is distributed across the team and becomes a supportive rather than a policing activity. The MSF Team Model is based on the premise that each team role presents a unique perspective on the project.

Yet, for project success, the customer and other stakeholders need an authoritative single source of information on project status, actions, and current issues. To resolve this dilemma, the MSF Team Model combines clear role accountability to various stakeholders with shared responsibility among the entire team for overall project success.

Each team role is accountable to the team itself, and to the respective stakeholders, for achieving the role's quality goal. In this sense, each role is accountable for a share of the quality of the eventual solution. At the same time, overall responsibility is shared across the team of peers because any team member has the potential to cause project failure.

It is interdependent for two reasons: first, out of necessity, since it is impossible to isolate each role's work; second, by preference, since the team will be more effective if each role is aware of the entire picture. This mutual dependency encourages team members to comment and contribute outside their direct areas of accountability, ensuring that the full range of the team's knowledge, competencies, and experience can be applied to the solution.

Successful solutions, whether targeted at organizations or individuals, must satisfy some basic need and deliver value or benefit to the purchaser. By combining a focus on business value with shared vision, the project team and the organization can develop a clear understanding of why the project exists and how success will be measured in terms of business value to the organization. The MSF Team Model advocates basing team decisions on a sound understanding of the customer's business and on active customer participation throughout the project.

The Product Management and User Experience roles act as the customer and user advocates to the team, respectively. These roles are often undertaken by members of the business and user communities. A solution does not provide business value until it is fully deployed into production and used effectively. For this reason, the life cycle of the MSF Process Model includes both the development and deployment into production of a solution, thereby ensuring realization of business value. Often, neither the outcome nor the means to deliver it is well understood, and exploration becomes a part of the project.