|While project documentation is
incomplete from the start, there is a tendency that
it will also differ from the work actually done.
This deviation is further growing the nearer the project
comes to its end.
How can one overcome this dilemma?
The Creeping Scope
Incomplete documents and scope creep - how accurate can project documentation be?
Oliver F. Lehmann, PMP
What some experts say
There are two common opinions in project management
relating to documentation:
"Whenever a problem or an issue arises,
which is connected with incomplete documentation, the
made these documents is to be blamed. This may be the proposal
manager, the project manager, or any other stakeholder.
Documents must be complete to the extent
that they describe any possible course of events and decisions."
This opinion is applied to many commonly used documents in
project management, including
Internal project requests
Requests for proposals, invitations for bids
Statements of work
Bids, quotations, and proposals
with the customer
Contracts with subcontractors
Other planning documents
(WBSs, network diagrams, resource schedules etc.)
Change control documentation
Product and service descriptions
||... and many more
The opinion is held true for customer
projects, where disputes that can not be remedied otherwise
may lead to expensive and time-consuming court cases with
It is also applied to internal
projects, i.e. projects where the performing
organization and the organization obtaining the deliverables are
identical. There, different opinions may be sorted out by the
organization's management not judges, but the authors of any
documentation linked to the dispute may still be held
"Documents and the actual scope - the
work done and its outcomes - must remain consistent with each
other during the entire course of the project."
A clear Integrated change control
process ought to be applied which ensures this consistency. An
example for such a process is shown in the following diagram:
Change control process ensures that requested
changes are assessed for their impact before they
are getting implemented.
Note: This process description assumes
that no requested change is being implemented without an impact
assessment, which includes identification and evaluation of all
impacts over the various aspects of the project including time,
costs, staff, quality, risks etc.
Another element of this assessment is to
gain understanding of the impact with the project environment,
e.g. on other projects inside the same program or portfolio.
change control process integrates over knowledge
areas and into the project environment.
At the end of the project, there should
therefore be documentation, which is not only complete but also
consistent; and all changes have been
impact-assessed and approved. Anything else is Scope creep:
Uncontrolled and often unauthorized alterations to the project
plans, typically without approvals.
"Uncontrolled changes are often referred to as project scope
"Scope creep: Adding features and functionality (project
scope) without addressing the effects on time, costs, and
resources or without customer approval."
Taken from: A Guide to the
Project Management Body of Knowledge (PMBOK® Guide
(Pages 119, 375)
These opinions are not generally challenged
in this article. They describe a professional approach to a
well-defined and maintained project scope. The question discussed
here is, which mechanisms make it so hard to follow these rules.
Is there such a thing as complete documentation?
The concept of Incomplete contracts
Oliver Hart, John Moore and other scientists from the
Contract Theory discipline made clear that there is no such
thing as a Complete contract.
Contracts are always written as incomplete
Agreements to agree from a simple reason: The need to limit
transaction costs. Trying to write a complete contract would mean a
costly and time-consuming exercise which would stand in no
reasonable relationship to the bargain value of the contract. So
would be trying to read it, identifying errors and typos and using
it to develop judgments.
One can easily expand this concept on all
project documentation. Trying to model and describe the project
before its inception in complete depth would be expensive and
Another aspect is progressive elaboration,
which means that each project is sending its stakeholders through a
learning process. This process includes:
Developing an understanding of the
deliverables and the work to develop them
Developing an understanding of the material
and human resources (stakeholders) and of their interrelations
Developing a common understanding among all
Identifying risks and issues and finding
responses for them
Many project decisions should not be made too
early for various reasons, for example:
Technical decisions often need
visualization in form of mock-ups, models or a prototypes.
A subcontracted company may go bankrupt
during the time before their assignment begins.
An assigned employee from the own
organization may leave before the project assignment begins. Or
a better person may join the organization meanwhile.
Prices for services and deliveries may go
The financial situation of the own
organization, the customer etc. are difficult to predict.
It may also be hard to predict how long a
market window remains open.
Uncertainty and misunderstandings
Is it possible to fully avoid interstices in
the understanding of what a project is? How can we assess
To understand this point, simply check your current project:
Obviously, projects begin with incomplete
documentation, and it is uncertain, to which degree it has been read
and understood by the various stakeholders. And to what degree they
will be able to memorize it during the course of the project.
What happens with the documentation during the course of the
The illusion of a perfectly documented world
Theoretically, progressive elaboration should
include both, the project's documentation and project work and
deliverables in an integrative manner.
A clear process as described above should
ensure that only beneficial changes are getting approved, that
approved changes are implemented and that rejected changes are not
implemented (which sounds more trivial than it actually is).
"When the weight of the project paperwork equals the weight
of the project itself, the project can be considered
77 Project Management Proverbs
Part of this process should be ensuring that
the documentation reflects the latest status of the project
including one or more realistic forecast scenarios.
But maintaining documentation also comes with
transaction cost. Time, efforts, money needed to keep documentation
accurate and true are lacking especially in those projects where
avoiding scope creep would be mostly beneficial: In projects with
tight budget and burning deadlines.
Scope creep really comes creeping
An observation: In most projects (all
projects which the author has seen so far!), Scope creep, defined as
the level of inconsistency between documentation and what is really
happening, grows exponentially to the end of the project.
Projects often start
with a high level of discrepancies between
documentation and reality and finish on a similar
Project managers may have large printouts in
ANSI D or ISO A1 size or even larger made from their project
management software. Meanwhile, large format inkjet printers have become fairly
They may also have electronic documents made
from templates, spreadsheets and databases. You see their
documentation printed or on the PC screen, you look at the work
really done and you find that they do not match. If you ask people,
they will tell you: "This doesn't really matter. Things will change
Things do not change. There may be variance,
but change is decided upon and implemented by people. Change
doesn't just occur. It is made and should be controlled. This is one
of the first lessons to be learned when one starts working with
A square in a decision
tree stands for a decision - a change. Circles stand
for chances, these are normally variances around an
expected mean value.
Reasons for the increased level of scope creep
towards the end of a project include:
Field changes - ad-hoc changes, whose
necessity and urgency often become evident only during late
implementation stages. Then, they need to be decided upon
immediately, and the process above would take too long.
Customer projects - field changes are even
more difficult in customer projects: two process worlds must be
reconciled and coordinated, each with its own pace and
Getting things done - finishing work has the
higher priority over documenting it. In most projects, time
pressure goes up towards the end of the project, and there is
not enough time left for both, documenting the project timely ex
ante and ex post.
The need is no more seen – the less work is
open and needs to be planned and tracked, the less value seems
to lie in a well-maintained documentation.
Customer projects again - documentation has
a value for a contractor to set off and ensure payments. And the
amount of money outstanding is getting smaller with each
Is it really a problem?
Take is as simple as it is: Whenever a
problem arises from missing, insufficient or false documentation, it
will be you who is in charge and responsible.
Another point: Learning lessons from projects
is something easier said than done. A lot happens during a project
day by day, and as much as a project manager needs a reliable
memory, a dependable ability of forgetting is also needed to free
the brain for new proceedings.
If things go wrong and if this is linked with
the project manager's poor planning, tracking and forecasting, the
person will be held accountable for that. Maintaining a consistent
and reliable documentation is something the project manager does in
the own interest and that of those who entrusted him or her with the
Is there a solution?
"Things are going to change anyway..."
As mentioned earlier, this is a common
statement when one visits a project manager in the office and finds
inconsistencies in the documentation. These are the most common
The important deadline is in six months, but there
is enough work there for the scarce resources to
keep them busy for almost a year.
The project budget does not include fringe costs,
contingency allowances, costs for inevitable idle
Network logic diagrams (if they are developed and
maintained anyway!) show dangles: open ended network
Periods of availability of resources are not
Resources are clearly over-allocated,
resource-leveling is not applied at all.
This is my favorite one: Cherry picking and Data date inconsistencies:
A swim lane diagram
showing work in a big engine project. Each line in
the diagram represents a worker.
The long vertical red line in the diagram is
the data date. Green bars stand for finished work, gray bars still
need to be done.
Question: How can open work be done in the
past and finished work be placed in the future?
This is a real-life example, the diagram
shown has been published by the performing company to prove their
performance. At the time when this photo was made, January 2006, the
company running the project was not aware that the project was
already one year behind schedule. How should they know? They made
out the real status of the project only some weeks later, and it was
painful for them to inform the customer and the media.
Finding a solution
There are two reasons for discrepancies
between project documentation and what is really going on:
The necessities of finding quick
responses in world of inevitable and urgent changes, especially
towards the end of a project when time and budgets are getting
tighter every day and the number of requests to do things
differently is going up. This is just an ordinary observation.
Lack of discipline by stakeholders. This
This is the solution: A project manager
should not add poor documentation to the uncertainty that has always
been a natural element of project management.
Updating and maintaining the project
documentation is an essential part of a project manager's job. It
has to be done proactively - ensuring valid plans and forecasts -
and reactively - the documentation should reflect the last known
status of the project.
It will cost time and other resources. If a
project manager doesn't find the time for this work, other work
should be delegated.
Maintaining a valid documentation is costly,
and one will never be 100% successful. Not doing it is risky and
will potentially become even more expensive.
Can Insight Tree help?
Every tools which helps planning and
documenting a process can help. Insight Tree helps documenting
decision making processes in order to:
Verify the integrity of the process.
Have a clear distinction between change
and variance - decision and chance.
Gather lessons learned later, when the
expected outcomes have occurred - or not.