In-Depth

A Method for the Madness

Understanding and applying the Microsoft frameworks can help you bring order and meaning to the chaos of technical projects in your organization.

• By Nivine Zakhari
• 12/01/2001

“More than 80 percent of technical projects fail due to non-technical reasons.” —The Standish Group

While it certainly was a fun and exciting ride, the technology boom of recent years has finally yielded to the reality of the business world. No matter how “kewl” the technology, it takes more business know-how than technical skills to make a positive, lasting impression on a company’s bottom line. Just what is this “business know-how” and why should MCPs care? Common business sense was the critical ingredient lacking in many management teams of dot-com operations. Unfortunately, this same lack of business sense is evident when we try to analyze failed technical projects within larger, established organizations.

With record-setting layoffs and missed earnings estimates pummeling even the most venerable of companies, the decision-makers in many of these companies need more justification before approving upgrades and additional development. As technology experts, we can appreciate the performance improvements and enhanced stability offered by an OS upgrade or new suite of management tools, but how do you explain the business benefits in a way management can understand? If you can’t, odds are your dream project won’t get the green light.

Today, technical groups must exercise the same due diligence as other business groups when planning, preparing, building and operating technical solutions. Understanding the technical issues is no longer the critical success factor.

In recognition of this fact, Microsoft has developed a group of frameworks for addressing the business issues faced at an enterprise level in each phase of the IT lifecycle. While Microsoft developed the frameworks with its own solutions in mind, you can apply the principles regardless of technology or vendor selection.

As certified professionals, we’ve already demonstrated our technical expertise to our clients, employers and peers. Through application of the Microsoft Enterprise Services Frameworks (ESF, the umbrella term used to describe the collection of frameworks), available free online, we can further demonstrate our understanding and awareness of the impact we have as technical consultants within the business organization.

Successful Solutions for the
Full IT Lifecycle
Microsoft created its frameworks to address the key issues facing technical project leadership at each stage of the IT lifecycle.

The basis for the frameworks originated within Microsoft itself. The Microsoft Solutions Framework (MSF) was the first to be developed and formally released in 1994. Microsoft Consulting Services and several of Microsoft’s enterprise customers and partners currently use the MSF as the basis for training their technical staff in enterprise architecture, application development, component design and infrastructure deployment.

Since its introduction, the MSF has been expanded and two additional frameworks—the Microsoft Readiness Framework (MRF) and the Microsoft Operations Framework (MOF)—have been developed to address the other two critical phases in the IT lifecycle. While the company hasn’t formalized a framework for the planning phase, don’t be surprised if it’s introduced in the not-so-distant future.

While the frameworks provide an enormous amount of information addressing the various aspects of project management, what I want to do in this article is get you familiar with the MRF, the first formal framework you’d use in the project’s lifecycle.

Getting Ready
Many of us who have worked in large companies know that most system upgrades don’t happen overnight. While it would be wonderful if every new OS release could magically be applied and wipe out all the problems of the previous version, we know that getting a new system installed brings its own versions of problems. But we can predict technical compatibility issues. What about compatibility with your organization?

The successful implementation of technology solutions involves more than just technology. These initiatives often have implications for people and processes across the organization. Do your organization’s projects typically allocate the necessary resources to address these issues? Most technology initiatives fail to achieve their objectives because human and organizational problems aren’t adequately addressed.

The MRF provides a set of guidelines and best practices for preparing an organization to adopt technological changes through capability planning, organizational capability and competency identification, and individual and organizational assessments.

A recurring theme throughout the frameworks and IT lifecycle is the importance of team models, risk management and process.

Team Models
The team models for each phase of the lifecycle provide a set of guidelines for the organization, communication, skills, roles and responsibilities for that phase. A critical component of the team model is the assignment of specific areas of responsibility for each role so there’s direct accountability on the success or failure in achieving those goals.

Within the MRF, there are six team goals to achieve in preparing the organization for the implementation of new technology:

• Communicate a clear vision for successful technology adoption.
• Deliver highest priority readiness needs.
• Deliver enhanced organizational performance and successful management of the technology change.
• Get stakeholder participation and effectively use organizational resources.
• Attract, develop and retain people throughout the adoption process.
• Sustain sponsorship and management of the change to help the organization move to full realization of the technology investment.

The members or groups within your team need specific roles in order to achieve these goals, which would include:

• Analysis management. In order to communicate a clear vision to all the project’s stakeholders, the person involved in analysis management must be able to understand and translate the business requirements into technical requirements, identify stakeholders who need to be involved, and facilitate meetings and focus-group sessions.
• Assessment management. This person is responsible for making sure the organizational assessment accurately reflects the team’s existing competencies and readiness for change, which, in turn, identifies gaps that need to be addressed to achieve the project’s overall goals.
• Organizational readiness management. The person in this role will usually have overall budget and schedule accountability, since this role could be described as the project manager with a heart. They make sure the project is a success, not only on a technical level, but also at the human level, where project success is most dependent.
• Business management. This role is the champion for the project’s stakeholders and makes sure their needs are accurately represented and properly addressed by the other project participants. The business manager also makes sure that all the organization’s resources are being properly used during the course of the project.
• Education and development management. Another critical success factor to technical projects is making sure the implementation team and the end users will have the right skills to execute and benefit from its successful release. The education and development manager works with the assessment manager to identify the skills gaps that need to be addressed through selected education, training and development strategies.
• Sponsorship management. Project sponsorship is usually dependent upon finding the highest-level person in the chain of command necessary to support the initiative in the organization. This doesn’t mean getting the CIO to rubber-stamp each project. Usually, it requires support from non-technical leaders in the organization who can communicate the business value of the proposed changes and gain acceptance by the user community.

Without each of these critical areas of responsibility assigned to a team member and properly addressed, projects run an increased risk of failure, not due to a technical inability to deliver, but the organization’s inability to accept. You don’t need to look hard to find enormous capital expenditures associated with enterprise-level technical projects all going to waste because the user community refuses to adopt the new tool and/or process for a variety of reasons. What the MRF helps you do as a technical consultant is recognize those early indications of potential project failure before that first line of code is written or that first server is put in place.

Risk Management
The discipline of risk management has to do with the identification of potential problems and determining when and how they should be dealt with. Being proactive is key here. [For more on this topic, read Roberta Bragg’s article “Risky Business” in the September 2001 issue.—Ed.] However, it’s possible to take risk management to an extreme, and that’s where understanding a cost/benefit analysis can come into play.

For example, most people understand the risks associated with testing code changes in a production environment. Developers usually have a test environment for simulating production so that they can deploy code changes without jeopardizing operations if that new code happens to break another part of the system. Having the test environment reduces that risk. Larger teams may have two environments to simulate production: one for development and unit testing, and a second for user acceptance and stress testing. It costs more to have multiple environments, but the more critical the production system, the more testing and verification you want before applying any changes. (Need I even bring up the DNS fiasco Microsoft reportedly experienced a few months ago?) If more environments help, does it make sense then to have three, four or more set-ups? How many times do you want your team to run through the build process before iy actually gets to production? How thoroughly do you document and test your back-out plan in case the unexpected inevitably occurs in production? In other words, how much do you spend to avoid a failure in production? The only way to know is to have an estimate of what the cost of a production failure would be. If your company’s Web site processes $10 million in transactions each day, you’re going to want to invest more to avoid production failure than if that Web site processed only a handful of transactions per day.

While we all know the significance of a production server going down due to a bad code release, how familiar are we with the non-technical causes of project failure? Prior to setting up our development and testing environments and build process, we must identify the non-technical risks associated with our project’s success. One of the tools provided with the MRF is a Risk Assessment Matrix in, simply enough, an Excel spreadsheet. The risk factors the spreadsheet contains, however, are far from simple. (See Figure 1.)

Figure 1. Problems and potential solutions. The Risk Management Matrix, provided in an Excel spreadsheet form, lets you evaluate the non-technical risks associated with your project’s success—and provides means for overcoming the obstacles. (Click image to view larger version.)

For example, when identifying potential project risks at the individual level, one of them could be, “Resistance: Project stakeholders are exerting overt and/or covert opposition to the project.” What would be a consequence should that occur? “Project delays or failure, poor adoption rates, failure to realize business and functional benefits.” How do we know the condition exists? “Lack of participation in assessments, project meetings, activities, input or feedback.” What would cause us to want to take action if this risk is apparent? “Major milestones aren’t being reached due to lack of participation or sabotage.” Not a good thing.

So how can we mitigate or reduce the likelihood of this risk? “Identify resistance through interviews and sessions designed to surface it; educate stakeholders on reasons for the change, its benefits and the impact it will have on them, and the plan for supporting them through the change; install feedback mechanisms; increase sponsorship participation; increase change agent participation or effectiveness; increase stakeholder participation.”

That’s a great mitigation plan, but what if that still doesn’t work? What’s your contingency plan? In other words, how do you make sure the risk is properly dealt with once the trigger condition has been met but before the project is doomed to fail? “If overt, remove resistant individuals from project. Analyze and discuss cost of resistance to change with sponsor and make decision to implement top down, delay project or abort.” I don’t think you need to devote a lifetime to project management to know that’s easier said than done.

While the Risk Assessment Matrix may oversimplify some of the more complex and delicate issues you’ll face in project management, it does get the team thinking more at the human level instead of just at the technical level. I think it’s fair to assume that most of us are comfortable with and expect to find solutions to many of our technical problems in MSDN or the online support Knowledge Base, but where do you go for step-by-step solutions on dealing with a politically motivated project saboteur? Unfortunately, remedies for those types of situations aren’t as clear-cut.

Process Models
The process models for each phase are flexible enough to be applied across any project type: phase-based, milestone-driven or iterative. The process model includes both organizational and individual activities and can be applied to projects of varying scope.

For example, within the MRF, the process model consists of four integrated phases: planning, assessing, changing and evaluating. Within each phase are specific activities that should take place and designated team roles responsible for carrying them out in order to achieve the appropriate level of readiness.

How many times have you been rushed to fit “just one more thing” in before a deadline, only to have that change questioned after it was released? Were all of the parties affected by the change notified beforehand? Was the self-proclaimed decision-maker for that piece of functionality really the decision-maker? If any of this sounds familiar to you, then it would make sense to implement change control processes now to avoid these types of problems again in the future.

I should remind you that a lot of these recommendations come out of working in large, enterprise organizations in which more time needs to be spent documenting and preparing the organization for change simply because you can’t get all the key participants up-to-speed with a 15-minute meeting by the pool table. If you work in a smaller company, you may not have resources available for implementing a formal change-management processes. Unfortunately, it’s not unusual in smaller development shops to see no formal change-management processes at all—which is scary in itself! Usually, it’s not until after a serious problem occurs that people realize it’s worth it to take the time to document their changes and justifications before rolling them out.

Increasing Your Value as a Consultant
While much of this may seem like common sense, the reality is that common sense isn’t that common! A lot of us can probably think of projects we’ve worked on in the past that could have turned out better had we, or other members of the management team, spent more time focusing on its non-technical aspects.

Many of us prefer not to even have to deal with a lot of these issues in our projects because they can sometimes seem so irrational, disorderly and unpredictable compared to what we’re used to dealing with in our code and admin consoles. Are you more comfortable ferreting out log entries for a failed transaction in a production system or dealing with business owners who can’t understand why their new multimillion-dollar software installation still isn’t capable of doing all their work for them?

Whether you have internal or external clients to deal with on a regular basis, taking into consideration the business and human factors on your projects early on can go a long way in demonstrating your true value as an IT professional.