The document discusses integrated project management and systems engineering. It describes the concepts of an Integrated Master Plan (IMP) and Integrated Master Schedule (IMS), which separate work tasks from accomplishments and criteria for delivering accomplishments to customers. This defines what "done" means upfront, rather than letting it emerge from tasks. Benefits include creating a critical path to focus attention and tying performance to measurable deliverables. The next steps are to provide an overview of vertical and horizontal traceability between components and how IMP/IMS can be deployed in Microsoft Project.

1. 1
The Herding Cats Column of Glen Alleman
On Integrated Project Management and Systems
Engineering
A Recent “Encounter”
Glen Alleman
Many project managers cringe when the talk of project management processes are compared to 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 from the generalist. 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 theorist 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 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.”

2. 2
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)
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 the purposes 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 the Critical Path Method (CPM). 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 have 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, 50,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 in 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 project 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 into the Integrated Master
Schedule (IMS). Like any simple idea this stuff is obvious on the surface, but more difficult once you get
started.

3. 3
Benefits to the Project
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 and 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 losing 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
overview of this concept along with the sequential numbering schemes that enable IMP/IMS deployment
in Microsoft Project illustrated in a real IMP/IMS Project Professional schedule.
Note: (1)# Like all modern processes, words get in the way. Project Controls is a term used in many
organizations for Project Accounting. The 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 an agile PM still needs indicators that the project is not going well.