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.
“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
|Planning. The ongoing business function
of identifying business needs, technologies and solution
options to align business and IT plans. While Microsoft
hasn’t developed a specific framework for addressing the
planning phase, its service offerings include “Business
Value Services,” which will likely lead to a more formal
set of guidelines and best practices to address the planning
Preparing. The project-specific business function
of developing the organizational and individual readiness
necessary to implement new technologies. The Microsoft
Readiness Framework was developed to address this critical
Building. The project-specific technical function
of designing, developing and deploying systems rapidly
and efficiently. Many developers are familiar with the
Microsoft Solutions Framework used to address the issues
inherent with the execution of large-scale application
Operating. The on-going technical function of
implementing repeatable processes, procedures and customized
support options to run highly available, scalable, reliable
and manageable systems. The Microsoft Operations Framework
provides guidelines and best practices for developing
an operational plan for this phase.
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
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.
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.
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
- 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
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.
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
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.