In a previous column I argued for the importance of IT procurement, and for the benefits that can flow from following best practices in IT procurement. That column introduced the procurement review process developed by the U.K. government, The OGC Gateway Review, which identifies what needs to be accomplished, but offers little help in determining how it should be accomplished.
The Software Engineering Institute (www.sei.cmu.edu) has developed a Software Acquisition Capability Maturity Model (ESC-TR-2002-010). The full model is available on the institute’s Web site for unlimited distribution for internal purposes. It follows the general maturity model approach SEI has used in other areas, identifying five maturity levels and describing what is required for an organization to reach each level.
At the lowest level, initial, success depends on a hero who manages to get it right. The organization has very little in place to help with software acquisition. Procurement discipline emerges only at the next level, repeatable, where “basic acquisition project management processes are established to plan all aspects of the audition.” For many organizations, this would be a significant improvement over current practice.
Each maturity level has key process areas that must be mastered; the repeatable level has seven:
– software acquisition planning
– solicitation
– requirements development and management
– project management
– contract tracking and oversight
– evaluation
– transition to support
Subsequent levels add new key process areas to be mastered. It will typically take an organization one year or more to move from one level to the next.
Each key process area has one or more associated goals. Against each key process area there are targets for commitment to perform, ability to perform, activities performed, measurement and analysis, and verification. This model provides a considerable level of guidance; for example, there are seven activities identified with software acquisition planning, and most of the activities are described in some detail.
One of the activities is establishing and maintaining appropriate documentation. That, in turn, is broken down into seven documents that are typically included in the documentation set. They range from a document that lists all relevant policies for the areas of the acquisition, to a document that describes the measurements to determine the progress of the acquisition.
The next level, defined, adds another six key process areas, ranging from process definition and maintenance to training program management. Key process areas are added as the organization advances to the quantitative level, and then to the optimizing level, where there is “continuous process improvement, empowered by quantitative feedback from the process and from piloting innovative ideas and technologies.”
The SA-CMM can be a useful tool to help an organization improve its IT procurement process. The IEEE (www.ieee.org) has also established a standard for software acquisition. It doesn’t include a maturity model, but it does include a 16-page long checklist to “assist organizations in establishing their own software acquisition process.”
There is a large and growing body of best practices that can be applied to IT procurement. Regardless of process, an important difference exists between objective and unbiased procurement. Objective procurement removes human judgment from the process. Unbiased procurement includes human judgment, but provides for independent review, and is to be favoured.
Best practices are really only common sense. Field proven best practice IT procurement guides have another important virtue: they have been improved through use in hundreds or thousands of procurement exercises. Such field-tested processes are anything but common.
Fabian is a senior management and systems consultant in Toronto. He can be reached at Robert@fabian.ca.