The Microsoft Solutions Framework is a comprehensive collection of best practices derived from over 20 years of software development and deployment experience at Microsoft. Taken together, it supplies answers to three categories of questions:
1. How should teams be structured?
2. How should tasks be selected and sequenced?
3. How should the inherent risks of the process be managed?
In this continuing series of articles, we share ideas for successful implementation and adaptation of MSF gathered from the experience of C2 Consulting and the Technical Consulting Skills Institute.
The MSF Process Model helps teams think about, select and sequence tasks that build to meet a project goal. The phases of the Process Model are:
- Envisioning
- Planning
- Developing
- Stabilizing
Most of the ideas below apply primarily to the Envisioning phase, but may need to be considered at later phases of the project.
Give the Team Time to Get Clear on Their Roles and Processes
The Envisioning phase of the Process Model culminates in the acceptance of the common vision. This vision encompasses a number of dimensions of project success. They include:
- The goal of the project
- The roles of the team members
- The inherent risks of the process
- How the team members will interact with each other
- How the team members will interact with the outside world
- What are the next steps to take in completing the project
To summarize, the Envisioning phase is all about resolving team ambiguity. Why are we here? What are we going to accomplish? What’s my part? How do we know who’s in and who’s out? How are we going to proceed? Etc.
If a new team fails to answer these questions, they may be unable to proceed. If they can continue, the unresolved ambiguity will usually be expressed later in the project with potentially disastrous results.
One of the great challenges of the Envisioning phase is that the work may not appear from the outside to be productive. In fact, it may not appear productive from the inside either. The team may feel as if they were afloat on the sea as they struggle to resolve the ambiguity of how to proceed. This is normal and necessary.
The amount of time required to establish the team will vary based on a number of factors including the experience level of the team members, their familiarity with their roles, their level of experience with the self managed team concept, and the degree of adjustment required to adapt from their previous organizational culture.
The team must be allowed to work through this period. Failing to do so will result in much wasted effort and emotion (in all but the most simple projects).
Get Total Buy-In From the Team for the Vision
Achieving the buy-in from the team and the client to the common vision represents the conclusion of the Envisioning phase. It does not mean that the team members have grudgingly accepted their direction. It means that each member has emotionally committed to the success of the project and the definition of that success.
Attempting to artificially force the conclusion of the Envisioning phase is a temptation, but a mistake. Although it is difficult to perceive the long-term value of gaining buy-in, failure to do so can set the project up for disaster later in the process. The types of dysfunctions that develop later may include stress on the team members or schisms in the team as differing definitions of success take are expressed. It may also include missed deadlines and team apathy in the absence of real commitment to meeting the dates or meeting the client needs.
Reorient the Team to the Nature of Their Work
Each of us has been socialized into a particular business culture. We bring our assumptions about the nature and value of work from our families, our formal education, our friends, and our early work experiences. Given that the nature of knowledge work is fundamentally different from physical or industrial work, it is common to feel that we are not doing “real work” during many of the phases of intellectual property creation or deployment.
Software developers are particularly susceptible to discomfort when they feel that they are not making progress. It is common for them to feel, “If I’m not coding, I’m not working.”
People need help becoming accustomed to the nature of work in development and deployment projects. In fact, seeing the MSF Team Model for the first time can be a revelation for some. Discovering that each of the non-development teams has real, valuable work to do can be a real eye-opener. Refusing to believe that the non-development groups are actually working can be a career-limiting and project-destroying bias.
Helping people understand that not all meetings are a waste of time and that writing specifications is not just taking time away from valuable coding is an important part of empowering a team to effectively manage itself.
Resist the Temptation to Step In
The final piece of advice for this article goes out to clients and managers responsible for overseeing MSF project teams. Especially the first time supervising or employing these types of teams, the impulse to step in and intervene at the first sign of trouble can be almost overwhelming. The advicedon’t.
The damage that will be done to not only the project team, but also the organizational culture may be unrecoverable. At best, it will be a long time before a successful attempt at team empowerment can be tried again.
The reason for this lies in the ways groups learn. In many ways, groups learn to respond to their environment as children do. If they learn that they can make mistakes and recover from them on their own, the belief in their independence and ability will be reinforced. If a supervisor steps in as soon as problems develop, the unconscious message is clear. “You are not trusted to understand or fix your problems. You are incapable of this level of work.” Groups treated this way will become passive and dependent on supervision. This sort of cultural assumption undermines all the power of the MSF Team Model.
As you get more experience applying the teaming, process and risk principles of MSF, it becomes easier and easier to reap the benefits of the approach. Dramatic improvements in project outcomes usually require investments in change. Following MSF is a significant investment in change. I hope that the above advice makes it less frightening to embark on a program for MSF change.
Paul Glen is an IT management consultant and the author of the award-
winning book “Leading Geeks: How to Manage and Lead People Who Deliver
Technology” (Jossey-Bass Pfeiffer,2003). He regularly speaks for
corporations and national associations across North America. For more
information go to: http://www.paulglen.com. He can be reached at
info@paulglen.com.
