[project.headway]
™
I N T E G R A T I O N
S E R I E S
Integrating
Project HEADWAY
And MICROSOFT
SOLUTION
FRAMEWORK
P
R
O
J
E
C
T
H
E
A
D
W
A
Y
W
H
I
T
E
P
A
P
E
R
Integrating Project HEADWAY And
MICROSOFT SOLUTION FRAMEWORK
Introduction
Microsoft Solutions Framework (MSF) has become a prevalent
structure for the development and management of systems
projects, particularly those that employ Microsoft’s development
environments. Originally developed as a loose collection of best
practices based upon internal product development efforts as
well as numerous consulting engagements by Microsoft
Consulting Services, MSF has developed into a comprehensive
framework for guiding the development of software applications.
Like many frameworks for systems development, MSF bills itself
as a method of managing systems development projects based
upon the principle ‘build it right’. At its core, MSF is a systems
development methodology. While it speaks to some
management principles, the primary focus of the MSF is on
developing the technical products associated with a systems
development project.
Project management methodologies like Project Headway
provide solid support for the use and application of
development approaches like MSF. Rather than being viewed as
a replacement, they are instead a complement to how systems
are development. Project Headway in particular is an ideal
environment for supporting the management of systems
development processes. While the roots of Project Headway are
in the IT industry, the methodology has evolved into a robust,
sound approach to managing any type of project.
Microsoft Solutions Framework Overview
In the world of systems development approaches, MSF is rather
unique for a number of reasons:
• The roots of MSF are in product development, rather than the
delivery of systems development in through an internal IT
department or an external consulting basis. While Microsoft
Consulting Services had a strong influence in the development
and continued maintenance of the process, its origins are in the
wealth of experience Microsoft has gained in developing products.
• MSF positions itself as a framework rather than a
methodology. As such, it tries to offer guidelines and identify
useful practices rather than providing specific dictates about
how to proceed with developing systems.
© gantthead 2006
• MSF specifically recognizes project management as a separate
but related discipline to systems development. While not
directly a part of the process, MSF offers a separate ‘project
management discipline’ that provides guidance in managing
projects using the MSF process and team models.
In keeping with its principles of being a framework rather than a
methodology, the guidelines within the MSF are presented in a
number of component entities, most particularly the Process
Model and the Team Model.
Core Dimensions Of the Microsoft Solutions
Framework
Process Model
The core of the MSF Process Model is a development approach
that integrates a linear cycle in an iterative model. In essence,
each iteration of the model is a ‘version’ which results in the
production of a working, usable solution by customers.
A central principle within the MSF is adaptability and flexibility.
Within the phases of a version, there may be activities that
overlap phase boundaries. A core principle of the development
process is the creation of living documents that are versioned
and evolve over time. The overall intention is collaborative
evolution of the project deliverables in order to rapidly deliver
functionality.
The core phases of the MSF model include:
• Envisioning. The overall intent of the envisioning phase is to
establish the vision and objectives for the project. The team
should develop a shared and consistent understanding of what
the project at a macro level and the version at a micro level
should produce - the vision. This is an unbounded narrative of
what the solution could be and is possible to create. Separately,
the scope document commits to a concrete definition of what
the version will produce in the context of the defined vision.
• Planning. The planning phase emphasizes the determination of
how the project will be conducted. Functional specifications
and version designs are produced, and the overall work plan
including costs and schedule are defined. The planning phase
bridges the more abstract definition of the project created in
the vision with concrete technical specifications.
• Developing. The developing phase is focussed upon the
creation of working, usable code and executables. This is the
version of the system that will be released as a result of the
iteration. This includes not just development of the system
code, but installation scripts, frozen functional specifications
and test cases and test scripts.
• Stabilizing. The stabilizing phase emphasizes testing of the
solution in conductions that are similar to a realistic
operational environment, in order to produce finalized and
stable code. During this phase, bugs are identified, prioritized
and eradicated in order to establish a stable, workable solution.
• Deploying. The deploying phase involves the introduction of
the core technology and system components in an environment
that is usable by the project customers. This includes transition
of responsibility for support of the version, and finalization of
all documentation, processes and procedures.
While the phases associated with the process model appear
linear in nature, and not dissimilar to a traditional waterfall
approach, it is the practices within the process model and the
philosophy of iterative development of frequent versions that
create flexibility and usability of the MSF.
Team Model
The MSF Team Model is intended to define the role groupings
associated with the framework. A principle of the MSF
development environment is one of defined responsibility but
mutual accountability. In other words, each role and role group
within the MSF has its own focus and objectives within the
context of the project, but the team as a whole has a shared and
collaborative accountability for the delivery of the project results.
The MSF Team Model provides an exhaustive view of the roles
required to support an effective systems development effort. The
specific roles include:
• Product management. The primary role of the product
management group is to act as an advocate for the customer,
with a goal of ensuring that they are satisfied with the solution.
The role is to manage expectations of the customer groups,
manage the process of requirements definition and develop
and maintain both the business case and the awareness and
communications process associated with the project.
• Program management. The primary role of program
management is to define and manage the process to ensure
delivery of the system within the defined constraints of the
project. They serve as the primary project architect, as well as
maintaining and monitoring project performance and
managing project risks.
© gantthead 2006
• Development. The role of the development group is to build
the system to specification. They are responsible for
establishing the physical design of the solution, building the
product and supervising its deployment.
• Test. The test group is responsible for approving the system for
release once all product quality issues have been resolved. They
are responsible for developing and implementing testing
strategies and ensuring that all issues are being followed up on.
• User Experience. The user experience group is responsible for
ensuring the user effectiveness of the delivered solution. They
are responsible for graphical standards and look-and-feel, as
well as acting as an advocate for the users of the system and
ensuring user requirements are established. The user
experience group is also responsible for change management.
• Release Management. The release management group is
responsible for ensuring the efficient and effective transition of
systems products into use, and acting as an advocate for the
support teams. They are responsible for the deployment of
systems, the procurement and installation of required
infrastructure and for providing logistical support to the
project team.
While the discipline of project management is a part of the
program management group role, what is interesting about the
MSF guidelines is the maintenance of a collaborative and cooperative approach amongst the team members. There is not a
hierarchy where the project manager assumes supremacy, but a
framework for shared ownership and accountability.
Project Management Discipline
MSF does not have specific project management activities
identified within the Process Model, nor is there a specific
project management role within the Team Model. Project
management is still viewed as a key component of MSF, but is
defined in a separate ‘Project Management Discipline’ that is
articulated separately from the framework itself.
Most importantly, MSF acknowledges that the Project
Management Discipline is not intended to be a specific guide to
project management, but to define how standard project
management activities integrate into the MSF framework.
In defining project management, MSF reinforces the framework
established by the knowledge areas within PMI’s Project
Management Body of Knowledge (PMBOK). It acknowledges
that while there is some overlap between project management
and the industry-specific practices of systems development
defined within the MSF, much of project management is
separate and distinct, while still related. What MSF does provide
is some specific recommendations regarding specific detailed
practices, including project planning, WBS definition, estimation
and scheduling to reinforce specific areas of emphasis.
Additional Microsoft Solution Framework Dimensions
In addition to the Project Management Discipline, MSF also
defines two additional disciplines that are designed to support
the MSF practices and models:
• Risk Management Discipline. While risk management is
traditionally considered a part of the overall approach to
project management, MSF articulates a separately defined Risk
Management Discipline. Within this, it is acknowledge that
risk management is a core component of project management
- but continues to define it as a separate dimension. The
approach defined reflects a fairly standard approach to risk
management, involving risk identification, analysis, planning,
tracking and control.
• Readiness Management Discipline. The Readiness
Management Discipline addresses the requirements associated
with preparing the organization to adopt a new system. It in
essence addresses the ‘change management’ or ‘business
implementation’ aspects of introducing a system and ensuring
that the skills and capabilities are in place to effectively utilize it.
Additional Resources
• Microsoft Solution Framework v.3 Overview White Paper:
http://www.microsoft.com/downloads/details.aspx?FamilyID=5
0dbfffe-3a65-434a-a1dd-29652ab4600f&DisplayLang=en
• Microsoft Solution Framework web site:
http://www.microsoft.com/msf
Project Headway Overview
What Is Project Headway?
Project Headway is a project management methodology
developed and published by gantthead.com. It provides a
comprehensive framework for managing projects in an
organizational context. The framework is fully compliant with
the 2004 version of the Project Management Body of Knowledge
(PMBoK) of the Project Management Institute (PMI) and the
latest version provides direct integration between the activities
and steps within Project Headway and the PMBoK guide.
Project Headway Background & History
The methodology is based upon the JPACE project process
originally developed by James Martin & Associates (now
Headstrong) and is made available to corporate members of
gantthead.com.
© gantthead 2006
In 2006, the Project Headway process was enhanced and
updated. Changes included directly aligning Project Headway
with the PMBoK, as well as introducing guidelines for the
management of three different project models, differentiated on
size. Project Headway defines all of the project management
activities necessary to support the full management and delivery
of projects, as well as supporting integration with a variety of
product and service development processes.
Project Headway Structure
The structure of Project Headway is based upon five discrete
phases of work:
• Justify. The Justify phase focuses on articulating the purpose
and business drivers for undertaking a project. This phase
articulates the activities necessary to build a viable project
charter, as well as to develop and sell the project business case.
• Plan. The Plan phase describes the work necessary to plan a
project in detail. It defines the full range of activities necessary to
produce a project plan, including determining the objectives and
scope of the project, selecting the project approach, developing
the detailed work plans and determining the project management
activities necessary to successfully deliver the project.
• Activate. The Activate phase articulates the work necessary to
initiate a project once it has been approved, including securing
team members, managing stakeholder communications and
awareness and ensuring the resources are in place to deliver
the project.
• Control. The Control phase defines the work necessary to
monitor and control the project throughout its life. It addresses
the steps required to monitor project progress, take corrective
action as required and control the various aspects of the plan,
including schedule, cost, scope and risk.
• End. The End project phase addresses the activities required to
successfully close the project and evaluate success. It addresses
the administrative requirements necessary to complete the
project and any associated contracts, the evaluation of project
success, redeployment of staff and the identification of future
improvement opportunities and the ability to reuse the
capabilities produced in this project.
Integration & Alignment
How Project Headway Supports The Microsoft Solutions
Framework
The principles and practices contained within the Microsoft
Solution Framework are logical, practical and proven effective.
What is important to recognize about them, however, is that
they represent guidelines and recommendations, not specific
process steps. As such, organizations and project teams must
specifically decide how to adapt and adopt them in order to
successfully deliver a project.
The irony of managing a project to allow for the flexibility and
progressive elaboration of design described in the MSF is that a
great deal of rigour is required to control scope and
management expectations in order to enable the flexibility of
solution development approach described, a point that is
reinforced by the MSF development team, particularly with
respect to ensuring effective change control of the project and
solution scope and ensuring rigorous configuration management
of the developed deliverables.
What is most essential in creating this rigour is choosing a level
of project management practice that makes sense. Project
Headway provides an ideal basis for project teams and
organizations in defining and selecting their project
management practices. The integrated project models provide
ready guidance in adapting the project management approach to
differing sizes of projects and expectations of management
rigour. The overall approach represents a flexible, dynamic
means of managing a project using MSF principles.
Alignment With The Process Model
The process model has a strong degree of alignment with Project
Headway framework, in both philosophy and practical
application. There is a strong correlation of purpose and
objectives between the Justify phase of the Project Headway
framework and the Envisioning phase of the MSF, as well as
between the Planning phases of both frameworks. The Activate
and End phases of Project Headway provide a formal
mechanism for both ensuring an effective project or version
launch and managing the close-out process, while the
Development, Stabilizing and Deploying phases of MSF would
all be managed during the Control phase of Project Headway.
The advantage of Project Headway is its scalability and flexibility
- the JPACE process model is relevant and appropriate at both
the project level, to manage the full scope of work contemplated
by a systems development initiative, and at the version level in
managing individual iterations, as illustrated below:
© gantthead 2006
As importantly, Project Headway aligns with the underlying
principles of MSF, including:
• Work towards a shared vision. The development of a clear, shared
vision is fundamental to being able to collaboratively deliver a
successful project outcome. The Justify phase of Project Headway
is focussed on ensuring that there is a clear articulation of what
the project is designed to produce, and the business value of this
being realized. Embedded within the process guidelines are
expectations of collaboration both inside and outside of the team,
making sure that there is strong organization and sponsor support
as well as a collective vision that the team is working to realize.
• Stay agile - expect things to change. Change is fundamental to
any project. Project Headway supports a project and team
mindset that welcomes change, but that also supports the MSF
expectation that this change be managed. Constant focus on
ensuring the business value of what is being produced, and
managing changes in the expectations associated with this
delivery, is central the Project Headway process.
• Focus on delivering business value. The objective of ensuring
measurable business value is at the heart of the Project Headway
process. This process starts with the articulation of the vision and
collaborative development of the business case process within the
Justify phase. The articulation and reinforcement of the vision
and values with all stakeholders is reflected in the Activate phase.
On-gong reviews through each project phase provide a continued
focus on monitoring the attainment of value.
• Foster open communication. Project Headway takes a broad
and inclusive approach to stakeholder communication and
awareness. As well as ensuring a collaborative environment
within the project team,
Alignment With The Team Model
The team model within MSF provides an articulation of the roles
that should be addressed in delivering a project, without being overly
prescriptive in how those roles should be filled. Instead, there are
some underlying principles defined that govern team operations,
which are well supported by the Project Headway framework:
• Clear accountability, shared responsibility. As mentioned
earlier, one of the underlying principles of MSF is that of clear
accountability and shared responsibility. The essence of this
philosophy is that each of the roles defined within the team
model is equally important, that each provides a unique lens by
which to view the project and that all of the roles cannot be
represented by a single person. Project Headway supports this
philosophy in that it does not dictate any particular structure
in how project teams should be structured. While roles are
defined within Project Headway, they are descriptive of the
responsibilities more than they are an imposition of hierarchy.
They also readily align themselves with the roles that exist
within the MSF, while defining the accountability for the
individual activities.
• Empower team members. While the idea can be broad, the
specific goals of empowering team members in the context of
the MSF Team Model are ensuring that the team is able to meet
the commitments assigned to them, that each team member is
willing to make commitments to others to deliver on the
project, that commitments are clearly defined and that each
member of the team makes every reasonable effort to meet the
commitments they have made and actively manage
expectations when a commitment is at risk. Project Headway
strongly supports this philosophy. First and foremost, it defines
a common set of expectations and a consistent process and
terminology by which to communicate and understand the
overall commitments to be managed, while being entirely
flexible in how (and to whom) commitments are assigned,
made and kept. The strong emphasis within Project Headway
on team communications and collaboration, and on active
customer awareness and involvement, readily lend themselves
to supporting this principle.
Alignment With The Project Management Discipline
Overall, the project management discipline within MSF strongly
draws upon the principles and knowledge areas defined within the
PMBOK, without specifically defining how the knowledge areas
should be addressed. As a methodology that is strongly aligned
with the PMBOK, Project Headway provides absolute alignment
with these expectations while offering teams specific guidelines on
how to address the project management requirements outlined in
the MSF project management discipline.
Within the MSF project management discipline, there are some
best practices that are specifically highlighted and recommended,
and which are each directly supported by Project Headway:
• Plan preparation and scope definition. The MSF project
management discipline suggests a process of on-going planning
within the context of a tight definition of project scope. Project
Headway allows for the on-going iterative refinement of project
© gantthead 2006
plans, while establishing an approach of tight scope control to
the project. The project plan definition in Project Headway
begins with the initial identification of project goals in the
Justify stage, and expands and elaborates on this in the Planning
stage. The use of Project Headway can be readily adapted to an
iterative model of development (discussed and illustrated in
“Alignment With The Process Model”, above) that allows for the
continued refinement of the plans from version to version.
• Document re-use. MSF recommends the identification and reuse of documents from previous projects to make the planning
and definition process more efficient. Project Headway
specifically allows for and accommodates re-use as part of the
overall methodology, including identification of existing
documents and deliverables that can be re-used within the
project being undertaken. The project close-out activities also
include identification of deliverables and artefacts that can be
re-used in future projects.
• Work breakdown structures. MSF places strong emphasis on
the development of effective work breakdown structures as a
means of defining the overall activity structure of the project,
and as well as providing a framework for traceability of the
functional specifications to the work and deliverables of the
project. Project Headway reinforces the strong emphasis on the
creation of an effective work breakdown structure, emphasizing
a level of detail that promotes the ability to estimate, assign and
monitor completion of the full work of the project and align
the resulting deliverables of the project.
• Estimating. The recommendations of the MSF project
management guidelines a bottom-up estimation approach that
starts at the lowest (task) level of detail within the project.
Project Headway supports and advocates bottom-up estimation
approach, including identification of the level of uncertainty
associated with project estimates. The estimation guidelines
within Project Headway provide practical, proven techniques
for developing estimates and managing overall expectations
regarding delivery requirements. The planning process is
predicated on a bottom-up estimation approach, and Project
Headway provides extensive guidance and helpful tips for
developing and validating project estimates.
• Scheduling. MSF recommends specific techniques for project
scheduling, including the identification of dependencies, the
use of time-boxing, scheduling based upon risks and the
management of ‘buffer’ or contingency allowances at a project
level rather than for each activity. Project Headway fully
supports and advocates the use of these techniques in
developing project schedules.
Conclusions
Overall, there is an extremely strong degree of alignment
between the project management principles identified in the
Microsoft Solutions Framework and those of Project Headway.
MSF defines a framework at a conceptual level, identifying
guidelines and best practices rather than advocating a specific set
of processes or activities. Project Headway builds upon these
principles, providing practical guidance in how to apply the
management principles in a practical and logical fashion.
While Project Headway provides a process focus, it is also not
excessively structured or linear in its approach. Flexibility is
explicitly created through the identification of three project
models: small, medium and large. Many of the best practices and
techniques advocated in MSF are incorporated into Project
© gantthead 2006
Headway, either as specific techniques and process steps or through
tips and techniques associated with individual tasks within the
process. It readily aligns with the progressive, iterative development
philosophy of MSF while providing a common language and
framework by which to think about and plan projects.
For any organization adopting Project Headway, there are still
choices to be made in how to specifically apply and adopt the
process. These adaptations will result from up-front choices
around how the organization defines its process expectations, as
well as continued evolution of the process over time as it is applied.
Where an organization chooses Microsoft Solutions Framework as
the basis by which to manage its systems or product development
processes, Project Headway provides a logical, flexible and scalable
choice for implementing systems recommendations.