Here’s an all-too-familiar scenario: A project team spends six months of late nights and cold pizza working to “go live” with a new system. Then the “go live” date occurs, the new system is up and running, and reality sets in. In this real world, implementing a system by a given date frequently requires compromises and tradeoffs, and these usually translate into a reduction in the system’s functionality. Those involved assume that the omitted features will eventually be implemented. However, it often happens that after the climactic moment of reaching “live” status, the project is deemed complete, and both resources and the organization’s focus move on to deal with the next formal hurdle.
TRACK DOWN THE TRADEOFFS
Your company was no doubt required to develop a business case to justify the cost and risk associated with the purchase and installation of its new system. This justification almost certainly included promises that the new system would deliver increased operational performance in the form of lower costs, decreased cycle time, or inventory savings.
It may seem obvious, but to achieve the results promised, the system must be implemented as close to the original specifications as possible. Therefore, now is the time — before you schedule that hard-earned vacation — to track down the compromises and tradeoffs and finish the implementation.
The most challenging aspect of completing the implementation is likely to be identifying the remaining tasks and developing a thorough implementation to-do list. These activities will serve as a guide to develop the list: Perform a project post-mortem; audit system usage; examine external data flows; and review the original project justification.
During the course of any project, numerous deviations from the original plan occur. The key to completing an audit will be to identify what those changes were and why they were made. However, as projects are usually long and employ the talents of many people, and memories do tend to fade, this is no simple task. The first step is to gather all the project documents that you can find. Among the most important are schedules, status reports, software change orders, lists of problems, meeting notes, and requirements documents. Sort these items into chronological order and review each in detail. Your first objective will be to reacquaint yourself with the project. Reading will immediately transport you back into the trenches and cause you to remember general events and specific activities.
Next, locate items such as schedule changes, interesting decisions, changes of scope, challenges to key assumptions, personnel changes, temporary “go live” compromises, major software defects, or operational constraints — anything that seems to have altered the project or the ground rules under which you started it.
When you locate such an item, identify its date, source document, and information about it. These notes, which you should sort in chronological order, will become a rudimentary project history.
Share your initial draft of the history with important members of the project team. Ask them to note what else was taking place during the various phases of the project described in the narrative. Incorporate these notes into the project history.
Review this document one last time with the specific purpose of locating implementation tasks to find areas where the system’s functionality was either reduced from the original plan or omitted entirely. You should also identify temporary additions, short-term workarounds, and other less-than-optimal solutions.
Finally, include each of these items on your implementation to-do list. When in doubt, you should include any item that appears to be a change.
AUDIT SYSTEM USAGE
Once you have compiled a history of how the project arrived at its current point, you need to determine where exactly this point is. The results of this activity will surprise some.
To do this, you will need to complete an audit of how the organization currently uses the system. This may sound like a large task, but if broken into smaller units, it need not be daunting. Start by dividing the system into operational areas: receiving, putaway, replenishment, picking, shipping, quality assurance, and so forth. Next, assign each of these areas to an associate to document. I suggest selecting the “power user” in each of the areas. This person may require a little coaching in the mechanics, but generally has the most complete knowledge, is proud of it, and is eager to share it.
For each major function in an operational area, identify the following:
- What menu options are used and when?
- What reports are generated?
- What messages or error indications are displayed (if any)?
This information should then be used to produce systems usage documents, traditionally in a flowchart format. (Incidentally, these documents will provide significant value outside of the scope of this activity — you can use them in training, diagnosing problems, and designing modifications or upgrades.) Compare the documents against the usage planned originally. This task will be difficult, and it may require both a systematic review by key project team members and a manual comparison to the original design and requirements documents, with the goal of identifying any deviation from what the system was intended to do.
| Data | Direction | Trigger | Action |
|---|---|---|---|
| Customer order | In | New order | Add |
| Customer order | In | Order amendment | Update |
| Customer order | In | Order amendment | Delete |
| Ship confirmation | Out | Manifesting | Add |
| Ship confirmation | Out | Trailer departure | Add |
Focus on identifying tasks to add to the implementation to-do list. Include any intentional functional variances, as they might prove useful later, perhaps in reconciling actual results to those forecast in the justification.
EXAMINE EXTERNAL DATA FLOWS
Once you identify the history of the project and current system usage, focus on how the system interacts with the outside world.
A less-than-robust interface creates extra work, requires close monitoring, needs constant maintenance, and often produces erroneous results. This, combined with interface development frequently being one of the project activities that is reduced in scope to meet schedules, suggests that this area will provide valuable tasks to add to your list. If either of the previous steps didn’t reveal such items, this should.
First, identify the systems to or from which data is sent. Next, for each of those systems identify what data (e.g., customer order, receipt) is transmitted and under what circumstances. To assist in the analysis, prepare a simple table format for each system with which the WMS interacts.
Next, analyze these tables, looking for:
- Missing transactions. Do you receive “ADDS” but not “UPDATES” and/or “DELETES” for the same file?
- Duplicate transactions. Are transactions such as shipment or receipt confirmations sent from two different WMS processes?
- Missing transaction types. It may be that there are other types of transactions that are technically possible and would prove useful to your operation. For example, the order management system may support and significantly benefit from receiving a periodic or on-demand inventory status transaction from the WMS.
- Timing discrepancies. Are transactions synchronized properly? Is it possible, given either transfer schedules or processing sequences, for a transaction like a SKU “ADD” to get ahead of the first purchase order specifying that order? Also, look for data being transferred at the wrong time.
REVIEW ORIGINAL TARGETS
Finally, dust off and reexamine the business case submitted to justify the cost and risk associated with the new system’s implementation. While it may be too early in the project life cycle to be realizing its proposed benefits, you should be able to determine if the conditions exist for achieving those results.
For example, imagine that enhanced utilization of reserve storage locations and increased lift operator productivity were key elements of the justification for a project. However, to simplify and expedite the implementation, the advance features of the putaway and replenishment functions (e.g., rules, triggers) were not implemented. In this case, you should add the full implementation of those two functions to the implementation to-do list, since they are required to achieve the utilization and productivity targets specified in the justification.
PRIORITIZE AND ACT
Once you finish these activities, the implementation to-do list should be fairly complete. However, before you begin working on the tasks you have identified, first direct your attention to the list itself.
As the tasks on the list are probably in no particular order beyond the sequence in which you have discovered them, take a moment to organize the document. Start by sorting the items by functional area. This should make it possible to identify any duplicate items. You should eliminate or consolidate these items, as appropriate.
Although the development of this now-sanitized implementation to-do list is the most time-consuming step of the post-mortem, it is certainly not the most critical — implementation of the identified items is. However, if, as is likely, you have listed more tasks than can be completed in the near term, some prioritization and sequencing are required.
Begin this process by considering the following factors for each item:
- Payback: Will it offer significant benefits?
- Risk: Will implementing it now adversely affect operations?
- Difficulty: How much effort will its implementation require?
- Linkages: Is this task related to another that would be easier to implement along with it rather than separately?
Obviously, the assignment of priorities is more art than science, but the process of assessing each of these factors will prove valuable. While this assessment may not supply a definitive priority for each item, it will provide a greater understanding of the work to be done and ultimately facilitate the development of a rough implementation plan — which is the goal. When you do begin implementation, it will probably make sense to perform the tasks in groups. This will minimize disruption to the business and offer the project teams an enhanced ability to diagnose any bugs and measure results.
Congratulations! At last you have a complete and organized project to-do list that is the only thing standing between you, a truly finished implementation, and the hard-earned reward of your choice.
Judson A. Puterbaugh is a partner with The Progress Group, a logistics and supply chain consulting firm. He can be reached at (602) 369-4803.