Project Prospectus

The prospectus is simply a tool for setting clear, written, concise ground rules for a project and then reinforcing periodic routine communication among the participants.

The effectiveness of communications among departments within a typical organization has historically been a hit-or-miss proposition. Communication takes many forms, and each of these forms can cause its own type of distress. For example, call-outs on a drawing that specify 22 in. may be interpreted as 2 ft 2 in., or a verbal instruction to “dry up the sump in the No. 2 warehouse” may mean a new drainage field and pumping station to some when what was called for was a bucket and mop.

Engineers tend to think in linear paths with an end in mind and a course of action identified from their first encounter with a situation or proposal. Once set upon a project’s trail, they will doggedly pursue the course of action they feel most confident in, and very little will divert typical engineers from the course. That is why we love them and why they are useful to us. However, engineers may be at a great disadvantage when operating within these patterns of thought; they are victims of their own paradigms.

Operations personnel may or may not think in these linear paths. They tend to make their needs known and then get out of the way and let the engineers design solutions to the problems they have been given. The maintenance organization often gets caught in the middle. Engineers tend to encourage this type of treatment by remaining detached from the mainstream of plant operations and by performing their assignments in semi-autonomous work units. Traditionally, engineering departments have not responded well to management; guiding an engineering staff has been compared to the “management equivalent of herding cats.”

This tendency toward independence can be interpreted as arrogance or resentment of interference, leading to an even more insular environment for engineering. Add the language barrier between engineering and the rest of the world, and you have a perfect formula for non-détente. This linear thinking and reluctance of other departments to interact with the engineering staff can lead to a one-time interface with a project design group and the avoidance of followup on the part of management or operations.

Engineering efforts can result in a perfect fit for the situation at hand, or something that leads production to say, “Yes, that will work, but it isn’t exactly what we had in mind. If only you had.” Sometimes the result does not begin to approach what the correct action should have been.

On a recent tour of a client’s facility conducted by an instrument and electrical (I&E) technician, I was shown a small structure containing a board, some gauges, and cables. The technician made it a point to inform me that the structure (more of a one-walled shack than anything else) had cost over $43,000. When I expressed some surprise, he laughed and pointed out three identical fixtures on the property, none of which had ever been brought on line. The long and short of it was that the I&E project and maintenance crews were given detailed drawings for the execution of these structures by the project engineering staff 3 months after upper management had canceled the project.

Obviously, the blame for this fiasco can be shared by several individuals: the I&E department, for not understanding the intention of the project, the installation crew for not checking the construction schedule against operation’s needs, the operations group that first commissioned the project and then abandoned the installation, and certainly upper management for not having a formal review of the project development status when the decision was made to cancel the project.

This case is isolated, of course, but how many times have we seen wasted money and effort spiral along with a project whose purpose evolves or disappears over the course of development? This scenario is most true when a project has either a poorly defined statement of purpose or an extended development horizon, with lengthy lead times between inception and execution.

Too often, the developing project with its solution will run into the reality of true need at a point where the project has begun to take on a life of its own. So much time and money have been poured into development that egos will be crushed and jobs may be lost when it becomes evident that the project has no practical application. In these instances, operations and engineering will often try to salvage the effort thus far expended. The final outcome may be a jury-rigged solution that does the job but is far from optimal. Another very real cost is that of sacrifice; how much profit have we forgone in lost manufacturing timetime that could have been spent turning out product but was instead spent pursuing solutions to problems that may have changed or become moot.

To promote the better use of engineering’s time and efforts and to promote better communication between departments, it is useful to pursue a course of “concurrent engineering,” bringing together affected parties for a harmonious relationship that stresses the positive contributions various participants can make, rather than pointing out differences between departments.

In approaching concurrent development, a “project prospectus” may be useful. The prospectus is simply a tool for setting clear, written, concise ground rules for a project and then reinforcing periodic routine communication among the concerned participants. The interval at which the parties meet is set by the involved parties (chief project engineer, an operations representative, and a project sponsor, for example) when they decide on the rest of the terms.

Other terms of the prospectus would define the intended purpose of the project, the problem or situation the project is intended to address, the parties responsible for oversight and participation, the proposed budget, expected completion date, and delivery dates for incremental milestones. It would also formally recognize the contributions that all parties will make to the development, not just the engineering staff. In this way, the prospectus becomes something more than a request for action and less than a contract for the parties involved (see the example).

An added benefit to the approach is the introduction of time sensitivity for the engineering staff. The pursuit of productivity in development staffs is often nebulous because of the intangibility of the product. The prospectus requires that the parties make a commitment to time expectations and delivery dates and then lets progress be examined in a public forum. As the project progresses, the charged parties meet at the specified interval to review the status of the project and to ask pertinent questions regarding the intention and outcome of the project.

This approach cuts across departmental boundaries to ask common-sense, practical questions: Is this project still viable? Is the original need unchanged and is the intended result unchanged? Is progress being made at an acceptable rate and are financial ramifications the same? Are staffing requirements static? Are personnel issues changed? Are supplier commitments unchanged? Have timing needs evolved? Are delivery dates holding steady? Management may wish to set a bottom control limit on the amount of money that would make this approach practicalany project over $20,000 with a development horizon of over 90 days, for example.

The interval for review should be controlled by two factors: Let enough time pass so that consequential progress can be made, but not so much that significant time, effort, and money can be wasted, should needs change. This approach has an added benefit. The periodic review of projects tends to raise the collective consciousness of the entire organization to the impact of project work and the resources devoted to engineering and projects. The result will raise the awareness of the entire organization regarding the amount of money devoted to project and developmental work. With engineering costs typically running in excess of $50/hour, wasted resources can quickly reach significant proportions.

Some parties may view the initial introduction of the prospectus as intrusive, but the benefit becomes readily apparent to all who have a sense of real contribution to their organization. To ensure the future acceptance of this approach, the first instance of using a prospectus needs to be a success. Therefore, the initial project sponsor may wish to pick a high-profile project with good support as the inaugural project. The project team should include forward thinking members with good adaptation and cooperation skills.

After all, tigers can be trained to jump through flaming hoops; it should be easy to herd cats. MT

Charles Spillman is a project manager with HSB Reliability Technologies, Kingwood Place 3, Suite 180, 800 Rockmead Dr., Houston, TX 77339; (281) 358-1477.