Case: Distribution II
Narrative
This distributor wished to enhance its order processing system to simplify workflow and to enable collection of additional customer information. A vendor was identified whose software could provide both the necessary business functionality and the related components required for integration. A preliminary demonstration confirmed that the software did indeed appear to meet the needs. Minor bugs were identified after the software was delivered and installed for user review. While the bugs were being addressed the business units that would be principally affected by the use of the software had the time to realize that in fact the software did not really meet all their needs. Further delays resulted while decisions were made as to how best to deal with these additional requirements; the eventual resolution was that some existing business processes were adjusted and some changes were made to the software. Live implementation did take place but not until several months later than envisaged in the original project plan.
Comments
This case exposes the perils of relying - even unintentionally - on a vendor demonstration to clarify business requirements. A vendor's demonstration, where the vendor largely controls the script, frequently influences the perception of what the business requirements are. The delayed reaction that the business units experienced in this case is also not uncommon. A preferred course is for the business to compose its own script and to require vendors to follow this script precisely during demonstrations. This necessarily means that the business articulate its own requirements in order to develop such a script. However, the effort is well worth while; not only does it ensure that the vendor presents features and scenarios that the business needs to verify- it also enables meaningful comparisons among presentations given by several competing vendors. See also Manufacturing I.
|
|
