What does a really great project specification look like and who should be involved in developing the project specification?

Indiana_Dave's picture
Submitted by Indiana_Dave on Sat, 09/12/2009 - 21:57.

I've been on both sides of the user/vendor fence and in both roles I've been involved in developing project specification documents. I've seen the benefits of project specs that are heavy on describing the application and I've also seen the benefits of project specs that were much more technology oriented.

In my humble opinion, all the technology options available in 21st century automation and safety systems is making things more complicated for end-users - e.g., Wired or Wireless? HART or fieldbus? Which fieldbus? Integrated control & safety or segregated control & safety? Integrate fire & gas or not? Managed or unmanaged network switches? Separate or integrated security? Include plant wireless networks (i.e., video, audio, mobile workers, etc.) or not? The list goes on and on. For some end-users some of the decisions were pre-determined when their company signed a buying agreement with vendor XYZ. But with vendor's constantly adding new features, benefits, and capabilities even a buying agreement doesn't preclude the need for a really good project specification.

So, I'm posing some questions:
1) What does a really great project specification look like?
2) Who should be involved in developing a really great project specification?

Regards,
Dave

High-Resistance Grounding ›

A great project

FrancisL's picture
Submitted by FrancisL on Mon, 09/14/2009 - 10:19.

A great project specification starts out by describing exactly what the plant is supposed to do – the functional requirements - in a way that is fully understandable by the all stake holders. I have spent 15 years developing tools for producing them!
It is not just the final documents that are important, it is the entire process of developing them, most importantly the process whereby these stake holders (process engineers, operators, automation engineers etc) agree the detailed requirements. The S88.01 standard provides some guidelines at least on the terminology and models that can be used, but there is much more to it.

Things like " Wired or Wireless? HART or fieldbus?..." are nothing to do with the functional requirements and only need to be decided once the functional requirements are determined. In practise this rarely happens by the way.

Francis

www.controldraw.co.uk