MSF Governance Model

A key component of the Microsoft Solution Delivery Lifecycle is the MSF Governance Model. The Governance Model is structured to allow a team to deliver key portions of a solution faster than would otherwise be possible if they focused on the highest priority features first and moved less critical ones to subsequent releases. The model is structured to help drive a team quickly to a shared consensus on how to deliver on the various aspects of a solution. The Governance Model is a flexible component of MSF that has been used successfully to improve project control, minimize risk, improve solution quality, and increase development speed. Because MSF is fully customizable, it is expected that an organization adapts the Governance Model to fit its business processes and existing solution delivery approaches.

As mentioned earlier, MSF is designed to provide the right guidance to the right people at the right time. To help achieve this, the MSF Governance Model couples project governance with process enactment, as depicted in Figure 6-4. Project governance focuses on optimizing a solution delivery process and efficient and effective use of project resources. Process enactment focuses on defining, building, and deploying a solution that meets the needs and expectations of the stakeholders.

Figure 6-4. MSF Governance Model, which consists of enactment and governance

From a different perspective, the one depicted in Figure 6-5, the core of the MSF Governance Model is orienting team members to how they should approach solution delivery (i.e., mindsets). The model then layers on principles to guide how a team should work together to deliver a solution. Next, the model calls for a team to define and complete a set of activities to realize a solution (i.e., process enactment). Finally, the model adds how to use project resources optimally, balance project constraints, and organize and perform project work to deliver a solution (i.e., project governance). Additional governance layers can be added if a project is part of a program or if it is necessary to reflect organizational governance.

Figure 6-5. How governance, activities, principles, and mindsets relate

The following sections as well as the next six chapters discuss key elements of the MSF Governance Model, namely, tracks, checkpoints, and the iterative approach to completing the work necessary to deliver a solution.

Tracks

At one level, tracks are overlapping, coordinated groupings of certain activities aimed at producing relevant deliverables for each track. However, MSF tracks are more than this; each has a distinct mission and represents a change in the pace and focus of a project. Tracks use reviews and synchronization points (called checkpointsdiscussed next) throughout each track to assist in determining whether track objectives are being met. Additionally, major checkpoints are used to bring closure to each track, which enables a shift of responsibilities for directing many activities and encourages a team to take a new perspective more appropriate for the goal(s) of the next track. Track closure is demonstrated by delivery of all required track deliverables and by the team and customer reaching a level of affirmative consensus around those deliverables. These deliverables, developed throughout a track, are used to initiate the next track. Note that this is likely a phased influence on the next track because it probably started before the end of the current track.

The MSF Governance Model consists of five overlapping enactment tracks and a persistent governance track that spans across the enactment tracks. Within each track, activities are further decomposed and regrouped into subtracks, called work streams. Work streams might be further decomposed and regrouped into swim lanes. The next three sections provide a highlevel understanding of enactment tracks, what each advocacy group needs to focus on during these tracks, work streams, and swim lanes.

Clarity Point

So why are they called "tracks" and not "phases," the word used by other frameworks and methodologies? It is an attempt to distinguish the fact that tracks are groupings of activities that, although they are started sequentially, might be completed quickly and run concurrently, as opposed to phases, which are more often associated with larger efforts and frequently need to be completed linearly before moving on to the next phase.

Enactment Tracks

Process enactment is the detailed sequence of steps by which a solution is defined, built, and deployed. The five overlapping enactment tracks are conceptually shown in Figure 6-6. Essentially, the enactment tracks help a team reach a high-level agreement on what is envisioned and create approach options to deliver on that vision (i.e., Envision Track); assess those options and plan out the selected option (i.e., Plan Track); build the solution (i.e., Build Track); make sure the solution is delivered as expected (i.e., Stabilize Track); and ultimately, deploy that solution (i.e., Deploy Track). From a simpler perspective, the enactment tracks are effectively: (1) think about what to do; (2) plan it out; (3) do it; (4) verify it was done right; and (5) wrap up.

Figure 6-6. Conceptual view of enactment tracks within MSF Governance Model

When you look at the enactment tracks from a time perspective, as exemplified in Figure 6-7, one track starts well before its predecessor track has finished. As depicted, multiple tracks of activity are running in parallel.

Figure 6-7. Enactment tracks splayed out over time

Figure 6-8 adds changes in risk, knowledge, and solution completion to this perspective. As shown, as a project proceeds, a solution moves ever closer to completion. A team's knowledge about a solution and how to deliver it increases. In addition, as more of a solution is built, typically the amount of risk decreases because riskier aspects of a solution should have been built in earlier releases. It is not intended to convey that the passage of time alone increases knowledge and drives down risk.

Figure 6-8. Conceptual view of MSF Governance Model applied to changes in risk, knowledge, and solution completion

Although all advocacy groups have specific responsibilities and deliverables for each track, their level of effort in each track varies. It is not that each advocacy group is not busy; it is just that the "spotlight" is on different advocacy groups at different times throughout the life cycle. For instance, solution architects are very busy defining a solution during a Plan Track, supporting a build team during a Build Track, and helping to troubleshoot a solution during the Stabilize and Deploy Tracks. So, for solution architects, their time in the spotlight is during planning. Table 6-1 contains a representative set of focal areas for each advocacy group across all tracks.

Table 6-1. Example of MSF Team Focal Areas for Each Enactment Track

Advocacy Group	Envision	Plan	Build	Stabilize	Deploy
Product Management	Overall goals Customer needs Requirements Vision/scope definition Customer acceptance criteria	Conceptual design Business requirements analysis Communications plan Requirements prioritization	Clarifying scope, requirements, and stakeholder expectations Market channels and sales aids	Communications plan execution Launch planning Scope trade-off prioritization	Customer feedback, assessment, signoff for each site deployment
Program Management	Project structure Project constraints Constraint trade-offs	Master project plan Master project schedule Functional specification management Budget	Project tracking Plan updating	Project tracking Constraint and scope trade-offs	Deployment plan and schedule updates Stabilization management
Architecture	Design goals and strategies Solution concept Feasibility analysis Build and technology options	Conceptual and logical design Technology evaluation Functional specification content Initial build estimates	Architectural validation Clarifying design details	Issue triage	Solution/scope comparison
Development	Build needs and strategies	Logical and physical design Build plan/schedule Build estimates Prototypes	Solution construction Infrastructure development Configuration documentation	Issue resolution Solution optimization	Issue resolution Escalation support
User Experience	User performance needs and implications User acceptance criteria	Usage scenarios/use cases User requirements Localization/accessibility requirements User documentation, training plans and schedules for usability testing Training	Training Usability testing Graphic design Support tools and manuals	User documentation stabilization Training materials User acceptance Usability assessments Training pilot users, operations, and support teams	Training User readiness
Test	Testing strategies, approach, and metrics	Design evaluation Testing requirements Test plan and schedule Test scenarios	Technology and limited functional testing Issues identification Documentation testing Test plan updates	Functional, system, and integration testing Issue reporting and status Configuration testing	Issue triage Deployment stabilization
Release/Operations	Deployment implications Operations management and supportability Operations acceptance criteria Qualities of service	Design evaluation Operations requirements Pilot and deployment plan and schedule Define and build various project environments	Rollout checklists Rollout and pilot plan updates Site preparation checklists	Pilot setup and support Deployments Operations and support readiness	Site deployment management Change approval

Governance Track

As mentioned earlier, MSF is designed to provide the right guidance to the right people at the right time (i.e., governance). As discussed in Chapter 12, "MSF Governance Track: Guiding the Solution Delivery," the Governance Track focuses on balancing efficient and effective use of project resources and delivery of a solution with adherence to a set of potentially changing project constraints. In addition, the Governance Track espouses continuous process improvement.

Work Streams and Swim Lanes

Most solution delivery approaches segment work into smaller and smaller work packages (e.g., activities), and ultimately into work items (e.g., tasks). However, there is a wide variance in what to call these groupings and the subteams performing the work. Whatever nomenclature or taxonomy is selected, it should be applied consistently across an organization. One common taxonomy is to segment activity into work streams and each work stream into swim lanes. Work streams are synchronized by using checkpoints but otherwise are independent, parallel efforts. Swim lanes tend to be within a subteam, and as such, it is up to teams to self-manage and synchronize. Keep in mind that, typically, work streams proceed at their own pace, and as such, checkpoints need to be structured to support this.

For example, a project involves three distinct domains of activity segmented into work streams: application development, infrastructure, and operational readiness. Because application development can be such a big area, it is often further segmented into functional-oriented swim lanes such as presentation layer, business logic layer, and database layer swim lanes; and/or capability-oriented swim lanes such as financial, messaging, and reporting.

It is that simple: segment the work into groups and assign it to teams so that it makes sense for an organization. For instance, the U.S. Army calls its progressively smaller teams: Army, Corps, Division, Brigade, Battalion, Company, Platoon, and finally, Squad. In this organization, team names have definitive meanings, work capacity, and attributes that are commonly understood throughout the organization.

Checkpoints

Checkpoints, a central theme in MSF, are used to plan and monitor project progress and call out completion of deliverables and activities. Checkpoints are used to provide explicit opportunities for a team and the customer(s) to reconfirm project scope, or adjust project scope to reflect changing customer or business requirements or to accommodate risks and issues that might materialize during the course of a project. Checkpoints are used for many reasons, namely, these:

• Help to synchronize work elements

• Provide external visibility of progress and quality

• Enable midcourse corrections

• Focus reviews on goals and deliverables

• Provide approval points of work before moving forward

Clarity Point

So, why are they called checkpoints instead of milestones? Same reason as given for why tracks are called tracks instead of phases. Checkpoints signify the conclusion of activities or a planned point during an activity to cross-coordinate with the team and with stakeholders. A milestone, sometimes called a toll gate, more often refers to a bigger or more formal event. As such, milestones are just one type of checkpoint. The real driver is that, within MSF, synchronizing with team members should be a regular event not to be shied away from because it is surrounded with pomp and circumstance.

MSF distinguishes between two types of checkpoints: major checkpoints and interim checkpoints. Major checkpoints mark the completion of major activities and major deliverables, including the end of planned activities for a given track. Interim checkpoints are defined by the team to indicate progress within a track and to segment large efforts into workable pieces.

Major Checkpoints

The alignment of team advocacy groups with each of the six major checkpoints clarifies which advocacy group is primarily responsible for achieving each checkpoint. Table 6-2 shows which advocacy groups drive each major checkpoint. This creates clear accountability. Although the completion of each checkpoint is driven by an advocacy group, all advocacy groups contribute in this achievement.

Table 6-2. Primary Driver for Each Major Checkpoint

Major Checkpoint	Marks Track Ending	Primary Driver
Vision/scope approved	Envision	Product Management
Project plans approved	Plan	Program Management
Scope complete	Build	Development
Release readiness approved	Stabilize	Test
Deployment complete	Deploy	Release/Operations
Customer acceptance	Governance	Product Management

Interim Checkpoints

Interim checkpoints vary depending on project type. In subsequent chapters, MSF provides a set of suggested interim checkpoints for each track. However, it is up to a team to adapt these checkpoints so they make sense for the project.

Defining interim checkpoints early on in a Plan Track helps to frame and focus team thinking when defining work packages without getting caught up in the details. Teams often have a strong sense of what needs to be accomplished but often struggle to identify tasks, schedules, and interim checkpoints. It is important not to worry about any dates at this time but instead to make sure the teams understand how their tasks and checkpoints interrelate. To help with this, a team maps out the logical relations using predecessor associations between the work streams and the swim lanes, as exemplified in Figure 6-9, which is an example of interim checkpoints for a Stabilize Track of a software development effort. Notice that the interim checkpoints are relative to each other and to the major checkpoints (e.g., Testing's 1st Pass Functional Testing Complete interim checkpoint occurs one week after Development's Code Complete major checkpoint). This way, it is clearly understood early on how teams rely on each other. Please note that the dates are included in the figure only for ease of understanding the figure.

Figure 6-9. Example of major and interim checkpoints for software Stabilize Track

Checkpoint Reviews

Each checkpoint provides an opportunity for learning and reflection through checkpoint reviews as well as an opportunity to review deliverables and synchronize expectations between customer, stakeholders, sponsors, and team. Checkpoint reviews used to identify and share lessons learned among a team are sometimes called postmortems or after-action reviews. These reviews are also occasions to gain agreement on project decisions, secure go/no-go decisions to move forward, or course-correct as needed.

For checkpoint reviews to be effective and valuable, open communications among the participants (e.g., project team, users, and stakeholders) must be established. As stated previously, open communications relies upon a no-blame culture.

Iterative Approach

How do you swallow an elephant?...One bite at a time.

An old adage

A solution does not provide business value until it is deployed into production and used effectively. For this reason, the life cycle of the MSF Governance Model includes incremental development and deployment of a solution into production, thereby ensuring realization of business value and of a team's overall strategic vision and goal(s). The combination of a strong multidimensional business representation on a team with explicit focus on impact to the business throughout the process is how MSF ensures that projects fulfill the promise of technology.

The practice of iterative development is a recurrent theme in MSF. Documents, designs, plans, and other deliverables are developed in an iterative fashion. As you would expect, the MSF Governance Model is an iterative approach. There are many highly compelling arguments across many disciplines for taking an iterative approach to solution delivery^[1]:

^[1] Sam Guckenheimer, Software Engineering with Microsoft Visual Studio Team System (Upper Saddle River, NJ: Addison-Wesley Professional, 2006), 30.

1. Risk management: If the desired result is not known in advance or the technology used is unproven, a solution should be incrementally implemented, starting with the highest risk elements, to prove or disprove the requirements and design assumptions.

2. Economics: In an uncertain business climate, it is important to review priorities frequently and treat investments as though they were financial options. The more flexibility gained through early payoff and frequent checkpoints, the more valuable the options.

3. Focus: People retain only so much information. By batching activities into small work packages, team members better grasp and deliver on the work at hand.

4. Motivation: The most energizing phenomenon on a delivery team is seeing users interacting with a solution, even if the solution is in a limited operational capacity.

5. Control theory: Small iterations allow a reduction in the margin of error for estimates and provide fast feedback about the accuracy of project plans.

6. Stakeholder involvement: Stakeholders see results quickly and become more engaged in a project, offering more time, insight, and funding.

7. Continuous learning: The entire team will learn and mature with each iteration, improving the accuracy, quality, and suitability of the finished solution.

Although delivery methodologies vary in how they approach iterative development, the concept of incrementally developing component parts to realize a solution is fundamental. An example of this concept for software development is shown in Figure 6-10. The elements of the iterative approach start with the individual (i.e., check-in) and incrementally roll up to a portfolio of projects to deliver a solution (i.e., program). Before talking about each of these elements in this figure, a few guiding principles regarding the MSF iterative approach are discussed next.

Figure 6-10. Elements of an iterative approach

Iterative Approach Fundamentals

The MSF iterative approach has two key guiding principles: creating living documents and baselining early and freezing late. Each of these is discussed next.

Create Living Documents

MSF project documents are "living documents" that are developed iteratively to keep documentation consistent with project changes. An example of a living project document is a planning document. Planning documents often start out as a highlevel "approach." These are circulated for review by the team and stakeholders during an Envision Track. As a project moves into a Plan Track, these are developed into detailed plans. Again, these are reviewed and modified iteratively. The types and number of these plans vary with the size of a project. To avoid confusion, planning documents that are started during an Envision Track are referred to as approaches. For example, a brief test approach is written during envisioning that evolves into a test plan in later tracks.

Baseline Early, Freeze Late

The phrase "baseline early, freeze late" literally means complete an activity as soon as possible to solicit feedback from others regarding output of that activity; but do not be too quick to declare the output final because project changes might alter the output. Basically, baselining is the end of the planned activity, and freezing is "last call" for changes after others have had a chance to validate the solution is what is needed and expected.

One way to instill this iterative approach in members of a team is to establish that every activity and deliverable taking longer than three days to complete needs to have iterative interim checkpoints, identified in Figure 6-11. As shown in the figure, shortly after starting a task or drafting a deliverable, the team responsible needs to get sign-off on task strategy or deliverable outline. Iterative interim drafts are submitted and reviewed as time permits. A team reaches a "completion" checkpoint when the team believes they finished their required work. Only after successfully passing a review, be it a peer review or formal review, is an effort baselined, meaning an independent group concurs that the team is complete. This marks the end of planned activity for that task or deliverable until such time that enough time has passed (sometimes months later) that there is little chance for additional change, and as such the effort is declared done (i.e., frozen checkpoint achieved).

Figure 6-11. Iterative task and deliverable life cycle

By completing and baselining project deliverables early in the process, team members are empowered to proceed with follow-on work without delay. By making the deliverable life cycle flexible by freezing checkpoints late within their corresponding tracks, changes are more likely to be accommodated. Note that the cost of this flexibility is paying careful attention to the change control process. It is essential to track changes and ensure that no unauthorized changes occur.

Check-In

Although a software development concept, the concept of check-in has universal appeal if you consider it an activity performed by a team member to deliver incrementally, at the lowest level, on his or her portion of a solution. It is a "public" acknowledgment of a degree of completion. For example, this could be a messaging engineer sharing a design draft among infrastructure peers. Work items are not checked in until they have a degree of completeness and correctness. Each check-in needs to progress a solution and not disrupt or "break" it. For example, software developers do not check-in code until they have validated that what they are checking works both as a component part of a solution and with the other component parts already checked in.

Daily Builds

MSF advocates frequent integration of all solution components for testing and review purposes, rather than waiting until the end of solution construction to do integration testing. This iterative approach enables maturity of the total solution to be well understood, with ample test data, before a solution is released into production.

Larger, complex projects are often split into multiple segments, each of which is developed and tested by separate subteams or feature teams, and then consolidated into the whole. In projects of this type, typical in Microsoft product development, the "daily build" approach is a fundamental part of the process. A build is a periodic assembly of all solution elements that are sufficiently complete to be included. Typically, core functionality of a solution or product is completed first, and then additional features are added. Development and testing occur continuously and simultaneously in parallel tracks. The daily build provides independent verification that all solution components are compatible and viable in a production-like environment, and enables the various subteams to continue their development and testing iterations. Builds that pass predetermined quality levels are called accepted builds.

Note that these iterative builds are not deployed in a live production environment. Only when builds are well tested and stable are they ready for a limited pilot (or beta) release to a subset of the production environment. Rigorous configuration management is essential to keeping these builds in sync.

Another advantage of daily builds is that they enable a team to mature their skills. This is especially needed for the nondevelopment roles (e.g., training role). These teams are dependent on the output of a build team to get their tasks and deliverables done. For instance, a deployment team uses frequent builds to hone their skills. Otherwise, there could be an unacceptable delay in portions of a solution (e.g., training material).

Clarity Point

Daily builds are not always done literally daily. In some approaches, they occur once a week as development starts, and the frequency increases as a project progresses. Toward the middle to end of an iteration, the frequency of builds could be continuouskicked off by each check-in. This is not to say that builds are pushed to a test environment continuously with each build. Builds are usually pushed to a test environment when the quality is sufficient.

Iteration

An iteration is a predetermined logical stopping point in a delivery life cycle. Typically, it is either a predetermined period (i.e., time-boxed; for example, 4 weeks), a predetermined set of features, or a predetermined capability. Regardless of approach, there is a predetermined level of quality that must be achieved. A graphical depiction of a set of iterations leading up to a release is provided in Figure 6-12.

Figure 6-12. Iterations leading to a release

Versioned Releases

MSF recommends that solutions be incrementally delivered by using versioned releases. A release is a bundling of solution features and capabilities so that it can be shared either internally among the team or externally with stakeholders. The initial release is typically a bundled set of core solution features and capabilities. Subsequent releases build upon prior releases by either adding new features and capabilities or adding onto the existing ones. This is known as a version release strategy. It is true that some small projects might need only one version. Nevertheless, it is a recommended practice to look for opportunities to break a solution into a multiple versions. Figure 6-13 conceptually shows versioned releases.

Figure 6-13. Example of versioned releases

As depicted in Figure 6-13, versioned releases are not necessarily developed linearly. Mature solution delivery organizations often have multiple version teams working with overlapping release cycles. The time between versions varies depending on the size and type of project, as well as customer needs and strategy.

Experience shows that versioned releases improve a team's relationship with the customer and ensure that the best ideas are reflected in a solution. It also shows that 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. Otherwise, they will overload the team with feature requests. Other benefits of using versioned releases include the following:

• Manages uncertainty and changes in scope

• Encourages continuous and incremental improvement

• Enables shorter delivery time

• Sets clear and motivational goals for team members

• Forces closure on project issues

• Minimizes risks by breaking large projects into multiple versions

Note that successfully implementing a versioned release strategy adds significant coordination overhead to an organization. For instance, scope and schedule must be coordinated across versions. The following are considerations for adopting versioned releases, each of which is discussed in subsequent sections:

• Create an incremental release strategy

• Deliver core functionality first

• Prioritize using risk-driven scheduling

• Cycle through iterations rapidly

• Establish configuration management

• Establish change control

Create an Incremental Release Strategy

Timeless wisdom recommends that the best way to approach accomplishing a large effort is to decompose it into smaller, more manageable parts (i.e., swallowing-the-elephant approach referenced earlier). Consistent with an iterative approach, an incremental release strategy describes how a solution will be delivered incrementally through a series of releases. This strategy maps out which components, features, functions, and services will be delivered in each release. It might contain a few alternate approaches.

Thinking beyond the current version enhances a team's ability to make good decisions about what to build now and what to defer. By providing a timetable for future feature development, a team is able to make the best use of available resources and schedule constraints, as well as to minimize unwanted scope expansion.

Deliver Core Functionality First

A basic, solid, and usable solution in the customer's hands is of more immediate value than a deluxe version that will not be available for weeks, months, or years. By delivering core functionality first, a team has a solid foundation upon which to build and benefits from customer feedback that will help drive feature development in subsequent iterations.

Prioritize Using Risk-Driven Scheduling

Risk assessment by a team identifies which features are riskiest. Based on experience, it is best to schedule the riskiest features for completion first. Problems requiring major changes to the architecture should be handled earlier in a project, thereby minimizing the impact on schedule and budget.

Cycle Through Iterations Rapidly

A significant benefit of versioning is that it quickly delivers usable solutions to the customer and improves the solutions incrementally. If this process stalls, customer expectations for continual solution improvement suffer. Maintain a manageable scope so that iterations are achievable within acceptable periods.

Establish Configuration Management

Configuration management is often confused with project change control, which is discussed next. The two are interrelated, but are not the same. Configuration management is the formalized tracking and controlling of the state of various project elements (e.g., deliverables and documents). These elements include version control for code, documentation, user manuals, and help files, schedules, and plans. It also includes tracking the state of hardware, network, and software settings of a solution. A team must be able to reproduce or "roll back" to an earlier configuration of the entire solution if needed.

Configuration management provides the baseline data that a team needs to make effective change control decisions. An example of configuration management is the recording of settings selected and tracking their changes as they are made during development and testing. For organizations using MOF, configuration management processes and procedures already used for operations should be adapted.

Establish Change Control

Once specifications are baselined, all features and functionality of a solution should be considered to be under change control. Change control is the process of requesting, reviewing, approving, documenting, and distributing changes. If a change is approved, it alters the scope of a solution. An example of change control is as follows. To conform to new government regulations, someone has proposed adding a new electronic data interchange (EDI) mapping schema. Key team members meet with sponsor(s) funding a project and members of the operations staff to review the proposed change, its technical risk, and impact on cost and schedule. After considering all impacts of the change, the approvers (typically called a change board) decide either to approve or disapprove the change. Note that disapproving the change can still leave it open for consideration in a later release of the solution.

It is essential that the customer and entire team understand the change control process. MSF does not prescribe a specific set of change control procedures. Procedures can range from simple to elaborate, depending on the size and nature of the project. However, effective change control must have the following elements:

• Features are not added or changed without review and approval by both the team and customer.

• To facilitate review, requests to change features are submitted in writing. This enables groups of change requests to be tracked. At Microsoft, these are known as design change requests (DCRs).

• Each feature request is analyzed for impact, feasibility, and priority. Dependencies with other features are considered, including user and operational documentation, training materials, and the operating environment.

• The impact on cost and schedule for each change request is estimated.

• Individuals (including the customer, program management, and some combination of stakeholders and other team members) to serve on a change control board to authorize changes are specified. Such a group takes many forms, as long as it is authorized to approve changes to cost, schedule, and functionality.

• Changes are tracked and made easy to access. For example, it is a good practice to maintain change requests and their respective status in a team collaboration site using tools such as the Microsoft SharePoint and Visual Studio Team Systems products.

• Change control requires effective configuration management to be effective.