Interested in linking to "Accurately scoping process analyzer projects"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
10/10/2006
By Gary Nichols, PE, Jacobs Engineering Group
THE FIRST article in this series (“How to Launch an Analyzer System Reliability Program,” Control, July 2006, pp 49-53) noted the close relationship between the lifetime cost of a process analyzer project and the attention given to reliability during the concept (scope development) and design (detailed engineering) project stages. This article covers the details of a project scope document.
One of a project engineer/manager’s most challenging jobs, especially during project scope development, is the avoidance of “meatball engineering”—a poorly scoped project that leads to minimally effective results. (Gregory Hale, InTech, Oct. 2004) Key to this avoidance is “knowledge management” and “good client” development, says Hale.
ADVERTISEMENT
|
RELATED ARTICLE
|
The engineer must elicit from the client—the funding source—all the information required for a good project and gently, but persistently, minimize chances that he becomes his “own worst enemy,” causing unwise scope-cutting or, conversely, “scope creep,” or demanding procedural shortcuts, illogical cost-cutting and schedule changes. The project engineer must ensure communication with clients or accept--often unjustly--responsibility for missing project goals, and it falls to him or her to make sure this doesn’t happen. (Mark Hoske, Control Engineering supplement, Dec. 2004, pp.12-14)
The information that must be addressed is often part of the front-end engineering design, the front-end loading, the project execution model, and the independent project analysis. (R. Mead, H. Sedgwick, and S. van Soest, Hydrocarbon Processing, Sept. 2004, pp. 69-74)
Now we shall address formal details of the project approval scope. Following are the working assumptions:
We shall concentrate on the written scope, which probably has a standard format, but note that other documents frequently contain information needed to develop the project scope and, conversely, that the project scope will eventually be reflected directly or indirectly in the other documents.
Table I shows a typical project approval scope document structure. For simplicity, let us assume that the detailed estimate document generally follows the structure of the detailed scope, and that the latter does not include dollar amounts.
TABLE 1:
Typical Project Approval Scope of Work Document Structure
Table 2 shows the detailed scope structure that would be included under Item 5 in Table I.
TABLE 2:
Typical Work Types Included in Detailed Scope
ControlGlobal.com is exclusively dedicated to the global process automation market. We report on developing industry trends, illustrate successful industry applications, and update the basic skills and knowledge base that provide the profession's foundation.