CHAPTER 3

Law Two: Paper Is Cheaper to Change than Concrete

The old motto “Think thrice, measure twice, and cut once,” which my six-year-old Grandson has been taught to recite, is still valid for the carpenter engaged on a home project and it’s still valid, but more difficult to visualize, when scaled up to the industrial scale, when saving concrete or metal by “wasting” paper is equally relevant.

Being served a demolition order by the City’s Planning Office because the owners have rushed ahead and built a barn before getting the required permits, or starting early in building a large electrical cabinet before discovering that the German VDE regulations require a very specific and completely different component layout to a standard product, are just two personally observed instances of breaches of the Second Law. So, clearly inadequate planning and poor site coordination are the easiest ways of breaking this law thus causing project problems or even failures. Note that in this context inadequate and poor do not describe the same type of fault. An otherwise very good project plan may be inadequate in its scope because of the oversight of an unenvisaged problem and therefore result in a poor outcome, while poor plans are created by poorly trained or poorly managed workers.

Think thrice, measure twice and cut once

Don’t Emulate Those Public Utility Projects that Never Share Paper or Pavement

The general public most commonly witness breaches of this law in the streets of their home towns or highways; although undue haste in starting a domestic project can create some embarrassing examples.

I once lived in a small town where, for most of one year, the main street was repeatedly dug up by different utility companies working in isolation, one after the other. Clearly any two or more of the companies could, by using the same trench have shared the cost and reduced the ­disruption to the public, or at least done the work at the same time using the same excavation contractor. A resident asked, in a letter to the local paper:

What idiots decide to put new road surface down then let them dig it up and make it a mess again? Surely it would be easier and cheaper for checks to be done to the relevant companies who maintain water, gas, electric or sewerage to make sure no work needs to be carried out before laying a new surface?

Do ALL the work first, then put down a new road and that way save our local tax money—idiots!

So if the answer is so obvious, mutually beneficial and the paperwork changes required quite simple, why is this sort of breach of Law 2 so common?

In such a case as described earlier there was nobody, in either the companies or the public authority, who considered that they had any incentive to reduce the, already allocated, budget or to save money. The employees of the local Council didn’t consider they had any authority and each of the companies had budgeted a specific time and cost for the complete project, that is: excavation, laying of utility, and making good. They had no formal or informal contact with any of the other companies and had gained permission from junior officials whose job was simply to process paperwork. The people that suffer are the general public, who have to pay the cost of the inefficient working practices in their utility bills and suffer the inconvenience of having the town’s main street repeatedly dug up.

Good project management requires introducing and maintaining, through all means available, a sense of the mutual responsibly, reliance and collaboration in and between project teams.

I have carried out many post-project reviews, as part of my research into causes of unnecessary project expenditure and have been driven to distraction by the apparent lack of interest of organizations to collaborate for the common good.

In the United States, there are specialist companies that offer a service of Utility Coordination. In their corporate literature, a typical statement is:

Utility related conflicts can cause delays and significant cost added to infrastructure and roadway construction projects.

In some States they have obviously concluded that paper is cheaper to change than asphalt and, having learnt that they can’t rely on individual companies using common sense and liaising on matters concerning a common work area, they have imposed such collaboration through a third party.

One lesson learnt from recognizing this tendency for individual, departmental, specialist, company and tribal isolationism, is that good project management requires introducing and maintaining, through all means available, a sense of the mutual responsibly, reliance, and collaboration in and between project teams.

Rushing to Start—The “More Haste, Less Speed” Phenomena

Breaches of Law Two, in their most obvious form can frequently be observed in domestic projects. Once the new kitchen, bathroom, or garden remodeling has been decided upon, in outline but not in details, then there is a strong temptation to rush into the job; once the Dumpster1 has been placed in the driveway then everything is ripped out.

It is at this point in the project that the problems, which might have been discovered through more judicious planning and inspection, may be revealed.

With older houses (and some new ones) it is a really good idea to lift a few floorboards and take off things like bath panels to find out what crimes against good design and building practice have been committed and covered up by the previous property owners, or the original builders, before drawing up your final design.

Hiring a mechanized digger and making a trench in which to plant a large border hedge, then cutting through the sewer pipe shared by the whole street did not make an acquaintance of mine popular in his new neighborhood. A site drawing, in A0 paper format was available in the municipal planning offices but it was used after, rather than before the excavation and subsequent, expensive, repair.

In another case, demolishing an existing bathroom and then finding out that the old structural timbers prevented the, newly located, bath and shower outlets from running into the existing drain meant a radical redesign, cancelled orders and a couple of months of bathing with friends and parents.

Any good garden designer would advise new owners of existing gardens to wait a full year before deciding on what new planting should be done—you never know what’s down there and what they produce until you’ve seen the garden through all its seasons.

Gaps in the Paper Chase

Everyone has to know, has to be informed, when paper, be it the ground-plan, a design detail, the program, or the budget has been changed. Unless everyone who should know, does know, which bit of paper contains the up to date information, they will proceed in ignorance and according to an out of date bit of paper giving an incorrect model of the project.

The horrible cliché: We’ve all got to sing from the same hymn-sheet, is never truer than within a project team and wider project community.

There was the case some 30 years ago of a city redevelopment scheme included in which was a new Hotel and a Theatre that were either side of a busy road but joined by a pedestrian bridge. The bridge was fabricated off-site and when, with a large crowd watching, it was lifted into position and, only then, found to be significantly too short. The fault occurred when, early in the project it had been found necessary to move the position of the Hotel a short distance away from the theatre because of preexisting ground conditions, in all other respects the two buildings remained as originally designed. Historical details have proved impossible to discover but it is clear that the bridge was built to the original detailed design drawings, and the required changes to the overall length, necessitated by the moving of the hotel, were never made; the bridge subproject literally fell between the two building projects which had continued in isolation from each other. Perhaps there was no procedure for distribution of the updated layout or if it was distributed its importance to a geographically remote fabrication subcontractor was not appreciated. I think that if I had worked for the bridge builder, or in the central project team, I would have paid a site visit, perhaps in the early hours of the morning when traffic was light and put a measuring tape across the gap before fabrication started.

Lawyers grow rich and projects lose money when such large holes in a project appear. So, we ought to discuss paper control further.

What Constitutes Project Documentation?

The first rule is to impose on the whole document community what does NOT constitute project documentation; the following rules are suggested:

  • Messages sent via Twitter or Facebook or any other social media system are NEVER to be considered as project documentation and if used to conduct project business WILL be considered as a breach of project protocols and confidentiality.
  • Text (SMS = Short Message Service) messages from or to members of the Project community may be used only in extraordinary circumstances but have be confirmed by an appropriately distributed e-mail or via the project communications network within the same working day. Remember that predictive text, if not noticed and corrected, can corrupt the meaning of a message; comic perhaps in private life but dangerous in project work; which is why text messages need to be confirmed by different media.

Some will say that modern social media is an acceptable platform on which to conduct project control but, based on observation of community projects thus formed and the problems they have, I will strongly disagree. The clue is in the generic and specific titles: “social” media serves a social purpose and is best used in an undisciplined manner, while my copy of Thesaurus likens “Twitter” to “prattle, chatter, blather and drivel”; doesn’t sound like a serious project tool to me!

I will keep bleating on about the need for a project manager to keep a diary, in which to record important phone call or face-to-face conversations which would otherwise go unrecorded, such a book may be the most important project documentation you possess.

E-mail nowadays is the default means of communication within any size of project community, but there are a few sensible rules that I would recommend:

  • If you rely on e-mails you should use a system that allows you, in a few important cases, to receive automatic, date and time stamped, receipt and opening confirmation. This facility is usually confined to software suites designed for commercial use and not present in personal e-mail systems.
  • Crack down on those members of the project community who repeatedly broadcast every e-mail they send, to the whole community, when the message is only relevant to a very few. This is noise that nobody wants to handle.
  • Generally the use of blind copies (Bcc) should be forbidden within the project community where it indicates the that someone is “playing politics” and rarely serves a useful purpose. There are incidences when Bcc is useful, but it should be reserved for senior staff dealing with external organizations.

Tools of the Project Trade

The task of recognizing task dependences and planning the coordination of the thousands of tasks involved in highly complex projects, together with their duration and the identification of resources required led, in the 1950s, to the development, by the U.S. Navy, of the Program Evaluation and Review Technique (PERT).

PERT tends to be confined to major multidisciplinary projects which contain research and development tasks; examples are the creation of aircraft, warships, and major infrastructure projects such as the Channel Tunnel between France and England. The methodology, which includes Critical Path Analysis, requires trained practitioners to design and maintain the system; but they need input from specialists in order for the model to work. While PERT tends to be too complex for the average run of medium sized or small projects, combined hardware plus software projects that include product development are well suited to the discipline, as are projects that similarly have several, parallel, development activity paths.

To most of the general project community, a much more familiar and intuitively useable project tool than the PERT chart is the Gantt chart.

The Gantt Chart: Its Use in Planning and Misuse in Reporting

Many projects are planned using a variation of the Gantt Chart, using such software programs as Microsoft’s “Project” or GanttProject, the ­latter being one of several free, open-source, project scheduling tools. Gantt charts, which allows the author to plot task order against project duration, is widely used, from the smallest up to the largest projects.

In the wrong hands, and without strict version control, Gantt charts can prove to be remarkably elastic and misleading.

To avoid, so far as possible, Law Two failures I would print out our first draft Gantt chart on the largest sheet of paper possible and “walk down and through” the project with other members of the project team before the first program was issued. This task always resulted in additions and changes to task order and sometimes several iterations were required before the team was happy that all the tasks had been captured, in the correct order, and with sensible durations and dependences.

This methodology allowed the team to support a common vision of the project together with their tasks within it and then, upon issue, as many of the project community as possible to visualize, that is get a clear picture of:

  • The tasks within the project and their minimum duration;
  • The milestones (events triggering payments or management decisions);
  • The dependencies within the task list;
  • The resources (people) needed for each task.

I highlighted the word “picture” because the visualization of the whole project is a powerful aid in making it more widely and more easily appreciated than is possible with pages of text.

A problem with Gantt charts is in its use as a monitoring and reporting tool during a project. In the wrong hands, and without strict version control, Gantt charts can prove to be remarkably elastic and misleading.

If an important task overruns its programmed duration, its end date and all the start dates of succeeding dependent tasks have to be moved out. This may, if the programmed end date is still to be met and there is insufficient slack in the program to absorb the over-run, “bunch up” following tasks inappropriately. In such cases the reprogramming of resources to recover the program can be difficult and producing a clear graphic, within the original Gantt chart, showing delay effects can be difficult with some of the more basic programs. It is often much easier, and very tempting, to produce a new version of the program, with a new set of task dates, many of which being later than in the original. When such a reset chart is presented to a client, or a management review meeting, or to the public it has all the outward appearances of representing a well-controlled project, rather than one suffering delays. I have witnessed this form of mild deception many times and advise clients to beware of the presentation of completely new versions of a project’s Gantt chart because the presence, cause and duration of delayed tasks can be difficult, from the graphic, to determine.

Paper Acting as the Evidence Trail

If I had to choose a single piece of advice to give to every project manager, from the domestic building level to that of major industrial enterprises it would be:

Keep a detailed, daily, paper based, site diary, recording all events, important communications and decisions made.

In these litigious times such a contemporaneous record can be your only defense in cases of commercial disputes or action against you under Health and Safety legislation.

Don’t kid yourself that a Smartphone-based record is an equivalent modern replacement for a hand-written day diary; they are too easily changed, corrupted, lost, and don’t carry the same legal credibility. Major projects provide a computer network progress reporting platform which forces information to be stored in its format and content, not yours. It can be the contemporaneous observations and details that can prove vital.

In my personal case, in 1984, my site diary recorded, in some detail, an impromptu site discussion with my customer’s site manager during which we agreed on several detailed scheduling changes and small extras to contract during which I was assured that it was safe to remove some old, redundant ventilation. Three days later the ducts were removed and had been put into dumpsters for disposal when it was discovered that under the exterior painted skin was a thick layer of asbestos plaster. The result was somewhat dramatic, with most of the site being evacuated and the arrival of various officials dressed in “space-suits.” It was confirmed that the lagging material was white asbestos (chrysotile) the release of which into the atmosphere, even in 1985, could lead to the prosecution of those responsible.

It was the details within my diary records, including the time and date, and the fact that the following written records and lack of torn pages would have prevented changes being made after the event (note computer users), that proved I had asked about the need and the safety of removing the ducts and had both permission and safety assurance from the client. I thus avoided censure and prosecution.

Document Control and Team Discipline

Any process subject to iterative change is vulnerable to the disastrous consequences of one or more drawing or document recipients working to the wrong version.

In very large projects the full-time role of Document Controller plays a vital role in the recording, disciplining, and distribution of documentation; in lesser projects the job falls to the project manager or a nominated member of the project office. Large- and Medium-sized project companies are increasingly using web-based systems in which to upload and distribute project documentation. Such systems can either use proprietary suites of software such as Clarizen or 4 Projects, which tend to impose their own working methods on the users. Alternately they may develop their own basic in-house system that integrates with their long-established practices and existing software.

These systems are designed to ensure that everybody has access to the latest version of every document appropriate to their task. This is fine so long as everyone has been given appropriate password access, is continually reminded of version changes (which can be irritating), or remembers to look, which is unlikely. I have had experience of a project controlled through a suite of document control software whose multiple levels of access and filing system was of such complexity that many project community members tried to ignore or outmaneuver it. The system proved to be ineffective because very few members of the subcontract community, who were expected to both upload and download text and graphics, were given any training in its use as part of their induction. Paper prints of drawings were regularly exchanged between contractors in the carpark; eventually the project was completed but in spite of its document control system rather than with its help and I still wonder if the electronic records hold the genuine “as-built” drawing versions.

As we have already seen, any process subject to iterative changes is vulnerable to the disastrous consequences of one or more document recipients working to the wrong version. All issued specification documents and drawings need to be produced with their version number and issue date on every page.

Filing the Paper Away

Paper needs to be logically stored so that it can be found when needed; it’s a very old skill but less practiced in the world of electronic records, nevertheless failing to find an important bit of paper can lead to costly delays.

I have noted the following filing systems used in domestic and ­community projects:

  • The Compost system. This requires that each piece of paper upon arrival, irrespective of subject and its relevance to the project is placed on top of a pile. This pile can be located on any horizontal surface in the house, office or committee room and, since it may have to be frequently searched, the ­compost is regularly turned and thus loses all temporal ­coherence. Any project using this system will require a lot of extra hours work by the participants who will be doomed to suffer ­unnecessary stress.

    I have witnessed a slightly less disastrous industrial version of this system where any paperwork categorized by the project manager as pending or possible is placed in a composting tray. After a randomly chosen period of time, if there has been no reason to work on any of the content, then the lowest inch of the pile can safely be thrown into the trash bin. Believe me: it happens to this day!

  • The “Spring Lock” Box File system. Any project file should be distinctive and labeled appropriately. They should be ­distinctive because they are essentially portable and can be lost; yellow with pink spots is more recognizable and describable to the Lost Property office than the old, recycled, black-flecked, office file that your father brought back from work 15 years ago.

    Spring lock files can turn into a composing device because papers are not fixed into any order, they are therefore inferior to the next type.

  • The Lever Arch Box-File system. This, together with appropriate labeled divider cards, is the best choice for filing paperwork for most small building and domestic projects. It imposes discipline while being portable therefore is good for projects such as Wedding Planning and House ­Moving, which require “off-site” meetings with a wide range of ­important papers.
  • The Filing Cabinet Pocket system. All house owners and folk who run small businesses from home will have accumulated a considerable mass of paper-work and the common storage system will be a single, or multidrawer filing cabinet fitted with labeled hanging pockets. This is probably the most professional system for the domestic user, with a permanent position in the house. Since individual, task specific, pockets can be removed and put into a bag they have the dual advantages of being portable for away-from-home meetings but having a permanent home. This is the system I use, and I make a habit of keeping the file contents for at least six years after the end of any project which is the period where most tax authorities can come after you for any financial investigation—six years storage of key documents, after project ­completion, is a sensible rule to keep.
  • The Fully Computerized, Scanned Document system. Anyone who believes “paperless” project management is to be preferred, or is even possible for a domestic project, has never carried out the role of Executors and Trustees of a Will or similar projects where original documents are required by lawyers and courts. My father died in a road traffic accident as a result of which his final death certificate (the one that gives cause of death) could not be obtained until after the Coroner’s inquest, months after the event. Meanwhile, I had to deal with closing down his affairs and had to use original versions, or Lawyer certified copies, of an Interim Death ­Certificate. In attempting to close one savings account I had the ­following conversation:

Bank: We can’t close your father’s account by phone, we need you to come to one of our branches, with proof of your identity and authority to act, plus an original of his death certificate.

Me: OK, but I have not yet got a final death certificate so will have to produce a photocopy of an interim certificate.

Bank: No! That will not be acceptable, we have to see an original and proper death certificate.

Me: How much deader do you think my father will be between the issuing of his interim and final death certificates?

I will spare the reader the rest of the conversation but would add that it resulted in the Bank writing and distributing a completely new procedure for dealing with calls from bereaved relatives of ex-clients. The lesson is keep original certificates in a safe file and take copies that can be stored in a safe and separate location.

While it is possible to buy a complete Wedding Planner software package on the Internet you will still have to deal with the paper that is generated; the computer won’t do it for you.

Having spent many hours on sites around the world pouring over A0 sized drawings that are used as scribbling pads by engineers during machine commissioning and on which to record dimensional or ­circuit changes, I am not a great believer in the paperless project and even the best ­Tablet I can afford doesn’t allow me to read complex hydraulic schematics.

Finally: remember that IT projects don’t require any concrete content to be disasters under Law 2.

IT projects need to comply with exactly the same disciplines and best practices as those recommended to the “rude mechanicals.” In the case of IT work a paper-printable overall design of the project, in terms of flow diagrams and Graphical User Interfaces (GUI) must precede the coding. As a one-time customer for process automation software, I am not content or competent to give a considered opinion by being shown flow diagrams and logic trees on screen. I need to follow the system through on paper, preferably in my own time, and since I am probably not alone I would suggest that “customer focus” should extend to the mode of presentation at design reviews.

Storage of Project Files on a Personal Computer

As with paper, so with electronic files. Also, no member of the project team should have a PC that is the only storage site for important, project related, documents. It is good practice for every member of the same core project team to have the same file structure on their computers, then a common filing system can be imposed, and individuals have less excuse for losing information. Wasting full minutes during a meeting, or on the phone, while a member of the project community is searching through megabytes of irrelevant data is not only frustrating but also indicative that the project has a managerial weakness that needs addressing.

Some Points to Stop Your Project Failing with Law Two as a Contractor or Client

  • Have your Project Plan presented in a format your audience can understand and before release have it sanity-checked by the project team, or by an expert if you lack the required skills. Complete all this before breaking ground.
  • Think thrice, measure twice and cut once, may sound old fashioned but it’s still good practice.
  • The paperless project may be a future dream (or nightmare) but meanwhile don’t underestimate the importance of document control. The “paper-war” still has to be won and chronic, chaotic untidiness of a workspace, desk, or computer is a sign that it’s been lost.
  • Computerized project models are tools that can be excellent for planning and monitoring but need careful handling for reporting, unless the cause and effect of change, between versions, are clearly visible.

1 A “Rubbish Skip” in British English.

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

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