Introduction
You have just spent the last 6 months living, breathing, eating (but not sleeping much) with one and only one focus – “getting live” with your new system. Congratulations you are now “live”! So what do you do now? No, it is not time for Disney World! Actually, chances are you should be finishing the implementation.
That fact is your company, like most organizations undertaking such a process, was likely required to develop a detailed business case to justify the cost and risk associated with the purchase and installation of your new system. More often than not, this justification included promises that the new system will deliver increased operational performance – frequently in the form or reduced costs, decreased cycle time, inventory savings and/or increases in customer satisfaction.
Further, because we all must live in the real world and deal with real world constraints like approaching peak conditions or other key business events, there is a date by which the system must be “live” – often called the “Drop Dead Date”. Achieving this date frequently requires compromises and tradeoffs to be made during the implementation process. This usually translates to a reduction in the scope of the functionality included in the definition of “the system”. The implication is that the omitted features will be implemented at some future time. However, it often happens that after the crucial and climatic moment of reaching “live” status, the project is deemed largely complete and the resources and organizational focus both move on to the next hurdle.
Locate the Opportunities
It may seem obvious, but in order to achieve the results promised at the onset of the project the system must be implemented as close to the original specifications as possible. Therefore, the implementation needs to be finished.
The most challenging aspect of completing the implementation process (particularly if a significant amount of time has passed) will likely be identifying the remaining implementation tasks. The following activities will guide the development of a thorough Implementation To Do List:
- Perform a Project Post Mortem
- Audit the System Usage
- Map the External Data Flows
- Review the Original Project Justification
It should be noted that it is very likely that during the course of completing these activities duplicate implementation tasks will be identified. This is a positive sign and a direct result of the overlapping nature of the tasks and the structure of the project itself. Further, it demonstrates that you have been successful in adequately covering the many different components of the implementation.
Project Post Mortem
During the course of any project, numerous deviations for the original plan occur. The key to completing the Post Mortem will be to identify a) What those changes were; and b) Why they were made. However, as projects are usually long and employ the talents of many people from multiple organizations whose memories tend to fade, this is no simple task. There are, however, a number of methods to ‘reconstruct’ the project and its events. Further, it is often true that the simple recollection of key dates and events has a memory triggering effect on the project team members. This will help recover other more relevant facts. Together, it will be possible to assemble an accurate and complete history of the project.
The first step in this process is to gather all the project related documents that can be found. Among the most important to locate in this ‘paper chase’ are: Project schedules, status reports, software change orders, issues list (particularly from the period of initial “go live” operations), meeting notes and requirements documents. Don’t just rely on the documents in your personal collection; solicit them from key project team members. Also, don’t neglect any electronic records that may reside on the various systems used during the course of the project. The search will undoubtedly lead to duplicates, but it will just as likely lead to some gems.
Once what seems to be a representative (1 foot per month of project duration is a good rule of thumb!) mound of documents has been collected, sort them into chronological order. Next each document should be reviewed. The purpose in doing so will be twofold. First, it will be useful to reacquaint yourself with the project. You will be immediately transported back into the trenches, undoubtedly causing you to remember general events and key activities that were occurring during the course of the project.
Second, you will be seeking key nuggets of information. These will include items like schedule changes, interesting decisions, scope changes, challenges to key assumptions, personnel changes, temporary ‘go live’ compromises, major software defects, operational constraints and anything else that seems to alter the project or ground rules under which you commenced it.
While completing this review, keep good notes. When a key piece of information is located, identify the source document, the information and the date. When the document review has been completed, organize these notes in chronological order. This list will in essence become a rudimentary Project History narrative or the story of the project!
After the initial draft of this narrative has been completed, it should be shared with key members of the project team. They should be asked to review it carefully and make notes detailing their own recollections. Their goals in this review will be identical to those during the initial document review – reacquainting and finding/recollecting key bits of information. Ask them to keep notes about what else was taking place during the various phases of the project described in the narrative.
After their reviews have been completed, collect the feedback from team members. This information should be added to the narrative.
Depending upon how much feedback you receive and from how many project team members you receive it, it may be helpful to complete this distribution and feedback collection process once more. Doing so provides team members with the benefit of their co-worker’s recollections. It is likely this additional review will likely stir up more memories and provide added useful information. Also, because the first iteration of this review included only selected team members, it may be beneficial to broaden the distribution during this subsequent cycle to include additional project team members who may provide additional perspectives.
Finally, after satisfactorily completing the distribution and update process, this document should be reviewed to one last time with the specific task of locating implementation tasks. The goal is locating areas where functionality was either reduced from the original plan or omitted entirely. Additionally, temporary additions, short-term workarounds and other less than optimal solutions should be identified.
Each of these items should be included on your Implementation To Do List. When in doubt, any item that appears to be a change should be noted on the list. At the completion of the task identification phase, a review process will offer the opportunity to review all the listed tasks in detail.
Audit System Usage
Once a thorough history of how the project arrived at the current point has been compiled, it now needs to be determined where exactly this point is. The results of this activity will surprise some.
To do this, an audit of how the organization is currently using the system needs to be completed. 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, Replenishments, Picking, Shipping, Quality Assurance, Cycle Count, etc.
Next, assign each of these areas to a team member to document. It may be wise to employ the talents of the “power user” in each of the areas. They may require a little coaching in the mechanics of completing this task, but in general they have the most complete and current knowledge of the function and are proud of this fact and enthusiastic to share their knowledge.
For each major function in an operational area the following items should be identified:
- What system functions are being used (menu options) and when?
- What screens are used in those functions and how are they accessed (e.g. function keys)?
- What reports are being generated?
- For each function, what messages or error indications are displayed (if any) on a regular basis?
This information should then be used to produce a Systems Usage document. This can be done in a variety of formats, but the traditional format is a flow chart.
Incidentally, this document will provide significant value outside of the scope of this activity. It will prove useful with tasks like training, issues diagnosis and designing modifications and upgrades.
The completed systems usage documents should be compared against the originally planned usage. This task will be difficult and will likely require both a systematic review by key project team members and a thorough comparison to original design and requirements documents. The goal of these reviews is to identify any deviation from the originally planned usage.
While many of the findings will not be unexpected, it is likely that some results of this review will be of surprise. For example, during the course of many implementations (particularly during the initial days of operation), users are asked to temporarily alter their system usage to adjust to a short-term condition or workaround a project issue, but for one reason or another never return to the correct method after the issue has been resolved.
As during the Project Post Mortem exercise, these reviews should be focused upon the identification of tasks that should be added to the Implementation To Do List. Keep in mind that it is likely that intentional functional variances from the will be identified. Include those items on the list anyway as they could prove useful at a later time; perhaps in reconciling your actual results to those forecast in the justification documents.
Map External Data Flows
Having identified the history of the project and the current usage of the system, focus should now be placed on how the system is interacting with the outside world. To do this, a ‘map’ will be prepared to document the data flows between the WMS and the other systems with which it interacts. This will help identify gaps, erroneous or missing data and opportunities to eliminate duplicate transactions.
A less than robust interface creates extra work, requires close monitoring, needs constant maintenance and often produces erroneous results. This combined with the fact that interface development is frequently one of the project tasks that is reduced in scope to meet schedules suggests that this area will provide a number of potentially valuable tasks to add to your list. If either of those statements could be applied to your interfaces, now is the time to correct that. If the Project Post Mortem didn’t reveal these items, this activity should.
The first step is to identify all the systems the WMS sends data to or receives it from. This list is always longer than most would initially suspect and may include accounting systems, order management systems, transportation management systems, conveyor control systems, and package manifesting systems among others. Next, for each of those systems identify what data, at the record or object level as opposed to field level detail, flows between the two systems. For example, simply identifying a customer order as opposed to all the elements of an order (i.e. order header, order detail, order notes) will suffice for this exercise.
Finally, determine what “triggers” the flow of the data. For example, an order management system might send customer orders to the WMS according to a fixed schedule. In this case the trigger is a calendar or clock. As another example, the WMS might send purchase order receipt data back to the accounting system upon receipt closure. In that case, the trigger is the specific function (s) in the WMS that affect the cause the receipt to close.
Take this information and create a simple ‘map’. Although many formats can work, a simple flow chart works well. This would have the WMS in the center with groups of arrows flowing between this system and the interfacing system. Each arrow, usually numbered to support additional description, representing a specific instance of a transaction.
Now that all this information has been collected and documented, the analysis task can be completed. During this activity you are looking for issues like:
- Missing Transactions – Do you receive “ADD” transactions but not “UPDATES” and/or “DELETES” for the same file? An example would be a Purchasing system that doesn’t send the WMS updates when Purchase Orders are modified. Do all activities that modify inventory balance in the WMS send a corresponding transaction (or summary level update) to the host?
- Duplicate Transactions – Are transactions like Shipment or Receipt confirmations sent from two different processes within the WMS?
- Missing Transaction “Types” – It may be that there are other types of transactions, which 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 Issues – Are transactions synchronized properly? For example, is it possible given either transfer schedules or processing sequences, for a transaction like an SKU “ADD” to get ahead of the first Purchase Order specifying that order? Additionally, look for data being transferred at the wrong time. Perhaps Ship Confirmations are being sent to the host before the orders have passed a potential audit and correction process.
Just like you did during the analysis components of the past two activities, you should be focused on isolating those items that should be added to your “Implementation To Do List”.
As an optional step to take this activity to the next level of detail, the field level data should be examined. The specific data that is transferred within each transaction should be identified and document. In this iteration, you are seeking to identify incomplete or inaccurate data elements being transmitted. The correction of those issues will be items that are added to the “Implementation To Do List”.
Review Original Project Justification
As the last, but most certainly not the least important activity to identify implementation tasks, the business case submitted to justify the cost and risk associated with the implementation of the new system should be “dusted off” and reviewed. While it may be too early in the project’s life cycle to be realizing the identified benefits, it should be possible to determine if the conditions exist for achieving those results.
As an example, imagine that enhanced utilization of reserve storage locations and increased lift operator productivity were key elements of a project’s justification. 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, the full implementation of those two functions should be added to the Implementation To Do List, as they are required to achieve the utilization and productivity targets specified in the justification.
Prioritize and Implement
After completing these tasks, the Implementation To Do List should be fairly complete. However, before beginning to implement the listed items, attention should first be directed towards the list itself.
As the tasks are likely in no particular order beyond the sequence in which they were discovered, time should be taken to organize the document. Start by sorting the items by functional area or business process. This should make it possible to identify any duplicate and/or overlapping items. These should be eliminated and consolidated as appropriate.
Although the development of this now sanitized Implementation To Do List is the most time-consuming step of this process, it is certainly not the most critical – implementation of the identified items is! However, it is likely that more items have been identified than can be implemented in the near term. Accordingly, some prioritization and sequencing of the items is required.
Begin this process by considering the following factors for each of the listed items:
- Payback – Will this item offer significant benefits?
- Risk – What are the chances that implementing this item at this time could adversely affect operations?
- Difficulty – How much effort will this item’s implementation require?
- Linkages – Is this task related to another that would be easier to implement together rather than separately (i.e. “the hood is already up”)?
Obviously the assignment of these priorities is more art than science; however the process of assessing each of these factors will prove valuable. While it is certainly likely that this assessment may not supply a definitive priority for each item, it will certainly provide greater understanding of each of the items and ultimately facilitate the development of a “rough” implementation plan – which is the goal.
Until now, each of the items to be implemented has been addressed individually. While it is certainly possible to successfully implement each item one at a tie, it may be more effective to group these items together into sets. By implementing the items in groups, the disruption to the operation can be minimized, while offering the project teams an enhanced ability to diagnose any issues and measure the results.
Congratulations! You now have a complete and organized Implementation To Do List. The only thing standing between you and a truly finished implementation project is the listed items. So, manage the completion of the list and then you plan that trip to Disney World!
As of September 8, 2020, Crimson & Co (formerly The Progress Group/TPG) has rebranded as Argon & Co following the successful merger with Argon Consulting in April 2018.
Share:
