Experiences from WMS Post-Mortem Review

No one likes to give the negative feedbacks during the project post-mortem review.  However this is one of the important project management phase that we should not leave without.  Though this activity, the project team gathers the best practices and lessons learnt, shares with the organisation to plan for improvements and knowledge sharing with other project teams should any similar projects are being implemented.

To illustrate the post-mortem review of the recent WMS project we had done, the below high-level project plan was shown in SDLC (software development life-cycle) methodology

The major items that we did not do well in the project are:

  1. Business Requirements Gathering
    • Customer BRD (2008)
      • Gaps that are still outstanding in Sept/Oct 09
      • BRD Sign-off only done in Nov 09
        • Impacted to Solution (using assumptions to develop)-> Results to Rework
      • Change requests
        • Highlighted in Sep 09
        • Impact evaluated and effort catered for.
      • No proper review of BRD in 2008
        • Project teams busy with Phase 1 (Dec 08 – Apr 09)
    • Lessons Learnt
      • Workshop with Customer before start of project and commit to timeline
      • Proper establishment for both Customer and vendors’ project teams
      • Proper project plan with buy-in from Customer
      • Escalating gaps in BRD
      • Sign-off of BUSINESS SOLUTION DOCUMENT/SYSTEM DESIGN DOCUMENT before development can start
      • No internal ownership to take up the project
  2. Solutioning
      • Incomplete documents
    • Lessons Learnt
      • Solution’s Subject Matter Expert involvement in BUSINESS SOLUTION DOCUMENT/SYSTEM DESIGN DOCUMENT
      • Complete BUSINESS SOLUTION DOCUMENT/SYSTEM DESIGN DOCUMENT before moving to next stage
      • Sign off of BUSINESS SOLUTION DOCUMENT/SYSTEM DESIGN DOCUMENT with the rightfully owners.

3. Development

    • Resources do not have right skill set
    • Resources not full-time on project
    • Gaps
      • SYSTEM DESIGN DOCUMENT not ready
      • Reworks
    • Functional validations
      • No one with the right expertise to validate the solution
    • Lessons Learnt
      • Committed resource with right skill sets
      • Complete/Signoff of System Design Document
      • Comprehensive internal testing

3.   Testing

    • Data Readiness
      • Wrong order type etc
      • Customer cannot provide right data
    • Testing Scenarios
      • New scenarios added midway
      • Late review of scenarios from Customer
      • Completeness?? Integration with carriers
    • Data Validations
      • Late review of Data from Customer
    • No sign-off for SIT/UAT
      • 2nd phase of UAT sign off
    • Development still ongoing
    • Testing integrity
      • No end-to-end verification from Customer
      • Customer did not require vendor  to know if data flows to their downstream/upstream systems
      • Real time code fix -> no test done??
        • Affect schedule
    • Lessons Learnt
      • Training is done during testing
      • Right party to prepare data (Customer)
      • Customer did not verify the data quality
      • Review of test scenarios for completeness with expected outcomes.
      • Comprehensive internal testing => produce test results?
      • Same testing location with Customer for effective testing
      • Sign-off from Customer

4. Project Management

    • Project Team
      • Availability??  100%??
    • Project Schedule
      • Follow-up
      • Completeness?
      • Checklist
      • Highlight Risk/Delay -> is there any real mitigation/workaround
    • Escalation.  How strong the team put across to the stakeholders
    • Lack of continuity plan for migration
    • Team obsessed with go-live date
    • PM ownership changed at the later stage of project
    • Lack of stakeholders meetings
      • Attendees
      • Frequency
    • Lessons Learnt
      • PM to be on –site for a block of periods
      • Team structure and commitments
      • Need for a logistic PM to drive the whole project
      • Proper contingency plan/fallback (be it a roll-back or manual process)
      • No shortcuts – Project methodology to be in place

5.  Post Go-live

    • Lack of proper reporting to Customer
    • No communication between regional and country
    • Lesson Learnt
      • Establishing a crisis management team to report to Customer on any ongoing post-deployment issues.

0 Responses to “Experiences from WMS Post-Mortem Review”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

June 2010
« May   Aug »


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 464 other followers


%d bloggers like this: