Project management is concerned with what can be referred to as the “external world.” As project managers we belong to this external world. The discipline of project management is not concerned with our private “inner” thoughts, dreams, and hopes regarding our profession. The science of project management is concerned with the “objective” reality of projects, rather than with the “subjective” experience of that reality.

1. The “Science” versus “Inner World” of Project Management
I want to start this month’s column with a controversial statement.
Project management is concerned with what can be referred to as the
“external world.” As project managers we belong to this external
world. The discipline of project management is not concerned with our
private “inner” thoughts, dreams, and hopes regarding our profession.
The science of project management is concerned with the “objective”
reality of projects, rather than with the “subjective” experience of that
reality.
Can there be a set of presuppositions behind this simple picture?
Presuppositions Consequences
There exists a world of physical
entities, with defined attributes,
metrics – separate from subjective
measurement.
On time, on budget, resource
usage
These entities exist independently of
perception.
Scalar measures of cost,
schedule, resource usage
Statements about these entities can
be known to be true.
Scalar measures have units of
measure agreed upfront
The soft science approach to project management has its place in the
interpersonal skills arena. But it is not a replacement for the core
elements of project management, nor can it take the place of a well
formed project and a competent project manager using the proper
tools and processes.
I personally feel that focusing on tangible processes for improving
project performance is the way to go. Others may not share this
approach and instead focus on the “softer” side of things. I have
neither the skill nor desire to go in that direction, so back to the core
processes I use daily in managing our projects.
Back to IMP/IMS
The previous column’s overview of Integrated Master Plan / Integrated
Master Schedule described the concept of an “event based” planning
process and its advantages over a “task based” planning processes.
Planning projects usually starts with tasks and milestones. The planner
gathers this information from the participants – customers, engineers,
subject matter experts. This information is usually arranged in the
form of activities and milestones. PMBOK defines “project time

2. management” in this manner. The activities are then sequenced
according to the projects needs and mandatory dependencies.
The usual critical path methods are then used to determine the
estimated completion date, risk areas of the project and other
statistical planning data.
What’s missing from the concept is the realization that the plan is not
the same as “done.” A description of “done” is usually not part of the
plan in an explicit manner. It’s there in implicit form – after all the
tasks are complete.
In the US Department of Defense version of PMBOK section 6 (Project
Time Management) is replaced by IMP/IMS.
In many project “contract” milestones occur at the end of the project.
These milestones represent the “end of work,” or the delivery of the
final product or service. Since they are “external” to the real work, it’s
difficult to have these milestones be part of the engagement process
between supplier and buyer or between project partners (Integrated
Project/Product Team).
The contractual elements of IMP/IMS are embedded in the contract.
Like earned value, IMP/IMS events are used as early indicators of
success.
In many projects, processes, disciplines, functional activities are seen
as the major schedule elements.
 Gather requirements
 Produce detailed design
 Develop software
 Test software
 Delivery software to customer
are typical functional boundaries between project phases. What is
missing are clear and concise definitions of “done.” IMP/IMS provides
you will still see terms like “design,” “test,” and “verify.” But they will
have past tense verbs attached to them. “Done,” “completed,”
“verified.” This may seem trivial at first, but there are subtle changes
in how the project plan describes the work.
If there is an “accomplishment” defined using the term “completed,”
what is the criteria used to assess the completion of this
accomplishment? Next what are the tasks that need to be performed
so the assessment criteria can be evaluated? This is the core of
IMP/IMS is an indented description of the work to be performed and
the physical evidence that progress is being made.

3. Project Event (PE)
Significant Accomplishment (SA)
Accomplishment Criteria (AC)
Activity Number of the Tasks and Subtasks (AN)
The focus on “events” replaces the focus on “tasks.” Tasks are still
present by they are an enabling activity not a project management
activity.
Without a clear and concise description of what is to be delivered, tied
to the plan, with measurement criteria the program has no way of
knowing how the project is performing.
The emphasis on “performance” and “maturity” is the core of IMP/IMS.
This is a fundamentally different approach than “task based” planning,
where the focus is on progress to plan for tasks, critical path analysis
of the work remaining, and resource management. IMP/IMS does not
replace this focus. It simply puts it in the proper position – as an
enabling process to the strategic goal of defining “done” in measurable
terms.
I’ve built a “just in time” training slide show for IMP/IMS that can be
found at www.niwotridge.com. The exact link will be available in a few
days.
Next Month
With this IMP/IMS background let’s look at the end to end project
management processes found in complex projects, including how agile
techniques can be integrated with the formality of IMP/IMS to produce
a powerful set of tools.