CXO

Microsoft Solutions Framework can keep projects and team members on track

Making sure that everyone on your application development project has a stake in its success can mean the difference between delivering the goods and missing the mark. Here's a look at how Microsoft Solutions Framework can help.


All project managers have two shared memories of development efforts they’ve tried to wrangle: the many hats they had to wear and an eerie sense of “winging it” as the projects unfolded.

Sometimes you can get away with this freewheeling approach, but far too often, you don’t. In fact, an often-quoted, six-year-old report by The Standish Group, an IT research firm, estimates that only 16 percent of IT projects are fully successful—on time, on budget, and in scope. When projects fail, it’s usually due to people and process issues, not the technology.

One method that consultants and project managers can use to up their own batting average is Microsoft Solutions Framework (MSF), a structured approach to managing development projects that uses both team and process models.

Here’s a closer look.

Second in a series
This is the second of a three-part series on Microsoft’s IT Lifecycle Frameworks. In the first article of this series, we examined Microsoft’s IT Lifecycle Frameworks in general along with its underlying models. The final article of the series will describe Microsoft's Operations Framework.

Peer pressure
MSF’s Team Model calls for approaching projects using teams of peers. There is no single team member who is “the boss.”

Instead, each member has responsibility for one or more roles, which are in turn tied to objectives for the project, said Neil Fairhead, lead product manager for the frameworks at Microsoft.

When one person leads a project, the objective most important to the leader tends to dominate the project, Fairhead said. But if each objective is represented by separate roles, he added, different viewpoints have a voice in the completed solution, he said. “Either everybody succeeds or everybody fails, so there’s a terrific peer pressure to perform,” Fairhead said.

With each member having a stake in the project’s success, the peer pressure model also leaves little doubt about who is responsible for a given task. This team makeup prevents tasks from falling between the cracks, said Derick Campbell, product manager for MSF. “It’s not at all like looking at one person and saying, ‘Tell me what to do,’“ Campbell said.

Roles and goals
The MSF Team Model specifies six roles:
  • Product Management keeps in close contact with customers (whoever is paying for the project), both to inform them of progress and also to learn of changes in the business needs and requirements. Product Management’s goal is to satisfy the customer.
  • Program Management is responsible for the budget and schedule, often considered the traditional responsibilities of project managers.
  • Logistics Management focuses on making the solution easy to deploy and manage on an ongoing basis. 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. “You want to treat every developer hour like a diamond,” Campbell says. Everything you can remove from developers’ plates shortens the critical path. Developers are tasked with making sure the solution meets specifications.
  • Testing ensures that the solution isn’t released until all issues are known and addressed. To keep the overall project moving, it’s important to understand that testing has a different perspective than the development role. Campbell put it this way: "To a developer, a successful test is one that passes; to a tester, it’s one that finds a bug."
  • User Education represents the interests of end users, making sure the solution actually increases their productivity.

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 MSF Process Model
If the Team Model keeps you from wearing too many hats, the Process Model makes the need to “wing it” less common. The model relies on “versioned releases” to complete a large project via multiple cycles, each returning value to the customer while remaining manageable in scope.

The model’s four phases are each terminated by a definite, measurable milestone.
  1. 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.
  2. The Planning phase creates functional specifications for a version/release (one cycle), a new or updated master project plan, and a new or updated master project schedule. The associated milestone is Project Plan Approved, which equates to customer approval to tackle the project as outlined.
  3. 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.
  4. The Stabilizing phase starts with beta testing and ends with customer approval and release to operations.

Information gathered in all four phases of this cycle is then fed into the Envisioning phase for the next release/version.

Certification is also available
Microsoft also offers MSF-related training for consultants, project managers, or others interested in finding out more about MSF. To learn more, visit Microsoft’s Web site.

What you get out of it
The MSF process model offers several potential advantages. If you’ve used the traditional “waterfall” style of project management, you’ve probably noticed that making changes without affecting the overall schedule can be tough. Because MSF’s Project Model uses “versioned releases,” development teams can accommodate changes in customer requirements because each cycle allows customer and development teams to negotiate which features will be implemented in the release.

In addition, milestones with fixed dates can provide structure to a release cycle and motivate each team member to deliver their part on time.

What are the benefits and drawbacks of "waterfall" and "spiral" methods of development?
Which method do your clients use most? Does it incorporate elements of each or stick to a “pure” method? Send us your comments in an e-mail or in the discussion below.

 

Editor's Picks

Free Newsletters, In your Inbox