Innovation Through Procurement Contests: Requirements v. Specifications (Part 2)
This post is a follow up to 'Innovation Through Procurement Contests' (Part 1), my thoughts on Procurement Insights’ 3 part (so far) series on contests in public procurement. I’ve had a chance to think about the idea a little more and as far as I’m concerned, if it allows the buying organization to put the right solutions in place, then it is a benefit. As I commented in my previous post, the concern becomes for the procurement professional whose role becomes one of administration rather than strategy and negotiation. Although I didn’t realize it at the time, I had started down the road towards what would become a sticking point for some of the collaboration-style projects often resulting from new solution development: intellectual property rights.
While reading part 3 of PI’s series, and the supporting white paper “Public Procurement for Research and Innovation”, an Expert Group Report prepared in 2005 for the European Commission, I started thinking about the difference between requirements and specifications. Both provide prospective suppliers with (a.) the information to decide whether or not to participate in the bid and (b.) the background required to define the details and pricing of their proposed solution. In the case of R&D, however, the difference is significant. While specifications define the parameters of the solution itself, requirements define the end product/result only. While a bid based on specifications will likely result in a group of comparable solutions, one based on requirements will result in more variation in the proposals and methods, but may also result in greater creativity and find a better solution because of the flexibility afforded the suppliers.
I’m in the process of reading, “The Deming Management Method” by Mary Walton. It is a high level run down of post of Dr. Demings tenets on quality management. Deming breaks his philosophy into Fourteen Points and Seven Deadly Sins. Point Four is “End the Practice of Awarding Business on Price Tag Alone”. Aside from the fact that low price and high quality rarely go hand in hand, Dr. Deming also expresses concern for the three primary risks associated with splitting an award between multiple suppliers (keep in mind that he predominantly addresses manufacturing environments): variation (from piece to piece), frequent transition between suppliers, and finally “it produces a reliance on specifications, which become barriers to continuous improvement”.
I re-read that paragraph in the book several times just to be sure I understood. Usually, more detailed specifications are regarded as a good thing because they lead to more comparable options which the buyer can leverage for better terms. But he’s right – making sure that everyone quotes on “apples” doesn’t reward creativity, innovation, or progress. And if procurement isn’t the point of entry for new ideas, either they won’t enter the company or we won’t be the point. Both are lousy options in my opinion.
Depending on what is being purchased, some specifications are necessary and important. But there is an opportunity for requirements to play a larger role in the bidding and buying process. By outlining what the product or service in question needs to accomplish for the larger organization, you may open yourself to alternative solutions. The trick is identifying and articulating the requirements well enough that they are useful.
Requirements definition (or analysis) is a discipline commonly found in software development, but it doesn’t take a huge stretch of the imagination to translate their examples to fit in a more general procurement environment. To get you started, I’ll conclude this post with a list of requirement types from the Wikipedia page on Requirements Analysis:
Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:
· Operational distribution or deployment: Where will the system be used?
· Mission profile or scenario: How will the system accomplish its mission objective?
· Performance and related parameters: What are the critical system parameters to accomplish the mission?
· Utilization environments: How are the various system components to be used?
· Effectiveness requirements: How effective or efficient must the system be in performing its mission?
· Operational life cycle: How long will the system be in use by the user?
· Environment: What environments will the system be expected to operate in an effective manner?
Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.
Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.
The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.
The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.
Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.
A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.