Project control - project creep

Senior managers and directors are generally great in the role of defining the broad strategy of their organisation. However, the same people tend to be not so good in the process of detailed specification for project requirements. A consequence is that when the budget funds for a new project is agreed and authorised it is usual that some features or services will be omitted from the authorised project. This omission  might have happened accidentally or intentionally.

As the the project progresses it is inevitable that senior managers, clients, team members will identify some feature or facility that "should have been included" within the project. It may be the proposed variation in the Project is a reasonable and sensible change. In those cases the changes can be incorporated by the variations route. In the cases where the Project Manager thinks the proposed change is stupid or would cost too much, or cause too much project delay he/she should reject the proposal via the variation process. No doubt the time will arrive when the project scope will have to be "frozen" in order to achieve a delivery date, but it always possible to parcel off some features to be delivered after the main implementation date.

The worst kind of project creep occurs when a senior manager/manager declares a related service feature must be included in the project even when it is nothing to do with the original project. The senior manager will even override the views of the project manager regardless of the impact on spend or the impact on project resources/time table. In those cases the project manager must be careful to document the impact in advance and then ensure the consequences are brought to the attention of the requesting manager/client. If there is no change in the senior manager's/client's demand for inclusion then the origin of the request and consequences should be included in the formal project progress documentation. The worst thing the project manager can do is to attempt to absorb the additional cost and resource time. A similar process should be followed where the senior manager/client instructs that a previously agreed element of the project should be removed.

A recent example I've seen of the latter is on a project to install a software based stock control system in the stock rooms for the consumable clinical equipment used in the operating theatres of a major hospital. Their existing manual systems are frequently out of date and the local operations managers have no idea of what is actually in stock. The project manager is rolling out this new system storage room by room. The project involves training staff in the new techniques and loading inventory details on the stock database. However during the project lifetime there was a major move from one hospital site to a new building. A substantial amount of stock, millions of pounds worth, was disposed of on the grounds of "hygiene", but in the rush of the move the stock disposals were not recorded in the manual records. A couple of months later a sample audit revealed the consequent discrepancies in the manual stock records and spreadsheets. 
A senior hospital manager diverted staff resources from the new stock control project team to undertake a full stock inventory exercise in order to be able to report to the Board the "reasons" for the difference. This "simple" command created an unauthorised extra £35,000 bill for consultancy and delayed the stock control system project by a month. Rather than use in-house clerical administrators to perform the inventory, expensive external software consultants were used to count scalpels. The senior manager subsequently tried to deny that she was the cause of overspend and delay to the project, but the project documentation showed otherwise.