CHAPTER 10

Law Nine: A Project Isn’t Finished Until It’s Finished

The “never quite finished” scenario is not uncommon at all scales of ­projects. Missing or defective parts should not be treated as a problem relating to warranty unless final acceptance has been given. So, clients should not sign off on final acceptance if there is still outstanding work, unless it is with a defined list of outstanding work and a required completion date, attached to a conditional acceptance document. From a strictly accounting point of view, warranty covers the repair of items, supplied within a project, that fail after their acceptance and before the end of the warranty period, but it is a common accountant’s trick to try to push costs from the specific project budget, which they wish to close, and onto the general warranty provision.

Let us consider the Kitchen project again. Everything is working, all the User’s manuals have been handed over and the final payment has been made; but there is just one little thing outstanding.

The decorative top of one of the expensive imported faucets (taps) was broken during installation, and the contractor “will be back to fix it as soon as the replacement arrives.” But the contractor’s staff are now fully engaged on the next contract, they are busy doing the practical work they are trained to do, for a different client. Trying to purchase one part of a component made by an obscure manufacturer in a foreign country, through an agent, is not only outside their competence but is also now a very low priority job and just too much hassle. Since the packaging has been thrown away, they don’t even have the model references easily to hand, so the customer is left with a cosmetically unfinished project and has no financial leverage with which to force its completion. The best defense for any customer caught in this sort of situation is to make such a fuss with the supplier, nowadays using social media or in some cases using low cost legal action (in the UK use the Small Claims Court) that it is less work and trouble for the contractor to deal with the problem than with the complaints.

Arrange Back-to-Back Warranty from Subcontract Suppliers

The main contractors of any project can find themselves losing a lot of money if the warranty of third party equipment that they have ­supplied within their contract, runs out before their own. For example: in a ­project to build and equip a University workshop the main contractor’s ­warranty ran for 12 months after hand-over date (acceptance) but one of the machines was covered by its manufacturer’s warranty of 12 months after delivery; but had to be delivered and installed six months later, thus leaving the main contractor exposed to the risk of a warranty claim for the six months.

Project company purchasing staff should negotiate back-to-back warranty cover for all equipment modules within each project, this may impose conditions on the storage, inspection, and commissioning of the equipment but it is preferable to being exposed to warranty claims on subsupplier’s equipment.

Dealing with the Last Snags Demands “Plodding Persistence”

The resolution of snags is not exciting work, but it is as vital as any other stage of the project. It requires a special type of character; a persistent, pedantic, negotiating administrator.

The resolution of post-acceptance snags has a number of inherent ­problems and it is my contention that the original project manager may not be the best person to be charged with their resolution. Whereas a project up to the stage of conditional acceptance requires the classic skills of project and site management, the resolution of end-of-project snags requires a special type of character; a persistent, pedantic, negotiating administrator. Resolution of snags is not exciting, but it is as vital as any other stage of the project.

The longer snags lists remain open the longer and more expensive they become, it is too easy for the project contractor to slacken back on the resource committed to a project once the customer is using the facility. It is also true that the customer’s definition of long outstanding snags will harden and widen the longer any remain open.

The real difficulty for the “snag sorter” will be that most of his or her management’s interest and resources will have been transferred to current and new projects, making sorting out the final snags of an old project a rather thankless task. This is particularly true if there is little or no financial incentive to supply the resource to a project which has been “taken to turnover.” Snagging is about small details and tenacity on both sides of the contract.

After reading the foregoing it may appear obvious that a client should not accept a project unless all acceptance criteria are met however, it is often impractical or unnecessary to adopt such a policy. My classification of post-acceptance snags which any client may feel content or obliged to accept are as follows:

  • Snags that have a clear resolution for which the contractor can make an accurate financial provision but that for reasons of disruption to the client’s work cannot be carried out until some fixed future date. Typical examples would be: re-laying a floor section cosmetically damaged during installation of project modules or replacing some damaged part of a building trim that involves disruptive work during normal work periods and has to wait for a scheduled shutdown.
  • Snags that are directly due to the client being unable, through lack of materials or trained labor to test or use the new facility to its design capacity.

Typical examples of the second type are in mass manufacturing ­projects where sufficient materials to meet the design production rate are not available, or the client has failed to train or recruit suitable staff to operate an IT system by the time the system is ready to be fully ­trialed. Clearly this whole area can lead to major disputes, but the danger signs would have been evident to the project management and the greater ­project community well before it came to be a contractual dispute.

Relying on the failure of others for your own project’s success, or to hide your own failures, is a dangerous and foolish tactic.

I once had a client who was contractually committed to providing three specially built engines for the commissioning of a major automotive project by a well-documented deadline. My own program was extremely tight, and it was widely believed by the client’s staff that I would run four weeks late. A few days before the deadline the client admitted that he had been relying on my failure instead of reporting on their own problems, consequentially the project, and certain individuals’ careers, stalled.

Relying on the failure of others for your own success, or to hide your own failures, is a dangerous and foolish tactic.

Sometimes we may meet snags whose resolutions are not, within “sensible limits,” technically or financially viable. It sometimes happens that the performance of a facility, while meeting the quality target specified, fails to meet the process or cycle time. As has already been mentioned in this book, one of the most dangerous clauses in a project specification, and one that project designers must be very wary of accepting, is when the description of a process contains the phrase “Time is of the essence.” An example I have had to deal with is in the case of industrial refrigeration plant where the final temperature, of minus 40°C is met but it took 12 hours from ambient, rather than eight hours, to reach it. There can be a multitude of reasons why the theoretical (calculated) chill down time can’t be achieved but after all the accessible sources of heat leakage had been dealt with the only answer would have required a large and expensive upgrade in the chilling capacity and therefore energy supply to the client’s whole facility. Unless such a short-fall causes gross operational problems, which in this case it did not, most clients would find a solution to such a problem by negotiation, perhaps through a reduction of the contract price and a change in their operational programs.

Failure to Complete Can Be Disastrous

There have been cases of companies that have collapsed due to the number of unfinished, post acceptance, snag-ridden, projects. In the mid-1970s one of the first equipment supply companies to develop digital control in the automotive industry had to be sold for a nominal sum to a ­competitor because of the drag on resources and cash-flow caused by unfinished ­projects. I was charged with the task of resolving the issues of six of the largest projects and it is interesting to consider the breaches of the Laws defined in this book that caused the problems and to mention the ­methods of their resolution:

Two of the projects had been undertaken with a significant difference in intention and interpretation of their specification (Zeroth Law). In one case a major subcontractor had been allowed to proceed with the supply and installation of plant completely at odds with technical standards documented in the specification; not only a failure under the Zeroth Law but also a complete failure of project management. The equipment had to be completely rebuilt at significant cost to the main contractor; as is often the case, the recovery of the costs from the subcontractor would have involved legal action, the cost in time and money of which would have exceeded the original losses.

Another of the projects proved to be a breach of Law 4 because it tried to defeat Newton’s Laws. The designers of a very complex, torque recirculating, component test rig had not correctly calculated or understood the force vectors involved, perhaps believing that software control could sort out the problems of “mere mechanicals.” The resolution process, which resulted in a facility that operated well above the original energy consumption specification, was horribly long, costly, complicated and resulted in at least one working life within the client’s organization being ruined.

Of the remaining projects all but one, which had to be settled by a reduced specification and price, were completed by persistent, detailed effort that would have been much cheaper and easier if the work had been carried out by the original project team, but which had never been allowed continuity of work and had not finished their job properly. What happened was that as soon as the impatient clients had made any commercial use of the project machinery the supplier had lost all interest in supplying documentation, as-built drawings and sorting out outstanding missing spares lists. This had caused intense irritation to two major manufacturing clients who had consequently withheld outstanding payments and all further orders, leading to the project company’s collapse.

These are typical examples of this Law 9 in that they were never fully completed during the normal course of the project, when the expertise was available.

Warranty Costs Can Be a Measure of Project Failure

Well run companies make a financial provision for the possible warranty costs arising from each project based on experience and the perceived risk. If one large warranty claim is made during the period it will not necessarily indicate a problem of process or management within the project, but all warranty claims need some project management focused analysis. For example, early component failures can be indicative of plant damaged by being installed in inappropriate conditions, as warned against elsewhere in this book.

The most difficult claims to anticipate are those resulting from behavior of the project’s client that had not been anticipated by the designers or suppliers, a problem faced in both domestic and industrial contracts. Unless the client’s usage verges on vandalism, these problems indicate that the original sales function or the project design team failed to understand the environment into which the project was installed; they didn’t do their homework.

Warranty claim data should be carefully monitored by project teams; too often they have moved on into new exciting tasks so valuable lessons that have cost good money, are not learnt.

Training and Its Role in Project Completion and Success

A project can’t be considered as finished until the users are trained and competent in its use.

This statement is completely scalable, from the cook who is left with a pile of component manuals but can’t work the child-lock on the induction hob, to the maintenance mechanic who is unaware of the location of in-line filters in a cooling water system.

Inadequate or inappropriate training of the maintenance staff and the operators of new plant containing novel technology frequently causes problems. So many projects fail to realize their full potential or suffer subsequent maintenance problems because the inadequate training of the end users.

At the domestic level, we have what used to be called the “video machine syndrome” when the, possibly elderly, users of, for example, a new and complicated “Smart TV” system spend the first few hours struggling to learn how to obtain their required functions and then put the multipage, multilanguage, User Manual in a drawer never to be used again, thus denying those users of much of the advanced functionality they have bought: until grandchildren come to stay! But this is not exclusively a feature of elderly people: how many of us exploit even half of the useful menu options of our digital cameras or word-processing software?

At a large industrial scale I have sat in the beautifully appointed office of the CEO and seen the bookshelves showing off pristine, unopened sets of Training and Maintenance Manuals for complex plant installed in his factory; plant which was operating below optimum performance and which was the reason for my visit.

Sadly there are many instances when much of the recommended, quoted, and required training was cut out of the final order to save capital costs in the belief that it could be transferred to operational budgets but never is.

A training method that I have found to be particularly beneficial when installing complex machinery or modern building control systems is the secondment of one or more of the client’s maintenance staff to the contractor’s installation team. If handled carefully this type of “training by osmosis” is a very effective technique for a client’s organization to absorb a complete understanding of the form and function of their major investment; providing of course that they have suitably trained individuals who can be seconded, free of charge, to the contractor.

Such an arrangement can be particularly useful for a client’s electrical maintenance department. Under such an arrangement the contractor gains an extra pair of skilled hands and a source of local knowledge, it is a “win–win” strategy, but clearly such secondment of client staff to an external installation team only works when the seconded staff are up to the standard required by the contractor. I have only one experience of such an arrangement being a minor disaster when we found out that our new coworker, who had never before worked with multicore individually screened control cables, suffered from a type of color blindness. Since these multicore cables use lots of, quite subtly, different colors and since the individual concerned did not realize that he suffered from a form of anomalous trichromatic vision there were rather a lot of faulty connections made before the problem was discovered and a lot of re-work had to be carried out.

A Project Is Not Finished Until the Final Documentation Has Been Delivered

Sometimes the difficulty in resolving the problem of the lack of “as built” electrical drawings can be significant and becomes a snag item, to be handed over at a fixed post-acceptance date. The problem is usually caused because the staff who had carried out the commissioning had to carry out small circuit or software modifications; these have to be ­correctly recorded and incorporated into the documentation, by the contractor’s design staff, before being passed to the client.

Here lies a very important rule:

Site modifications of projects must be recorded by the installation or commissioning staff, checked and approved by the design staff, then incorporated in the final documentation supplied to the customeras soon as practically possible after the event.

Believe me when I tell you that, if the Maintenance Manager of a continuous process industry finds that their staff can’t fix a process-critical breakdown, because the drawings you supplied are out of date, then your CEO is going to get a phone call that will certainly spoil his or her day!

The importance of the specification of the documentation to be ­supplied to the client in support of any type of project is sometimes overlooked by both client and contractor; this can lead to a serious dispute around the time of project handover. Loosely written contract terms such as:

“Three sets of complete documentation will be supplied, bound and indexed,” is open to a range of interpretations. The supply of documentation is particularly difficult for the main contractor when it has to include detailed operation and maintenance manuals for a large range of third-party components that will have been created in many ­different formats; this can represent a specialist librarian’s cataloging task—it is not to be under estimated.

Equally, overly or inadequately prescriptive specifications for documentation can both create serious disputes and are also often overlooked by suppliers during the early stages of the project process when there are “more important things to worry about.” The worst types of clauses are those that demand detailed, that is manufacturing, drawings of project components; in some cases this can justifiably be deemed unacceptable where it represents effectively putting a company’s intellectual property into the public domain. The clients’ justification may typically be that they wish to have the drawings of all components that could be deemed as “wear items” so that they have the option to manufacture them rather than purchase from the original manufacturer at “spare part prices,” this needs to be sorted out by negotiation at the pre-order stage, not left until the project hand-over meeting.

Where in the Project Life Cycle Is It Completely Finished?

The identification of the point at which a project is considered to be finished varies with the roles involved; for many subcontractors it will be marked by receipt of the final monies owing and for most domestic clients it will be when they can make full, snag free, use of their new facility and all the detritus of the project cleared away. But this, rather linear, view of the project process is not in tune with modern company quality policies of “continuous improvement” because it doesn’t lead to the lessons learnt, within the whole project community, being recorded or shared; nor does it address ongoing maintenance or end-of-life planning, all of which we need to consider.

Even the smallest domestic project may be a journey of discovery for the participants who have been exposed to new skills and have learnt hidden details of the structure of their house or land; skills and knowledge that will evaporate with time and not be shared unless some sort of retrospective review of the project is made and some basic records kept.

What constitutes the end of a project, and particularly product development projects, has changed over recent years with the advent of ­product “end of life” planning and, in Europe, the EU directives such as: The Waste Electrical and Electronic Equipment Directive (WEEE ­Directive). This requires manufacturers to include in their product design the methods by which the components and materials may be recycled when the product comes to the end of its life, therefore, at the very least the supply project has to supply the client with the information that is compliant with WEEE.

Project Maintenance: Important But Often the Most Thankless Tasks of All

From private homes to large organizations if nothing breaks down, because behind the scenes someone is carrying out regular preventive maintenance, very few people will be appreciative or even aware of the maintenance work or the role. But, when the boiler fails, or the elevator breaks down then maintenance is a high-profile issue.

My habitual visual test of the state of health of any organization and its management, from a hotel to a large factory, is to look up at the ­gutters; if grass and seedling trees are visibly growing up there then they either don’t care about the fabric of their facility, or they can’t afford to care; either way it’s a bad sign.

For managers of large nationally funded projects, right down to those of small community ones, it is too easy to concentrate on the exciting creative part of the task, including raising then controlling the capital expenditure but then to forget about, or greatly under-estimate, the funding and long-term management of the project’s maintenance.

Around the world in the lead up to the year 2000 there were many communities and cities that planned Millennium projects. Given one or more inspirational leaders, a group of dedicated workers, and regulatory permission, such projects usually achieved their targets. However, 18 years later many have run into problems and some have closed because the communities have difficulty in finding sufficient committee members to carry out the “boring” roles of secretary, treasurer, nominated key holders, grass cutter and the person to call out in the middle of the night when some sort of emergency occurs. They have also experienced difficulty in finding money to carry out essential maintenance work because rarely did the original financial planning include provision or raising of funds for basic maintenance, far less major repairs. At best this error in project planning will lead to large, unbudgeted repair bills and, at worst, has led to closure of the facility.

All community projects should have, as part of the initial business plan or grant application, a realistic post-completion maintenance plan.

There are many examples of major infrastructure projects suffering ill-advised cost cutting due to a lack of post-completion planning.

In New Zealand, the Auckland Harbor Bridge that joins the North Shore suburbs with the city was opened in early 1959. During its design phase the budget, and therefore its specification, had been significantly cut; in addition to cutting two traffic lanes and all pedestrian and cycling paths, the client-initiated cuts included any form of maintenance galleries, so it proved to be impossible, once erected, to paint the structure! Maintenance galleries were the first modification to be added at far greater cost than if they had been originally included, followed by extra traffic lanes (the famous, or infamous “Nippon Clip-on” structures); by great good fortune the designers had retained the original structural design so that the bridge was sufficiently strong to take the extra weight of all its additions. In addition to being an example of lack of appreciation that such projects are never finished and that you must make provision for maintenance, the Auckland Harbor bridge project was and is, in the words of the NZ Herald newspaper: “a ringing testament to the peril of short-term thinking and penny-pinching.”

Post Project Reviews

A suitable subtitle of this chapter could be “The project process should not be seen as linear but rather as a circle,” meaning that the recent experiences of the project community should be shared and turned into lessons learnt by all of that community. It is a tragedy therefore that so many post contract reviews are only held in the form of a financial post-mortem and only when a project has failed to meet a contractor’s budget or exceeded a client’s budget. These “who is to blame” meetings mean that the positive lessons that could have been learnt are overshadowed by solely negative, albeit, necessary lessons. Unless a well-managed, broad, review takes place lessons such as improvements in certain practices, that should become standardized, or errors that were made which should in future be avoided, remain only with the individuals involved and may not even be shared with their colleagues, far less with the wider project group. Post project reviews by a third party or academic institution are usually confined to the study of large Government sponsored projects when their poor outcome has become the subject of public outrage. If such reviews take sufficiently long, if the participants are carefully restricted, and project organization being examined is sufficiently fragmented, nobody will be found to be at fault and nothing useful will be learnt by the wider community.

From all this it should be clear that in any post project review the wider the participating group the more holistic and useful will be the views shared. However, the task of organizing and running such a review is not easy because there is always a reluctance for individuals to expose themselves to criticism and for companies to “do their dirty washing in public.”

From personal experience, I think the wide post-project review works best when the client calls for and organizes the event, appointing a disinterested Chairperson. Of course, it helps when there is a well-established project community and the likelihood of further contracts.

So, what sort of project process inefficiencies do these “time wasting” and potentially embarrassing reviews reveal?

I am aware of an example which revealed the cause of serious ­project delays and taught lots of participants to change their practices: it ­concerned the design and commissioning of an intelligent Building Management System (BMS), the real cause of serious delays caused by this item was revealed through a post project review:

Almost all modern factories and large, multiuse buildings are fitted with some sort of BMS; in the case of buildings housing a number of ­separate processes, such as commercial or university laboratories, the functional logic required to ensure the correct actions are triggered by any combination of inputs or alarms can be extremely complex.

A large laboratory project completion was delayed for several weeks because of the late delivery and disruptive testing of the BMS system’s software.

The post-project review had to drill down to a key, but previously “invisible,” function within the main contractor’s electrical design department. Here a young, intelligent, engineer had been given the task of designing the “logic tree” that would eventually be programmed into the BMS computer. It became clear during the review that this was an impossible task for a junior individual, lacking the seniority and authority to organize and demand attendance at, multiparticipant, design reviews during which the client and several expert suppliers needed to agree on the actions to be taken in their areas when the BMS noted alarms at different levels of importance. The young man in question had worked himself to near nervous collapse, not daring to report his inability to get the information he required. The supplier of the BMS system had not complained of the lack of data during project reviews because his own software department was unaware of their commitments to the project program and their management had not asked the right questions, being distracted by a different and larger project. The result of the review was for all project participants to recognize that, in future the BMS logic tree document was a key deliverable, and all versions would be made available to the Project Community in an easy to read matrix format. Furthermore, a senior member of the project team would call one or more specific design reviews so that the system could be “signed off” before the software coding was due to commence and an off-site simulation and test system was introduced to reduce disruptive on-site activities.

How a Contractor Leaves Site Leaves a Lasting Impression on the Client

Rarely have I seen on the GANNT chart of any project that I have been allocated a final task entitled “Final Site clearance and tidy” with labor and costs allocated to it, yet it is an important job, which if ignored leaves a bad impression of the contractor. Domestic contractors are particularly vulnerable to loss of reputation via comments on social media. The lesson is: tidy up before you leave.

At both extremes of the project size range organizing and funding a site clearance should not be a big problem. The individual contractor at the small end, and the team at the large end, will have suitable personnel to do the job, they just need to be told to perform the task. It is the medium sized, multidisciplinary projects that seem to have the ­problems. The final tidy-up, after all the cable covers have been put on and the false-ceiling panels are back in place, is classed as an unskilled, even menial job: so who does it?

The commissioning staff will have left, and anyway many of them believe in the existence of the tidy-up fairies who sweep up all the bits of cable off-cuts and other detritus they have thrown on the floor, so to do the job properly the project manager needs to hire in a team or an individual to do the job. This expense can be met with resistance from the finance management who will, quite rightly, wonder why the individual team members didn’t clean up their own junk. My advice is: just get it done, even if you have to use the broom yourself, and leave the site as you would have wished to find it if you were the client.

Some Points to Remember from Law Nine

  • Clients should be very careful in accepting a ­project and ­paying final invoices while “snag items” remain ­unresolved; retention of monies is the only real leverage to ensure ­completion.
  • Taking the profit from a Project before its complete is foolish; taking the profit prematurely from one project to bail out another is the way to ruin.
  • Dealing with the last items on the Punch List demands ­“plodding persistence” and suitable funding.
  • Neither supplier nor client in any type of industrial or domestic project will benefit from trying to “save” money by reducing or cutting the training of Operators, Users, and Maintenance staff.
  • Post Project Reviews, if well run and attended, with a ­constructive agenda are a key tool for the development of project skills. If used solely to allocate blame for problems experienced, they are a disaster.
  • A project isn’t finished until the site is cleared and tidy.

A project can’t be considered as finished until the users are trained and competent in its use.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.105.255