Skip to main content

A New Model for Product Purchasing

Most organizations follow an acquisition model similar to:
  • Identify Business Need
  • Gather Requirements
  • Evaluate Products
  • Select Product
  • Purchase Product
  • Implement Product
This model has generally proven to be costly and unreliable. Significant resources are spent identifying needs and requirements. Working with users to determine requirements is generally unreliable and often results in recursive need/requirement loops. Product evaluation and selection is time consuming and expensive, often requiring RFP’s, live demos and test installations. The end product rarely meets the users needs or requirements, simply because the unreliability of the user results in documented needs and requirements that do not represent actual user requirements.
The above process may be significantly streamlined by simply eliminating the unnecessary steps and reordering the remaining. The new model looks like this:
  • Purchase Product
  • Implement Product
  • Gather Requirements
  • Identify Business Need
This minor modification of the standard model has the following benefits.
  • Formal product evaluation by highly paid technical staff is eliminated. Products are instead evaluated by VP’s and executives at vendor provided lunches, social gatherings, sporting events, etc. Product selection is likewise eliminated, as it derives directly from product purchase.
  • Product requirements can be extracted from vendor documentation and product brochures more efficiently than developing requirements from scratch. Likewise, when an RFP or similar formal purchasing process is required, the process can be significantly streamlined by extracting requirements from vendor product brochures. Care must be taken to avoid the ‘ransom note look’ when copying and pasting vendor materials. Pasting as plain text into a preformatted document is preferred.
  • Business needs are easily derived from post implementation product walk through and demonstrations. Business users will realize their needs as they explore the product user interface and features during product training. An entire layer of analysis is thereby eliminated.
  • Entire teams of business analysts and architects are redundant in this model. The vendor’s analysts and architects have already provided much of the functionality that these roles normally perform. Substantial cost savings will result from the elimination of these roles.
  • Project risk is minimized. When needs and requirements are derived from the documentation of an already purchased product, there are no unmet needs or requirement gaps except in cases where the vendor product documentation is inaccurate. Change orders can be executed to correct the mismatch. Project success is virtually assured.
In the particular case of highly technical products where customers are unlikely to realize that they have an unmet need (security products, for example) this method assures that customer needs are met even when customer awareness of needs is insufficient to result in customer initiated product evaluation and purchase.

A parallel model may be used for software development. In the software development derivative of this model, developers perform requirements gathering as they write the software. As in the product purchase model, business needs are derived from the functionality of the completed software. Individual developers assume the roles of business analyst and architect. Their familiarity with the functionality of the software assures that the software functions as requirements dictate, as all requirements are derived from existing software functionality.

The matching of functionality to requirements is simplified by careful construction of module and function names. This will allow use of regular expression matching and word substitution to automatically build requirements from source code. For example, for a source file containing the following pseudo code[1]:
function store_customer_records 
This simple command:
cat <source file> </ source file>| sed -n \
'/^function/s/\(function\)\(.*\)/The product will \2\./p' | tr '_' ' ' 

Will extract the following requirement:

The product will store customer records.
The post-processing of requirements can easily be managed as a part of normal software deployment. As new versions of the software are deployed, the updated requirements can be automatically extracted and e-mailed to project managers by simple post-processing scripts attached to commonly available automated deployment systems.

A significant fraction of all product purchase and software development already follows derivatives of this model. Additional refinement and wider implementation of this model should result in improvements in efficiency, productivity and user satisfaction.

UPDATE 04/09/2009 After testing the new model on a recent large software purchase, it’s clear that I’ve obviously left out a critical step in the proposed model. An additional step should be added to the tail end of the process:
  • Analyze and Document Security Requirements
The complete model should be:
  • Purchase Product
  • Implement Product
  • Gather Requirements
  • Identify Business Need
  • Analyze and Document Security Requirements
Adding security requirements to the end of the document does not significantly alter the procurement process. The requirements are derived from existing functionality, making the process largely pro forma.

[1]Note: Regex matches on object oriented code should extract public methods only. The publishing of private methods is a security violation.


Popular posts from this blog

Cargo Cult System Administration

Cargo Cult: …imitate the superficial exterior of a process or system without having any understanding of the underlying substance --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.
The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:
Failing to understand the difference between necessary and sufficient. A daily backup …

Ad-Hoc Versus Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to…

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. These …