Every project should be defined as accurately and fully as possible before it is allowed to start. The investor must know how the money will be spent and what benefits can be expected in return, the contractors must know the extent of their commitments before the contract is agreed. Figure 2.1 illustrates that project definition is a continuous process, beginning before a project can be authorized and not ending until the project has been completed, when its final as-built state can be recorded.
Projects Which are Impossible to Define Accurately
Although this chapter is about defining a project, a few proposed projects are so surrounded by uncertainty that they cannot be defined adequately before work starts. If an investor still wishes to proceed with such a project, there are safeguards that can limit the exposure to risk.
Limiting the Risk in Projects that Cannot be Defined at Birth
Projects for pure scientific research are an extreme case of initial uncertainty. Chapter 1 mentioned how a step-by-step or ‘stage-gating’ approach can be used to authorize such projects, releasing resources in controlled amounts so that the risks can be kept within defined bounds. Each new tranche of investment will depend on the satisfactory outcome of a periodical project review. If the outlook is not good, the plug can be pulled on the project and all further expenditure stopped.
Stage-gating is a valuable method for the damage limitation of any project that cannot be defined with certainty in its early days. However, people working in a stage-gated project are unlikely to be well motivated because they work under the constant threat of sudden project closure. If the employer cannot guarantee equivalent alternative employment on other projects, some staff might decide to end the uncertainty by seeking safer employment elsewhere.
Avoidance of fixed-price contracts
A commercial contractor whose role in a project has not been clearly defined can accept the order with some confidence if the payment arrangements, instead of being fixed-price, guarantee reimbursement of the contractor’s costs plus reasonable fees or mark-ups for profit. Such reimbursable project terms should ensure that the customer or investor bears all the financial risk. But even with the promise of full cost reimbursement, poor project definition can still cause difficulties for the contactor. It is always inconvenient to commit resources to a project whose duration is unknown and which is liable to be cancelled at short notice.
Provisional cost items in fixed-price contracts
Understandably, contractors are unwilling to quote fixed prices for projects that cannot be fully and accurately defined before work begins. On the other hand, customers generally prefer to sign contracts where the prices are fixed, so that they know the extent of their commitments and can set their own budget limits with confidence.
Contractors (particularly for construction projects) often deal with this difficulty by listing and cost-estimating separately any parts of the project that cannot adequately be defined before work starts. These unknown or high-risk items are listed as provisional cost items (or pc sums) and are excluded from the work quoted in the fixed price. Here is an example. Consider a project to refurbish a building where part of the internal roof structure is hidden from view and there is no access for inspection by a surveyor. When the contractor submits a fixed-price proposal for this refurbishment project, a provisional cost item would be appended estimating the additional charges that would be incurred by the customer should wood rot or beetle infestation be found when the roof timbers are uncovered.
Feasibility studies to improve early project definition
The investor faced with an uncertain outlook for a large project might start by commissioning a feasibility study from a consultant or consulting company to obtain more facts and expert advice. This approach is often used to appraise the technical, logistical, environmental, commercial and financial aspects of all kinds of projects that require a high level of investment.
A feasibility study for a large capital project can take years to prepare and cost millions of pounds. But a good feasibility study report can recommend the most effective project strategy and define the risks, as well as stating the achievable objectives and predicting the costs and resulting benefits realization.
Banks and other institutions asked to finance or guarantee large projects might want to see a satisfactory feasibility study report before agreeing to provide finance.
Government departments usually carry out or commission feasibility study reports for projects that are of significant importance. Two examples at the time of writing are Britain’s proposed High Speed Rail Project (HS2) and competing schemes for expanding London’s airport capacity.
Checklists are a good way of ensuring that no important task or cost item is forgotten when a new project is being evaluated. Contractors with good experience in their particular field of operation can develop comprehensive checklists for use when compiling project cost estimates and proposals.
One very simple application of a project definition checklist is seen when a sales engineer takes a customer’s order for equipment that is standard, but which can be ordered with a range of options. The sales engineer might use a standard pro forma (either on a pad or a computer), entering data in boxes and ticking off the options that the customer requires. People selling replacement windows use such methods. So do salesmen in automobile showrooms. Standard formats are convenient and help to ensure that no important detail is forgotten when the order is taken and passed back to the factory or warehouse for action.
Companies about to tender for large civil engineering, construction, petrochemical or mining projects can make good use of checklists. A suitable checklist might be used to ensure that all aspects of the building and performance of a new chemical plant are considered. Another case would be to ensure that the accommodation space and standards in a new building can be appropriately specified. Local climatic and geological data at an overseas construction site may have to be defined.
The designer or contractor of a construction project may not be aware of hazards such as high winds, potential earth tremors or flooding. It is also necessary to check whether or not any special statutory regulations apply in the region, particularly in unfamiliar territory overseas. Other data might cover national working practices and the influence of local trade unions, the availability of suitable local labour, facilities to be provided for the contractor’s expatriate staff and so on. Checklists are ideal in these circumstances. The example in Figure 2.2 includes items that might feature in a checklist for a project that involves civil engineering, mining or construction at a distant site.
Management change and IT projects
Internal management change projects can consume prodigious amounts of time, money and other resources but cause considerable harm to staff morale and the company’s operations if they fail. Inadequate project definition can be the root cause of such disasters and, here again, checklists are invaluable. But there is a big difficulty in compiling checklists for management change projects when compared with other projects. Organizations undertaking large internal change projects will probably do so very infrequently, perhaps even only once in ten years or less. Companies intending to make changes to their internal organization, procedures and IT do not have the experience of past projects that is essential for compiling checklists. This is where the employment of a competent consultant can be very beneficial.
Consultancy companies with relevant experience from their work with many past and present clients are able to give advice and help to define this kind of project. These companies do have the necessary experience from which to compile checklists. A checklist compiled by one consulting company (Isochron Limited) is shown in Figure 2.3.
Defining the Project Scope
Before signing a contract it is essential that the contractor knows exactly what the customer expects to receive in return for money spent on the project. The project specification should set out all the requirements clearly, so that they can be understood and similarly interpreted by customer and contractor alike.
Particularly important is defining the way in which responsibility for the work is to be shared between the contractor, the customer, and others. The scope of work required from the contractor (the size of the contractor’s contribution to the project) must be made clear. At its simplest, the scope of work required might be limited to making and delivering a piece of hardware in accordance with drawings supplied by the customer. At the other extreme, the scope of a large construction or process plant project could be defined so that the contractor handles the project entirely, and is responsible for all work until the purchaser is able to accept delivery or handover of a fully completed and proven project (known as a turnkey operation).
Whether the scope of work lies at one of these extremes or the other, there is almost always a range of ancillary items that have to be considered. Will the contractor be responsible for training customer’s staff and, if so, how much (if any) of this training is to be included in the project contract and price? What about commissioning, or support during the first few weeks or months of the project’s working life? What sort of warranty or guarantee is going to be expected? Are any operating or maintenance instructions to be provided? If so how many copies and in what language?
Answers to all of these questions must be provided as part of the project task definition before cost estimates, tenders and binding contracts can be completed.
The Contractor’s Strategy
When a project contractor evaluates a proposed new project, an important aspect of definition is the intended strategy for performing the work. Suppose that, after consideration of a customer’s enquiry, a contractor decides to prepare a fixed-price tender. The contractor must develop and record an intended strategy for designing and carrying out the work. Without a good understanding of the project requirements and the intended strategy for meeting those requirements, estimating, budgeting and pricing become very uncertain, even impossible processes.
Without a documented internal project specification for design and strategy, there would be a danger that a project could be costed, priced and sold against one design and strategic intention but executed using a different, more costly, approach. This risk increases when there is a long delay between submitting the tender to the potential customer and actually receiving the order.
Not Invented Here
It sometimes happens that engineers prefer to create a new design even though a perfectly adequate design already exists. They feel that they could do better themselves, or find fault unreasonably with the designs of others (even though those other engineers might enjoy a good reputation and their designs have been proven in successful earlier projects). This state of affairs is sometimes called the ‘not invented here’ syndrome. The results can be ugly. Two of many examples from my own experience follow; names have been omitted to avoid any risk of subsequent unpleasantness.
A British company won an important export order to design, supply and install specially built electronic patient monitoring equipment for the operating theatres of a European university teaching hospital. Following internal company reorganization, the project’s chief engineer resigned. His successor had different ideas and caused all design work completed or in progress to be scrapped and restarted. The design costs alone of that project eventually reached the same figure as the fixed price for which the whole project had originally been sold. That meant that the company had to write off the original design costs and bear all the considerable manufacturing and installation costs of the project itself. The project was delivered very late.
An American company with a very high reputation for product excellence sent a set of engineering and manufacturing drawings to its new British subsidiary. This was a complete, finished design package for a large heavy engineering project. The intention was that it would provide the brand new machining and assembly shops with work during the start-up period when the local British design team was becoming established. The drawings produced in America required ‘Anglicizing’, which meant that the British engineers had to check all the drawings and, with help from the new purchasing department, ensure that the standards specifications and lists of bought-out components would be suitable for purchase from British suppliers.
What happened was that the UK team poured scorn on the American design, and the whole project was redesigned from scratch at a cost of several million pounds.
Construction projects offer another example of work that has to be defined by specification. All building contractors of any repute work from detailed specifications. The requirement to satisfy the statutory authorities is just one reason for documenting specifications of building location, layout, intended use, means of escape in case of fire, appearance, and many other factors.
There are, of course, many design aspects of a building which can greatly affect its costs, including for instance the style of interior decoration, the quality of the fittings and installed equipment, lighting and air conditioning standards.
Disputes can be minimized, if not prevented altogether, when a contractor produces a detailed project specification and asks the customer to accept it before the contract is signed. Any changes subsequently requested by the customer can then be identified easily as changes from the agreed specification and charged as variations to the original order.
Specifications for Internally Funded Development Projects
Development programmes aimed at introducing additions or changes to a company’s product range are prone to overspending on cost budgets and late completion. One cause of this phenomenon is that chronic engineer’s disease, which I used to call ‘creeping improvement sickness’. Now people call this ‘scope creep’. All projects are prone to scope creep. An imaginary case example follows that illustrates this danger.
The Bikes ’n’ Skates Project
Bikes ’n’ Skates plc, a company producing bicycles and other wheeled devices, decided to add a children’s motorized scooter to its product range. The aim was to produce a colourful two-wheeled affair with a foot platform and simple front column steering. That is the traditional scooter design with which we are all familiar from our childhood days, but now a small petrol motor would drive the rear wheel. A simple brake on the front wheel would help prevent accidents to riders, pedestrians and property.
Fierce competition from cheap foreign imports did not allow Bikes ’n’ Skates to set high prices, although the company could charge a premium price because of its good reputation for making attractive, reliable, safe and high-quality products.
The scooter project was started in January, at the start of a new year, with the intention of having scooters in the warehouse for distribution and sale during the next Christmas season. The product was to be advertised in the run up to Christmas (which in the UK begins in July or August). In addition, models were to be exhibited and demonstrated at an autumn toy trade fair.
Management confidence was high. They had commissioned market research and the reports were favourable. The company had all the resources to do this job. By any standards this was a simple, small project that needed only simple budgeting and project control: it was not dependent for its success on state-of-the-art project management techniques. Everything should have been straightforward. There was nothing that could go wrong. Or was there?
The kick-off meeting
The launch of the new scooter design started with a meeting in the chief engineer’s office. In addition to the chief engineer the meeting included representatives from other involved departments, such as sales, purchasing and manufacturing. The other essential person at this meeting was the responsible design engineer (George).
Discussion was focused on setting George on the right track to create the scooter envisaged by the company’s directors. Thus George was given a set task with a number of objectives. However, these objectives were fairly broadly based and they were not written into a formal specification.
George emerged from the meeting full of ideas arising from the discussion and carrying his own notes and sketches. He was given some idea of target production costs, styling, performance, the preferred selling price and a date for stocks to be available in the warehouse for distribution and release to the market. He looked forward with excitement to testing the prototype himself, in the company car park. His kids could test it too.
George was bubbling over with enthusiasm. Most competent engineers become keen when given responsibility for a new project on which their creative abilities can be unleashed. After a few weeks’ activity involving George and the company’s prototype model workshop, George was able to wheel out the first experimental model of the new scooter. This model was subjected to test rides, reliability and safety tests and the critical attention of various experts. Among the witnesses were marketing staff, an industrial styling designer and production engineers from the factory departments that were going to manufacture the scooter.
Following successful evaluation of the prototype, the next stage in the project was the preparation of production drawings, parts lists and specifications from which the first batch of scooters could be manufactured and tested. As expected, this phase of the project took longer than the few weeks needed to build the first trial model. The production department decided to go ahead with tooling, and the production engineers and others began to plan for full-scale manufacture.
Apart from having to answer occasional production or purchasing queries, George had to endure a period of waiting. He became bored. His active mind was starved of work. This caused him to reflect on his design and led him to some second thoughts. On thumbing through the engine supplier’s catalogue he found that he could have specified a better petrol engine, capable of propelling a heavier, older rider and giving more power in reserve. An informal telephone call to the supplier revealed that the order for engines could be changed without cancellation charges. So George, not a faint-hearted person afraid to make decisions, told the supplier to change the order. Then, almost as an afterthought, George asked Bikes ’n’ Skates’s astonished purchasing manager to issue a purchase order amendment for the new engines, mentioning that these would cost 15 per cent more than the smaller original engines and take three weeks longer to obtain.
George had to redesign the scooter chassis to provide stronger fixings for the new engine at a stage when the trial production batch had just started. Only simple changes were needed, but the first trial batch (work-in-progress) had to be scrapped. Modified drawings and parts lists were issued to the production and purchasing departments. This change caused a three-week hold-up in the programme.
At length, and in spite of the delays and additional expense, the prototype batch was completed and passed back to George and others for evaluation. George was dismayed to find that, because the enhanced engine power had increased the maximum speed from five to eight miles per hour, the braking system was no longer adequate. It was indeed unsafe. That left George with the following two choices:
Revert to the initial design, using the original engine and chassis.
Modify the brake design.
George, a person of high principles, could not contemplate the first choice because the idea of degrading the performance did not appeal to him. He considered redesign and changes to the brake manufacture a small price to pay in return for the improved performance. Accordingly George made and issued new drawings for the brake components and assembly.
Once again the manufacturing department had to be told to stop work and cancel a batch of components. George produced the revised drawings as quickly as he could, but the project was delayed by four more weeks. However, the modified prototype scooters eventually passed all their tests, so that tooling and planning for full-scale production could begin. All design and performance characteristics of the scooter were now excellent, exceeding those envisaged by the marketing department.
A good result?
The resulting scooters were unquestionably very good. When the production line started the Bikes ’n’ Skates staff knew that they were making high-performance scooters. George was well pleased with the results of his labours and congratulated himself on a job well done.
The company’s management was not so well pleased. The oft-repeated phrase ‘time is money’ is as true in project management as anywhere, and it is usually safe to assume that if the planned timescale has been exceeded, so have the budgeted costs. Development costs for this small scooter project rocketed over budget. Not only did it cost more to design the scooter than intended, but also the manufacturing costs had become so high that the intended profit margin was severely reduced. The first batch of scooters was produced so late that only a preproduction model could be exhibited at the autumn trade fair, and there were no warehouse stocks from which to supply the Christmas orders.
This disaster could have been prevented if George had carried out his original instructions. But what exactly were those original instructions? George was given only vague verbal guidelines at the start of this project and it was easy for him to choose and change his own course of action. This simple example illustrates some of the pitfalls that can happen in a project that has no adequate project specification.
George did, in fact, design a very good product, but not the product that management expected. He allowed his own ideas to intrude and he lost sight of the original objectives. George fell into a common trap by allowing the best to become the enemy of the good.
The project should have been launched with a written specification.
A more effective check could have been kept on progress if a simple programme schedule (such as a bar chart) had used and included as part of the project specification.
No change should have been allowed without formal approval from higher management. Procedures for controlling changes are given in Chapter 11. It is enough here to note that the unauthorized changes would not have been allowed under closer management control.
George would have been kept on the right lines by the provision of a formal product specification and development programme, by the sensible control of modifications and, of course, by the-day-to day supervision of his superiors.
The Project Specification and Version Control
Given the importance of specifying project requirements as accurately as possible, it is appropriate to end this chapter with some thoughts on the specification document.
Although customers might be clear from the very first about their needs, it is usual for dialogue to take place between a customer and one or more potential contractors before a contract for any project of significant size is signed. During these discussions, each competing contractor can be expected to make various preliminary proposals to the customer for executing the project. Some of those proposals might suggest changes to the customer’s initial enquiry specification – changes intended to improve the project deliverables or otherwise work to the mutual benefit of both customer and contractor. In some engineering companies this pre-project phase is aptly known as solution engineering.
For some projects a practice known as simultaneous engineering can be used. Here the contractor’s engineering group works with the customer’s own engineers to produce and recommend an engineering solution which they consider would best suit the customer and yet be practical for the contractor to build. Solution engineering might last a few days, several months, or even years. It can be an expensive undertaking, especially when the resulting tender fails to win the contract.
Although it is tempting to imagine the chosen contractor’s engineers settling down contentedly to write a single, definitive project specification, the practice is likely to be quite different. The first draft descriptive text, written fairly early in the proceedings, will probably undergo various additions and amendments as the outline solution develops. It is likely to be revised and reissued more than once. The text will typically be associated with a pile of drawings, artists’ impressions, flowsheets, schedules, or other documents appropriate to the type of project. Accordingly all the documentation might suffer several changes and re-issues before the preferred solution is reached.
Projects of all types can undergo a process of early discussion and changes before a contract is made. For example, the requirements for a management change or IT project are likely to evolve as the various stakeholders make their views known, until a final consensus definition of the project task is reached.
So, as all these discussions take place, the original draft project specification can undergo a series of changes (usually while still keeping to the original objectives). So a number of different design and strategy solutions can often exist by the time a contract is signed.
A vital requirement when a contract is eventually signed, or a charter is approved for a management change project, is to be able to refer without ambiguity to the correct version of the project specification. The correct version is that which defines the project according to the finally agreed intentions. The process of ensuring this is sometimes known as version control. Remember that the latest issue of any document might not be the correct issue as finally agreed.
The only safe way to identify any document is to label it with a unique serial or identifying number, and augment that with a revision number every time the document is re-issued with changes. If there are drawings and other documents that cannot be bound in with the specification document, these attachments must be listed on a contents sheet that is bound into the specification, and the list must give the correct serial and revision number of every such document.
Then everyone can be reasonably confident that the project has been defined.