Ask yourself, why is it called a User Requirements Specification? The User Requirements Specification (or URS) is the foundation of any serious effort to buy or implement a machine, system, or upgrade. Somebody somewhere decided that there is a need in the organization to be met. More than likely, that decision was made while evaluating the situation from 10,000 or 30,000 feet. They know that maintenance costs are too high, capacity is insufficient, or efficiencies are substandard. They gave someone money and authority to do something about it. Management set the project goals (cost reduction, capacity, efficiency) but that person became the Customer.
So, back to the original question: Why is it called a User Requirements Specification? It’s not a Management Requirements Specification or a Customer Requirements Specifications. The purpose of the User Requirements Specification is to drill down to the next level and capture the attributes required by the Users of this new acquisition in order to meet the project goals.
This clarification begs the question: What is a ‘User’? A User is any person or group that is going to interact with the piece of equipment or have an interest in how it is used. In the case of a filling machine, the most obvious user is the Production Manager or Supervisor whose people operate the bottling line. But, does this manager or his people know the process parameters to be met? Not necessarily. Is it possible there is more than one User? Yes. Right away, we add Process Engineering to the list of Users.
What about the people who will keep the equipment running? Do you think Maintenance should be consulted? Absolutely. They probably have preferences regarding the control system and other components they would like to see. Their people are trained on particular platforms and they have spare parts in inventory. By now you can see what we’re looking for.
Is Quality interested in how a new filling machine is going to be used? Yes. Quality is a User.
What about Facilities Engineering? What type of electrical power is available and how much? Is there enough compressed air to run the new machine? Will it fit through the door? (Don’t laugh.) Better put them on the list.
The Importance of Identifying All Your Users. To be clear, not all of the Users need to sign off on the User Requirements Specification . But it’s the author’s responsibility to make sure that the list of Users is complete, all of them are consulted, and their requirements considered. Many of us have been involved in projects where one person learned of the project well after key decisions had been made. Perhaps the order had been placed or (horror) the team was preparing to leave for the Factory Acceptance Test. This person had a vested interest in the success of the project, but nobody had thought to consult him. The next thing you know, everything comes to a screeching halt while the Project Team attempts to verify that the machine in question meets local safety or corporate engineering standards, or that it will accommodate a new product scheduled to launch six months after start-up.
Many times the tendency is to keep the list of those providing input to the User Requirements Specification to a minimum in order to save time and perceived complication. Seldom is that a good idea. Not every idea that one of your identified users comes up with has to be included, but they shouldn’t be dismissed out of hand either. Just now you saw where EH&S, Production Planning, and Marketing should have at least been asked for input.
Now, you tell me, did I miss anyone?
Speak Your Mind