The Creeping Scope

Incomplete documents and scope creep - how accurate can project documentation be?

What some experts say

There are two common opinions in project management relating to documentation:

1st opinion:

"Whenever a problem or an issue arises, which is connected with incomplete documentation, the person who 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
▪	Contracts with the customer
▪	Contracts with subcontractors
▪	Management plans
▪	Scope statement
▪	Other planning documents (WBSs, network diagrams, resource schedules etc.)
▪	Change control documentation
▪	Configuration descriptions
▪	Performance reports
▪	Product and service descriptions
▪	User manuals
▪	... 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 uncertain outcome.

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 accountable.

2nd opinion:

"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:

A well-integrated 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.

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.

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

Since 1993, 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 frustrating.

Progressive elaboration

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 and interactions

• Developing a common understanding among all stakeholders

• 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 down.

• 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 misunderstandings?

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 project?

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).

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.

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 cheap.

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 anyway."

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 decision trees:

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 priorities.

• 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 payment.

Is it really a problem?

It is.

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 project.

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 ones:

▪	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 times.
▪	Network logic diagrams (if they are developed and maintained anyway!) show dangles: open ended network paths.
▪	Periods of availability of resources are not maintained.
▪	Resources are clearly over-allocated, resource-leveling is not applied at all.

This is my favorite one: Cherry picking and Data date inconsistencies:

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 should avoidable.

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.