IT consultants at large firms use a company-defined project methodology to ensure that each project covers all the right steps. The methodology specifies actual forms and reports to be used at various stages of the project and specific rules for how the project will be conducted.

But what if you’re an independent or work for a smaller firm? You could imitate the larger firms and develop your own project methodology at great expense. But why reinvent the wheel?

For the past six years, Microsoft has been developing and refining its own set of project management tools. Originally developed within Microsoft Consulting Services (MCS), the IT Lifecycle Frameworks are available for free on Microsoft’s Web site.

In this article, I’ll outline these frameworks, and I’ll also give an overview of the conceptual models that bind these two frameworks together.

First in a series on Microsoft’s IT Lifecycle Frameworks

This article discusses the development of Microsoft’s IT Lifecycle Frameworks, a series of best-practice processes and guidelines for IT-related projects. The next article will discuss Microsoft Solutions Framework in more detail to see how it can help you manage development projects more successfully.

The IT life cycle
Microsoft’s approach is to create separate frameworks focused on specific parts of the IT life cycle instead of using a single, generic methodology. Most companies already have elements of a methodology in place, said Neil Fairhead, Lead Product Manager for the frameworks at Microsoft.

Consultants who approach clients and insist that they use a complete, comprehensive methodology often causes “too much pain, too much cultural change,” for the client, Fairhead said.

Microsoft has built frameworks for two parts of the IT life cycle: building solutions and operating them.

The first framework they created was Microsoft Solutions Framework, or MSF. MSF contains the best practices that Microsoft’s own development teams use. Microsoft’s Web site contains a library of MSF white papers that outline its approach to application and infrastructure projects. For example, the site’s “Process of Risk Management” white paper is designed to help project managers maneuver around the common stumbling blocks in projects, while its “Team Model for Application Development” white paper outlines group dynamics used for team model application development.

Although the information is free, Microsoft also provides links on the same page that point users to its regional sales offices as well as to MSF-related training.

When Microsoft began putting together its Operations Framework, it found that many of its customers were using a widely used set of standards for managed IT services called the IT Infrastructure Library (ITIL), Fairhead said.

So Microsoft built the Microsoft Operations Framework (MOF) around ITIL (currently, British Standard 15000). Fairhead uses an analogy to describe ITIL and its relevance to MOF: ITIL is like a good, general auto mechanic who knows how to do just about anything with automobiles. But the best mechanic still needs a shop manual for a specific model of car. MOF, then, serves as the shop manual for operating Microsoft technologies in production.

As it does with the MSF, Microsoft offers a series of white papers and case studies outlining the MOF. (Microsoft’s Web site notes that it is preparing a three-day MOF essentials class, although the course is not in place as of yet.) Again, consultants more interested in Microsoft’s processes rather than contracting with the company can use this information at no obligation as a framework for client projects.

Common models tie the frameworks together
Both frameworks share a set of conceptual models that deal with the business side of managing a technical project:

  • The Process Model defines a versioned releases approach of phases and milestones. Instead of trying to accomplish all the project’s objectives at once, this general flow of activities is structured like a spiral: Each time around the circle represents one release that makes the solution more complete and more robust.
    In essence, each cycle takes you higher as well as around. Because building an IT solution is different from operating it in production, each of the two frameworks has its own version of the Process Model.
  • The Team Model creates a team of peers in which each member takes responsibility for one or more roles. “We didn’t think of the roles first,” says Derick Campbell, product manager for MSF. “We thought of the goals first: What are the common goals for any solution?”
    Roles were then created for each objective. Because each of the frameworks has different objectives, each has different roles. The frameworks also identify which roles can be combined in one team member and which must be dispersed among different team members.
  • The Risk Management Model is the same for both frameworks. The steps include identifying the risks, analyzing their likelihood and impact, creating plans for reducing the probability (prevention), and reducing the impact (mitigation). “Our focus has not been to reinvent risk management; our focus is to make it easy to apply,” Fairhead said.
    To this end, the two frameworks contain separate lists of known risks for each project type. Project managers can, in effect, pick which risks from the list apply to their project.

Bottom line
While many consulting firms do just fine with their own methodologies, Microsoft’s guidelines can provide a starting place for consultancies interested in revising their approach or those that need to build a methodology from the ground up.

Do you use third-party guidelines for your projects?

Do you use guidelines for IT projects other than those you’ve developed in-house? Do you confer with your clients when using such methodologies? Send us your comments in an e-mail or in a discussion below.