Implementation Impediments

White Paper on Implementation Impediments

There have been great ideas that were a miserable failure in the market place (or operationally deficient) and there have been miserable ideas and products that have been profoundly successful – pet rock comes to mind. The following is an extremely brief overview of some of the impediments to a successful implementation of a project or the successful commercialization of a product. The information presented here is brief and is solely from the perspective of the author and his experience.

The first concern was identified in the “Three Most Important Steps” in any project is to define the requirement. While this seems obvious, it is utterly amazing how often this step is only given a modicum of attention. How much time and resources should be committed to this step? Three percent? Five percent? I suspect from past observations the real answer has been considerably less than one percent. Once the requirement is defined it must be coordinated, not only for further definition but to insure it has concurrence, support and buy-in. Further definition of the project/requirement may be acquired during the coordination process, but make sure to include the identification of any critical parameters and the identification of the values of those parameters. Some values may not be critical, but others may. When each parameter and value is identified, an impact assessment should be included to better understand the importance of that parameter and value. Care must be observed to differentiate been needs (requirements) and wants (nice to haves). It is ok to include the “wants” but they must be identified as such. It is possible they might be included in the plan if they can be implemented with a reasonable cost, but the obvious danger is that sometimes a “want” may increase the cost way out of proportion to its value. To reiterate, many times I have watched in frustration as working group participants argue, seemingly endlessly, over a design point, because the author of the requirement didn’t do adequate homework and properly articulate a specific parameter. As a consequence, the working group got bogged down and valuable time was squandered.

A requirements statement, sometimes called a SOR (Statement of Requirement), is the first step in the process of acquiring the capability represented by the SOR. Depending on company protocol, the SOR may contain other information, which a company decision-maker may want before approving the requirement. Once the initial approval is obtained, the next step, if the approach is orderly, is to prepare a Project Plan, which will include many more areas of germane interest in addition to the SOR.

Blind Men and an Elephant

The story of the blind men and an elephant originated in the Indian subcontinent from where it has widely diffused. It has been used to illustrate a range of truths and fallacies. At various times it has provided insight into the relativism, opaqueness or inexpressible nature of truth, the behavior of experts in fields where there is a deficit or inaccessibility of information, the need for communication, and respect for different perspectives.

1) Wikipedia.org: Blind men and an elephant
2) Wikipedia: Text of Creative Commons Attribution-ShareAlike 3.0 Unported License

A person sponsoring a requirement sometimes has myopic attention on the requirement, being biased from his/her specific responsibilities. Often the requirement may transcend a specific work center and may have an importance and applicability spanning several work centers or departments. For this reason it is important to ensure that the coordination of the requirements statement is fully coordinated.

One difficulty, sometimes encountered, but not always recognized during the requirements definition phase is to have too narrow of perspective. It is worthwhile to step back, take a deep breath, and take a more encompassing view of the requirement and all its subtleties. This technique is often referred to as the systems approach. The following are just a few of the ancillary concerns that might be addressed: air conditioning, grounding system, lightening protection, raised floors, expansion room, training, spare parts, physical security, operational security, redundancy, diversity, anticipated lifetime, uptime requirements, door-widths, construction requirements, power sources, back-up power, clean power, protected versus admin power, warrantees, and many, many more factors. All these concerns, while not directly defining the operational requirement, may be critical factors in the implementation phase and/or the on-going operational phase. They may also effect the project cost and could influence the outcome and approval of the project.

Additional concerns in the Requirements Definition phase must also be identified and considered, but unfortunately they are often overlooked or given too little attention. Some of these include factors such as: (1) Open system versus proprietary system has many aspects such as supportable and follow-on maintenance costs; (2) Interface-ability can provide many options for expansion and multi-vendor support; (3) Scale-ability so you can implement at a modest level and grow as needed capacity increases; (4) Flexibility is part of the concern to avoid “built-in obsolesce” that makes it difficult to alter, modify and adopt the system to evolving operational or performance requirements; (5) In-house trained maintenance personnel versus contract or vendor supplied maintenance is an issue which should be evaluated against long-term company objectives, and not “backed into” because of the lack of planning (hard to negotiate when you are backed into a corner); (6) Risk Analysis examining options and alternatives is essential to avoided the “blinder effect” which can often be created by an over-zealous contractor who thinks he has you believing he is the “only game in town”; (7) Supporting documentation, including diagrams, operation procedures and maintenance procedures; and (8) more, many of which may be identified during the coordination phase of the requirement.

One of the difficulties, which often occurs is the lack of clearly designated persons who are the “point of contact” (POC) in each functional area or department in the organization. These should be identified in the Project Plan. When the Project Plan is coordinated and approved by the different offices and Department Heads, the POCs are validated as the single point-of-contact with the responsibility to support the requirement, both in the development phase and during the implementation phase.

The SOR and Project Plan will be major sources of information used to develop a contract, which may be required for larger requirements. Two essential elements in any contract is to include a very detailed Statement of Work (SOW) to specify exactly what the contractor is to provide, and what constitutes acceptable delivery or completion of each item or task. Related to this is the List of Deliverables, which must be specified. Careful planning during this phase will preclude or minimize very costly contract add-ons later in the implementation. Another essential element in the contract (depending on the nature of the project and/or acquisition) is the commissioning test, which is sometimes referred to as the acceptance test. These tests should be carefully specified to insure the system is properly tested and should include detailed test results with appropriate signatures, authenticating the results.

There is another approach to Requirements Definition, which is sometimes employed, to varying degrees. This is the use of the Request for Information, or RFI. Unfortunately it is may not be considered because of “pride of authorship” or the “not invented here” syndrome. There is a behavioral tendency not to ask for help because there is an erroneous perspective that internal, company personnel may not have the talent or capacity to “define the requirement” or design the solution. The RFI is an open request to industry to provide the requestor with information on the requirement. While this may not seem intuitive, many companies are happy to accept the request and can provide valuable suggestions and design information. Included will be any deficiencies in the statement requirement. The result of this “free” engineering critique is that the Statement of Requirement can be improved, thus improving the implementation of the requirement. From the company providing the information, they are motivated to get their company promoted, which will make them more likely to receive favorable attention during the RFQ or contract phase of the project.

The forgoing has been an extremely brief presentation of factors affecting the implementation of a requirement. It is hoped that it may be a guide to improve the probability of a successful outcome for your requirement or project. A successful outcome should not be left to chance. It can be attained through careful planning during the development phase of the procurement or project. Good Luck -- remember, you shouldn’t rely on Luck, but should rely on carefully articulated and through definition of the requirement.

NOTE: This White Paper on Implementation Impediments may not be copied or redistributed without the expressed written approval by VitaStar Solutions, Inc.