Many project managers cringe when the talk of project management processes are compared to instances of broader business or organizational processes.

1. The Theory versus Practice of Project Management
Many project managers cringe when the talk of project management
processes are compared to instances of broader business or
organizational processes. Trained as specialist and wary of sweeping
“generalizations”, they flinch when the “soft sciences” attempt to
speak directly to the needs of project management with claims of
breakthrough solutions. When these claims are made in the absence of
specific actions it is even more troubling to project managers in the
field, since not only are they told their current practices are flawed,
there is no actionable replacement – just philosophical jargon words.
Here in the field, these attempts to generalize remind me of the
unique circumstances highlighting the situational differences in
projects and their processes from general business situations. Where
a “generalist” may see similarities I see uniqueness and limitations.
These two points of view are not incompatible. The problem comes
when an “actionable outcome” is desired. The generalist don’t always
have specifics – hence their position as generalist. The field PM’s don’t
always see the larger patterns that emerge from their specific
experiences.
The disconnect between theory and practice is long standing. By
searching for tools and processes that share a common understanding,
it may be possible to join these two distinct points of view. In the
absence of this connection, the practical aspects of project
management must prevail, since “delivering the goods” is the principle
measure of a PM’s success.
I’ve come to the conclusion that “field experience” is a prized position
from which to speak to PM issues. There are eloquent theorists in the
PM realm, Lauri Koskela’s Theory of Project Management being one.
But for the most part the usefulness of project management theory is
to frame the daily actions of those delivering products and services to
paying customers.
Back to IMP/IMS
Last month introduced the concept of an Integrated Master Plan /
Integrated Master Schedule (IMP/IMS). Although IMP/IMS appears
obvious at first glance, there are more subtleties and benefits than
meet the eye. As well, IMP/IMS appears to be a “high ceremony”
approach to project management, with a lot of moving parts. But
these benefits come from the “doing” rather then the “talking,” so it’s
hard to convey an experience in a discussion.
The underlying concept of IMP/IMS separates work “tasks” from the
accomplishments and criteria for delivering these accomplishments to

2. the customer. This approach is the basis of “performance based”
management systems. By starting with the “end in mind,” IMP/IMS
provides the tool for subordinating our natural urge to define the work
before the outcomes are identified. It’s more than just “understanding”
what done might look like, it’s defining what “done” means - in some
form - so where we get there it can be recognized and verified. This
approach creates the success criteria before creating the tasks (work)
needed to deliver that success.
This may seem anti-agile at first, since it goes against the emergent
aspects of an agile project. The concepts of causality and certainty are
at the root of any “traditional” project management system. By
traditional I mean PMBOK-style approaches where “management as
planning” is the core paradigm.
In these traditional approaches (at least in the non-government
sector) work starts with the WBS. The PM links all the work together
and manipulates this “schedule” to fit the allotted time and budget. In
principle there’s nothing wrong with this approach. But like Yogi says
“in theory there’s no difference between theory and practice. In
practice there is.”
The problem with this “task first” approach is that “done” is not always
well defined in the beginning, but rather is defined as the result of the
effort consumed in the tasks. Not defining “done” in the beginning
means that no one will recognize it if it ever comes around.
The agile approach is to let “done” emerge as the project proceeds.
This sounds interesting, but needs to be turned into specific actionable
outcome to deliver on the promise of faster, better, cheaper product
development.
The fundamental principle of IMP/IMS is to define what done means,
so that done will be recognized, and done can be verified along the
way. Incremental, iterative, and even “emergent” development work
processes are independent of this approach. This approach provides a
framework for agile PM by setting up the criteria to judge the progress
of the project. Project Management is not Project Control, it is the
ability to recognize we’re getting off track and “manage” the project
back toward the goal of “done.” 1
1 Like all modern processes, words get in the way. Project Controls is a term used in
many organizations for Project Accounting. Project Control’s staff gathers data and
produce reports on the progress to plan of a project. In this context “controlling” a
project is not desirable especially in the agile PM world. Rather the PM needs to
continually provide guiding information for the project team that they’re off track.
With continuous feedback from the customer, continuous testing to generate that
feedback and agile PM still needs indicators that the project is not going well.

3. So in the end, agile is embedded in a framework where “done” should
be well defined, the description of the accomplishments and the
criteria for judging these accomplishments is itself well defined. This
framework is a blend of structure and agility.
Some More IMP / IMS Background
One of purpose of IMP/IMS is to identify the “meat” between the
milestones. Milestones (or Events in the IMP), define “check points” in
the program. What takes place between the milestones is the subject
of this month’s column.
First some background on Critical Path Method. The role of CPM is to
communicate the progress, forecast completion dates, and identify the
“critical path” through a network of tasks. Gantt charts or any other
time phased diagram has difficulty showing the dependencies between
tasks. For small projects this may be possible, but my typical project
has 2,000 to 7,000 tasks. For large projects in my current domain,
200,000 tasks are the norm. Simply having a “bar chart” for such a
project may impress a visitor to the facility, but provides little help to
the Program Office staff.
The goal for IMP/IMS is to:
 Define the components of the project through a project data
architecture, a common numbering system for all these
components and a roll up linkage from tasks to events.
 Connect the horizontal and vertical architecture of the program
through a traceability diagram
 Illustrate the relationship between cost and schedule is ways
“obvious” to the stakeholders
 Tie the performance of the program to “Performance Based
Payments” through measurable deliverables.
Specific Contents of the Integrated Master Plan (IMP)
The IMP provides:
 An organizational structure for the Program
 The Program Management processes
 The horizontal and vertical traceability of the program
The three (3) components of the IMP are the Project Events (PE), the
Significant Accomplishments (SA), and the Accomplishment criteria
(AC). The detailed tasks, activities, and milestones; time-phased, with
durations, dependencies and sequencing relationships are assembled

4. into the Integrated Master Schedule (IMS). Like any simple idea this
stuff is obvious on the surface, but more difficult once you get started.
The first beneficial outcome is the creation of a Critical Path. The
purpose of this critical path is not to predict the future in the way
many critics of CPM naively claim. But instead, to identify which
activities in the network will be critical to the successful to the timely
delivery of the project. These critical path items become the targets of
attention by the PM and the development team. No matter what
development method is used, there will be items on the “to do” list
that are more important than others. This is the “operational
definition” of critical path. Meaning if we don’t deal with these items
then other items will fall behind become critical.
The search for “the answer” is not the goal of IMP/IMS or any project
management process. Regardless of the critics of CPM or any
deterministic project modeling approach, no professional project
manager sees these tools as anything other than tools to expand the
cognitive representation of the project. Arguing against the “predictive
power” of such tools is a loosing proposition unless of course there is a
viable replacement to answer the question “when is this going to be
done?” And, “how much will it cost at the end?”
Next Month
Vertical and Horizontal traceability are critical to the success of
IMP/IMS. Next month I’ll provide a quick overview of this concept
along with the sequential numbering schemes that enable IMP/IMS
deployment in Microsoft Project.