How to deliver successful IT projects using MSF team model and MSF process model


According to Standish Group, IT project failure rates are still very high with only 29% of projects delivered successfully (53% of all projects are challenged and 18% fail completely). But creating meaningful solutions on-specs, on-time and on-budget requires a proven approach. Microsoft® Solutions Framework (MSF) is a deliberate and disciplined approach to technology projects based on a defined set of principles, models (Team & Process models), disciplines (Project, Risk, and Readiness Management disciplines), concepts, guidelines, and proven practices. This presentation introduces MSF and provides an overview of MSF's foundational principles, core models, and essential disciplines, focusing on how their application contributes to the increase of success of technology projects. MSF focuses on successfully delivering IT solutions faster, with fewer people, and involving less risk, while enabling higher quality. The MSF project life cycle is using five phases: 1) Envision, 2) Planning, 3) Developing, 4) Stabilizing and 5) Deploying. MSF Team Model uses six distinct roles on organizing people: 1) Program, 2) Product, 3) Development, 4) Testing, 5) User Experience and 6) Release Management roles. Finally, this presentation provides references for further information about MSF and references for guidance in implementing MSF within organizations.


IT departments, technology organizations and Information systems (hereafter referred to as “IT organizations”) have been frustrated by the time and effort it takes to develop and deploy business-driven solutions based on evolving technology. IT organizations are aware of the negative impact and unacceptable business risks that poor quality results incur. Trying to do their work better, IT organizations seek guidance from the industry because technology development and deployment projects can be extremely complex. Technology alone can be a factor in project failures; however, Jim Johnson, CEO at the Standish Group, in The Right Business Use of Things Technical, states that: “when a project fails, it hardly ever fails for technical reasons”. More and more people now believe that a successful project outcome is related mostly to the people and processes involved rather than to the complexity of the technology itself.

When processes and people are not working well, the following effects on projects can be observed: 1) Poor Stakeholder management, 2) Insufficient business requirements, 3) misunderstood business problems, 4) poor quality etc. Organizations that overcome these issues increase dramatically project success rates and derive better results for their business through higher product/service quality, improved customer satisfaction, and working environments. These factors translate into a positive impact on bottom lines and improvements in the organization's strategic effectiveness.

MSF has been evolving since 1993 and is based on successful, real-world best practices from Microsoft product groups, Microsoft Services, Microsoft partners, Microsoft's internal IT Group, and customers. 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.


What are the obstacles in IT projects?

The obstacles on almost all IT projects are mainly the following:

  • Separation of goal and function
  • Separation of business and technology
  • Lack of common language and process
  • Unclear goals
  • Unmanaged scope changes
  • Failure to communicate and act as a team
  • Unclear team roles
  • Processes that are inflexible to change

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.

Alice: Would you tell me please, which way I ought to go from here?
Cat: That depends a good deal on where you want to get to.
Alice: I don't much care where…
Cat: Then it doesn't matter which way you go.

What MSF stands for?

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.

In Microsoft Solutions Framework Essentials, (Microsoft Corporation, 2002, p. 8) MSF is defined as:

“MSF offers guidance
in how to organize people and projects
to plan, build, and deploy
successful IT solutions!”

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.

  • Adaptable: MSF is more like a compass, not prescriptive methodology, usable anywhere, than a map, the usefulness of which is limited to a specific place.
  • Flexible: MSF applied to a specific customer's environment and technology scenario can become more methodological for that customer. Certain MSF concepts, for instance the MSF team model, can be applied within the established hierarchy of an existing organization.
  • Scalable: MSF can accommodate teams as small as 3 people and projects with more than 50 people.
  • Technology agnostic: MSF is not technology specific and can be used to deliver solutions based on any technology.

MSF Foundational Principles

At the core of MSF, there are 8 foundational principles:

  1. Foster open communications
  2. Work toward a shared vision
  3. Empower team members
  4. Establish clear accountability and shared responsibility
  5. Focus on delivering business value
  6. Stay agile, expect change
  7. Invest in quality
  8. Learn from all experiences

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.

Foster Open Communications

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.

Work Toward a Shared Vision

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.

Empower Team Members

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.

Establish Clear Accountability and Shared Responsibility

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.

Focus on Delivering Business Value

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.

Stay Agile, Expect Change

Traditional project management approaches and “waterfall” solution delivery process models assume a level of predictability that is not as common on technology projects as it might be in other industries. Often, neither the outcome nor the means to deliver it is well understood, and exploration becomes a part of the project. The more an organization seeks to maximize the business impact of a technology investment, the more they venture into new territories. This new ground is inherently uncertain and subject to change as exploration and experimentation results in new needs and methods. To pretend or demand certainty in the face of this uncertainty would, at the very least, be unrealistic and, at the most, dysfunctional.

MSF has designed both its Team and Process models to anticipate and manage change. The MSF Team Model fosters agility to address new challenges by involving all team roles in key decisions, thus ensuring that issues are explored and reviewed from all critical perspectives. The MSF Process Model, through its iterative approach to building project deliverables, provides a clear picture of the deliverable's status at each progressive stage. The team can more easily identify the impact of any change and deal with it effectively, minimizing any negative side-effects while optimizing the benefits.

Invest in Quality

The MSF Team Model holds everyone on the team responsible for quality while committing the Test role to managing the processes of testing. This role encourages the team to make the necessary investments throughout a project's duration to ensure that the level of quality meets all stakeholders' expectations. In the MSF Process Model, as project deliverables are progressively produced and reviewed, testing builds in quality - starting in the first phase of the project life cycle and continuing through each of its five phases. The model defines key milestones and suggests interim milestones that measure the solution against quality criteria established by the team, led by the Test Role, and stakeholders. Conducting reviews at these milestones ensures a continuing focus on quality and provides opportunities to make midcourse corrections if necessary.

An essential ingredient for instilling quality into products and services is the development of a learning environment.

Learn from All Experiences

In My Life Is Failure: 100 Things You Should Know to Be a Successful Project Leader, (Standish Group International August 2006), Martin Cobb, Treasury Board of Canada Secretariat, Ottawa, Canada, outlined his paradox: “We know why projects fail, we know how to prevent their failure -- so why do they still fail?” When you look at the marginal increase in the success rate of technology projects and when you consider that the major causes of failure have not changed over time, it would seem that as an industry we are failing to learn from our failed projects. Taking time to learn while on tight deadlines with limited resources is difficult to do, and tougher to justify, to both the team and the stakeholders. However, the failure to learn from all experiences is a guarantee that we will repeat them, as well as their associated project consequences.

Capturing and sharing both technical and non-technical best practices is fundamental to ongoing improvement and continuing success because it:

  • Allows team members to benefit from the success and failure experiences of others.
  • Helps team members to repeat successes.
  • Institutionalizes learning through techniques such as reviews and retrospectives.

MSF assumes that keeping focus on continuous improvement through learning will lead to greater success. Knowledge derived from one project that then becomes available for others to draw upon in the next project will decrease uncertainty surrounding decision-making based on inadequate information. Planned milestone reviews throughout the MSF Process Model help teams to make midcourse corrections and avoid repeating mistakes. Additionally, capturing and sharing this learning creates best practices from the things that went well.

MSF emphasizes the importance of organizational- or enterprise-level learning from project outcomes by recommending externally facilitated project postmortems that document not only the success of the project, but also the characteristics of the team and process that contributed to its success. When lessons learned from multiple projects are shared within an environment of open communication, interactions between team members take on a forward, problem-solving outlook rather than one that is intrinsically backward and blaming.

Building an MSF Team

The MSF Team Model represents the compilation of industry best practices for empowered teamwork and technology projects that focus on achieving these goals. They are then applied within the MSF Process Model to outline activities and create specific deliverables to be produced by the team. These primary quality goals both define and drive the team. MSF team model uses the following 6 roles or hats (Exhibit 1):

MSF Team model

Exhibit 1 – MSF Team model

Note that one role is not the same as one person—multiple people can take on a single role, or an individual may take on more than one role—for example, when the model needs to be scaled down for small projects. What's important in the adoption of the MSF Team Model is that all of the quality goals should be represented on the team and that the various project stakeholders should know who on the team is accountable for them. The MSF Team Model explains how this combination of roles can be used to scale up to support large projects with large numbers of people by defining two types of sub-teams: function and feature. Function teams are unidisciplinary sub-teams that are organized by functional role. The Development Role is often filled by one or more function teams. Feature teams, the second type, are multidisciplinary sub-teams that are created to focus on building specific features or capabilities of a solution.

The MSF Team Model is perhaps the most distinctive aspect of MSF. At the heart of the Team Model is the fact that technology projects must embrace the disparate and often juxtaposed quality perspectives of various stakeholders, including operations, the business, and users. The MSF Team Model fosters this melding of diverse ideas, thus recognizing that technology projects are not exclusively an IT effort. Test and development roles are internal to the project and the remaining roles are external (Exhibit 2).

Internal & External roles

Exhibit 2 – Internal & External roles

The MSF Process Model

Every project goes through a life cycle, a process that includes all of the activities in the project that take place up to completion and transition to an operational status. The main function of a life cycle model is to establish the order in which project activities are performed. The appropriate life cycle model can streamline a project and help ensure that each step moves the project closer to successful completion. A simple view of the MSF Process Model life cycle is shown below (Exhibit 3).

MSF Process Model

Exhibit 3 – MSF Process Model

The MSF Process Model combines concepts from the traditional waterfall and spiral models to capitalize on the strengths of each. The Process Model combines the benefits of milestone-based planning from the waterfall model with the incrementally iterating project deliverables from the spiral model.

MSF Disciplines

The MSF disciplines are areas of practice that employ a specific set of methods, terms, and approaches. MSF uses the following 3 disciplines:

The MSF Project Management Discipline

MSF has a distributed team approach to project management that relates to the foundational principles and models stated above. In MSF, project management practices improve accountability and allow for a great range of scalability from small projects up to very large, complex projects. The MSF Project Management Discipline embraces and is broadly aligned with the major project management bodies of knowledge within the domain of technology projects. This includes the Project Management Institute (PMI®), the International Project Management Association (IPMA), and Prince2™ (PRojects in Controlled Environments).

The MSF Risk Management Discipline

Whereas many technology projects fail to effectively manage risk or do not consider risk management necessary for successful project delivery, MSF uses risk management as an enabler of project success. MSF views risk management as one of the MSF disciplines that needs to be integrated into the project life cycle and embodied in the work of every role. Risk-based decision making is fundamental to MSF. And by ranking and prioritizing risks, MSF ensures that the risk management process is effective without being burdensome.

The MSF Readiness Management Discipline

The Readiness Management Discipline defines readiness as a measurement of the current versus the desired state of knowledge, skills, and abilities (KSAs) of individuals in an organization. This measurement concerns the real or perceived capabilities of these individuals at any point during the ongoing process of planning, building, and managing solutions. The MSF Readiness Management Discipline limits its focus to the readiness of project teams. It provides guidance and processes for defining, assessing, changing, and evaluating the knowledge, skills, and abilities necessary for project execution and solution adoption.


MSF is a deliberate and disciplined approach to technology projects based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft. MSF team model describes the 6 roles or “hats” that team members wear. MSF Process model uses 5 phases (Envision, Plan, Develop, Stabilize and Deploy) embracing both waterfall and spiral models.


Biro T. and Kiss S. (May 14, 2003) The Right Business Use of Things Technical Retrieved on January 10, 2007 from

Block, P. (1987) The Empowered Manager, San Francisco, CA: Jossey-Bass Inc.

Boehm, B. (May 1988) A Spiral Model of Software Development and Enhancement, IEEE Computer.21(5) 61-72.

Brooks, F. (1995) The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Upper Saddle River, NJ: Addison-Wesley.

DeMarco, T. & Lister, T. (1998) Peopleware: Productive Projects and Teams, New York, NY: Dorset House

McConnell, S. (1998) Software Project Survival Guide, Redmond, WA: Microsoft Press,

Highsmith, J. (October 2002) What Is Agile Software Development? CrossTalk, 4

Johnson, J. (August 2006) My Life Is Failure: 100 Things You Should Know to Be a Successful Project Leader, Standish Group International

Larson, C. & LaFasto F. (1989) Teamwork: What Must Go Right/What Can Go Wrong, Sage Publications, 55

McCarthy, J. & McCarthy, M. (2002) Software for Your Head, New York, NY: Addison-Wesley, 273,277

Microsoft (2002) Microsoft Solutions Framework Essentials, Redmond, WA: Microsoft Corporation

Turner, M. (2006) Microsoft Solutions Framework Essentials: Building Successful Technology Solutions, Redmond, WA: Microsoft Press

Peters, T. (1987) Thriving on Chaos, First Harper Collins Publishers

Project Management Institute (2000) The PMI Fact Book, 2nd Edition, Newtown Square, PA: Project Management Institute

Royce, W. (August 1970) Managing the Development of Large Software Systems, Proceedings of IEEE, 1-9

Santayana, G. (1981) The Life of Reason, (vol. 1) New York, NY: MacMillan Pub Co.

Senge, P. (1994) The Fifth Discipline: The Art and Practice of the Learning Organization, Doubleday & Company

Senge, P., Roberts C., Ross, R., Kleiner, A., & Roth G. (1994) The Dance of Change: The Challenges of Sustaining Momentum in a Learning Organization, New York, NY: Doubleday & Company

The Standish Group International (2005), Extreme Chaos, The Standish Group International, Inc.

Stross, R. (1997), The Microsoft Way: The Real Story of How the Company Outsmarts Its Competition, New York, NY: Perseus Publishing.

© 2007, Theofanis C. Giotis
Originally published as a part of 2007 PMI EMEA Global Congress Proceedings – Budapest, Hungary



Related Content

  • Project Management Journal

    Getting Past the Editor's Desk member content locked

    By Klein, Gary | Müller, Ralf To reach acceptance, every research paper submitted to Project Management Journal® (PMJ) must pass several hurdles. This editorial aims to declare the editorial process and reveal major reasons for…

  • Project Management Journal

    Narratives of Project Risk Management member content locked

    By Green, Stuart D. | Dikmen, Irem The dominant narrative of project risk management pays homage to scientific rationality while conceptualizing risk as objective fact.

  • Project Management Journal

    Coordinating Lifesaving Product Development Projects with no Preestablished Organizational Governance Structure member content locked

    By Leme Barbosa, Ana Paula Paes | Figueiredo Facin, Ana Lucia | Sergio Salerno, Mario | Simões Freitas, Jonathan | Carelli Reis, Marina | Paz Lasmar, Tiago We employed a longitudinal, grounded theory approach to investigate the management of an innovative product developed in the context of a life-or-death global emergency.

  • Project Management Journal

    Investigating the Dynamics of Engineering Design Rework for a Complex Aircraft Development Project member content locked

    By Souza de Melo, Érika | Vieira, Darli | Bredillet, Christophe The purpose of this research is to evaluate the dynamics of EDR that negatively impacts the performance of complex PDPs and to suggest actions to overcome those problems.

  • Project Management Journal

    Navigating Tensions to Create Value member content locked

    By Farid, Parinaz | Waldorff, Susanne Boche This article employs institutional logics to explore the change program–organizational context interface, and investigates how program management actors navigate the interface to create value.