Introduction

Successfully delivering solutions, any solutions, involves an ever-changing blend of skill, wisdom, luck, and often technology. Too many times, teams focus just on technology. This book is an attempt to quantify, simplify, and enable those other componentsyes, even luck. The book is a result of my belief that a team can increase their odds of success on all fronts through thoughtful and reflective application of Microsoft Solutions Framework (MSF).

This book describes and explains the Microsoft Solutions Framework (MSF)a collection of key concepts, foundational principles, and proven practices from Microsoft and from dedicated and passionate practitioners around the world. They are an amazing bunch, continually looking to improve and streamline how teams deliver solutions. It is an honor to write this book on their behalf.

Who Should Read This Book

This book was written for any team or organization, technical or nontechnical, that is looking for some commonsense guidance on how to deliver solutions successfully. This book is not for a particular role on a team; it is meant to stimulate thinking of all team members. Hopefully, the team will come away with a common taxonomy and common understanding of the foundational elements needed to have a successful team, project, and solution.

How to Apply the Information in This Book

If a team or organization lacks the fundamentals of solution delivery, it would be detrimental for a team to try to implement all aspects discussed herein. It is better to pick out a few implementable aspects and achieve a few successes. Then reread this book and, from your new vantage point, pick out a few more implementable aspects, whether you choose to improve existing ones or adopt new ones.

If a team is having issues in a few aspects of their solution delivery approach, read the whole book to get an overall understanding of the concepts. Then revisit those trouble areas with an eye toward process improvement ideas.

What Essentials Have Changed with MSF v4?

Although the fundamentals have mostly remained the same, Microsoft is refreshing MSF to clarify and adapt terms and concepts to be more understandable to a broader, global audience. Key changes, additions, clarifications, and enhancements to MSF v3 are highlighted in the following section. Please note that these concepts are discussed in detail in subsequent chapters.

Changed

Key changes to MSF v3 that are implemented in MSF v4 have been in the following areas:

• Foundational principles

• Key concepts

• Team Model

• Process Model

A few miscellaneous changes are also highlighted.

Foundational Principles

The following summary maps the principles currently found in MSF v4 to those currently in MSF for Agile Software Development and MSF for CMMI Process Improvement as well as in MSF v3. In some instances, a couple principles have been merged or recast as a key concept (now called mindsets).

MSF v4 Principle	Agile and CMMI (v1)	MSF v3
Foster open communications	Same	Same
Work toward a shared vision	Same	Same
Stay agile, expect and adapt to change	Stay agile, adapt to change	Stay agile, expect change
Invest in quality	Quality is everyone's business, every day (This applies to an individual's behavior and is therefore a mindsetmerged into pride in workmanship mindset.)	Same
Partner with customers	Same	New
Deliver incremental value	Flow of value: incremental delivery of value Make deployment a habit: implies team readiness Frequent delivery	Always create shippable solutions: implies solution readiness
Make mindset		Focus on business value: make sure what is being delivered has value (This applies to an individual's behavior and is therefore a mindset.)
Empower team members	New	Same
Establish clear accountability and shared responsibility	New	Same
Learn from all experiences	New	Same

Key Concepts

Key concepts have been renamed as mindsets, but they are still key concepts. To help clarify the difference between a principle and a key concept, and especially because these concepts apply to individual behavior, calling them mindsets seems to represent better that understanding. As with the prior table, the following summary maps the mindsets in MSF v4 to those currently found in MSF for Agile Software Development and MSF for CMMI Process Improvement as well as in MSF v3.

MSF v4 Mindset	Agile and CMMI (v1)	MSF v3
Foster a team of peers	Same	Extended to include trust. Trust is essential for many of the aspects of MSF to work properly.
Focus on business value	Quality is defined by customer: "Everyone on the team should be...focused on delivering something that the consumers need, want, and will derive value from."	Transferred from principles and merged with: Customer-focused
Keep a solution perspective	New	Solution mindset
Take pride in workmanship	Pride of workmanship Quality is everyone's business, every day (transferred from principles)	Quality mindset Zero-defect mindset
Learn continuously	Willingness to learn	Willingness to learn
(Merged into deliver incremental value principle)	Frequent delivery
(Moved to proven practices)	Get specific early
Internalize qualities of service	Qualities of service	Design principles, but there needs to be more awareness so it needs to be internalizedtoo often considered after design is done
Practice good citizenship	Same	New
Deliver on your commitments	New	Fixed ship date: Stimulate creativity by removing the option of moving the ship date

Team Model

A very welcome change is that role clusters remain. To help emphasize that the Team Model has always been about advocating for different aspects of delivering a solution and for their respective stakeholders, role clusters were renamed to advocacy groups.

As we reexamined the model, it made sense to make the most significant change to MSF Team Model, namely, adding an Architecture Advocacy Group. This group should seem familiar because most of the relevant aspects of this group were extracted from the Program Management Advocacy Group and the Development Advocacy Group.

The Release Management Role Cluster was renamed to Release/Operations Advocacy Group. This change was made to emphasize the critical need for the solution delivery team to be closely coupled with the Solution Operations team. Because not all solutions are deployed to an operations environment, the term release was retained in the name.

As part of reexamining the Team Model, we clarified and expanded the functional areas within each advocacy group. Added to this, we clarified, distilled, and expanded some of the key responsibilities and activities of each of the functional areas.

Process Model

The MSF v3 Process Model underwent the most change. Although the underlying concepts have remained the same, it made sense to separate the process and activities of building a solution (i.e., enactment) from the process and activities of running a project (i.e., governance). As such, Process Model was renamed Governance Model.

Other changes were made to help emphasize the agile, overlapping, and iterative nature of MSF v3. Namely, the five phases are now call tracks (e.g., Plan Track)as in tracks of activity. To emphasize that MSF v3 has always had a broader applicability to more than just the software development domain, the Developing Phase was renamed Build Track. Although the term milestone is commonly used in project management circles, to emphasize the agile nature of MSF v3, the term checkpoints is used instead. The Governance Model still has major and interim checkpoints.

The Process Model was changed somewhat to better emphasize the iterative name of MSF v3. For instance, some clarity was added about decomposing the major tracks of activity into work streams and further still into swim lanes.

Miscellaneous Changes

A few miscellaneous but important changes are as follows. The term defects has been replaced with issuesa term more fitting our litigious society. To emphasize the applicability of MSF v3 beyond software development, the term bug has also been replaced by issue. Accordingly, the two bug-related interim checkpoints have been renamed. The Zero Bug Bounce checkpoint has been renamed Issue Log Cleared. The Bug Convergence checkpoint has been renamed Issue Convergence. In the Build Track (formerly called the Developing Phase), the Proof of Concept Completed interim checkpoint was renamed Prototyping Completed to better reflect that not all projects include a proof of concept; however, most do include prototyping efforts.

New

A few key elements have been added to MSF v4 that often build off of or clarify a topic lightly covered in MSF v3, namely, the following:

• Scheduling process

• Risk mitigation trigger

• Empowerment readiness

• Requirement prioritization

• Governance track

Scheduling Process

Although not new for the project management community, an approach to scheduling that reflects the MSF principles and mindsets has been added into MSF v4. The real value of this section is the numerous lessons learned that accompany the explanation of this process.

Risk Mitigation Trigger

Although not a common practice in the project management community, it is a practical addition to MSF v4. It enables more options for a cost-conscious approach to risk mitigation.

Empowerment Readiness

MSF continues to be a strong proponent of empowering team members. However, not all team members are ready or able to be empowered. Empowerment readiness is a means added into MSF v4 to assess the degree to which each team member is ready to be empowered to perform a given task.

Requirement Prioritization

New with MSF v4 are a few sections discussing requirements prioritization. Examples of a simple means to prioritize as well as a more comprehensive means are provided.

Governance Track

As identified in the changes to the Process Model section, MSF v4 has a new track of activity, namely, the Governance Track. This track of activity spans the enactment tracks (e.g., Envision Track) to provide guidance on running the project.

Significant Clarifications and/or Enhancements

Many aspects of MSF v3 have been clarified and/or extended. A few key aspects of note include these:

• Readiness Management Discipline and Process

• Risk Management Discipline and Process

• More projects plans for Master Project Plan

• Supporting environments: more than just development and test environments

• Stakeholder analysis

• Defining high-level requirements

• Decomposing and refining requirements

• Added qualities of service (QoS) requirements

• Acceptance criteria: user, operations, and customer

• Clarified differences between conceptual, logical, and physical designs efforts

• Types of testing: regression, functional, usability, system

Help Evolve MSF

This book is a snapshot of a changing and evolving body of knowledge and practices. You are welcome to contribute to this body of knowledge. Go to http://www.microsoft.com/msf for general MSF information and tools. Additional MSF communities, resources, and services are available at http://www.NorthStarAnalytics.com/msf.

Training

Microsoft and its certified training partners offer an array of MSF classes, including a course based on MSF Essentials. Please visit the following Web site for more information:

http://www.microsoft.com/learning/training/

Support for This Book

Every effort has been made to ensure the accuracy of this book. As corrections or changes are collected, they will be added to a Microsoft Knowledge Base article.

Microsoft Press provides support for books at the following Web site:

http://www.microsoft.com/learning/support/books/

Questions and Comments

If you have comments, questions, or ideas regarding this book, or questions that are not answered by visiting the sites above, please send them to Microsoft Press by sending an e-mail message to

[e-mail]

or by sending postal mail to

Microsoft Press
Attn: Microsoft Solutions Framework Essentials Editor
One Microsoft Way
Redmond, WA 98052-6399