Posts Tagged ‘project management


Project Managers Still Didn’t Get This Idea of Sign-off Criteria

Having working with so many projects, I see most of them failed in achieving project deadlines.  Reasons like scope creeps, unclear project activities are the common but most project managers always miss out on setting and follow through the sign-off criteria/goals for each phase’s milestones.

Getting the project team to work out and agree on the sign-off conditions allows us to know what we need to set as baselines to work out all the deliverables for each milestones and probably leeways or conditional sign-off with mutual agreement to get on to the next phrase.

I will probably see that project managers need to spend time to work on as this will helps in:

  1. Clear objectives on what to achieve for each phase
  2. Measurements on what had been done so far for each phase and to plan adjustment to project timeline if necessary
  3. Clear picture to the project steering committee and project team to know and understand what they need to contribute and work on to achieve for the target deadline(s).

The areas to include the sign-off criteria must be indicate in every project phase, and link this milestone with a set of deliverables (may it be some documentations or agreed activities to accomplish).  Importantly communication and sharing of each information are to be done to all levels of the project team so everyone is set to work towards the plan


Poor Requirements, Main Factor for Projects’ Failures

It is no doubt that, in any projects poor requirement gathering results around 60% of projects’ failures that constitute to time and cost deviations.  Unnecessary re-works are done and in cases, customers and the vendors are arguing about change requests, the ‘scope creeps’ they have to pay for the additional work and timeline in which most customers do not want to extend the scope but increase the timeline.

With this ever-increasing competitions, it is harder to change the major stakeholders’ minds to extend projects with these limits.  SCRUM agile methodology is a proven way to ensure the initial business requirements are made, and new changes are built in iterative phases.  Business can also control the scope, the cost and timeline for the delivery upon mutual agreements.  In this case, this is a win-win situation for all.


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.

Project Management – A Job or A Career

Recently I came upon an article from a job search agency, about people having different perspective about a job and a career. (Reference – In this case, I come to think about the difference of a job and a career in Project Management.

Job vs. Career

How much do we understand these 2 definitions?

I remembered when I was with a well-know mobile phone maker, I look at the career roadmap on a project manager role. The career roadmap was a spiral diagram and surprise I see the miserable trend; namely project lead, junior project manager, senior project manager! What next? It is just a change to the job title, with the additional word ‘senior’ onto it. How can I move further into the program manager role in this case, in my previous employer? Well, I had to build up contacts in the head office in get me that job in which it was quite difficult for me at that time.

Being working as a project manager role, it seems to be like a daily routine except that the nature of the project different each time. Requirements scoping, cost budgeting, resource planning, planning activities are the core areas that a project manager has to do. Yes, every project is unique in terms of the business processes involved and solutions. As time goes, project managers are bored with the ‘routine activities’ they have been working on and this is what we will know as a job. A job is one that needs us to sustain the daily works of the project management organization.

A career, another definition to job-seekers, is an ongoing process that encourages an individual to enrich and develop their personal and career growths in a long run. It is not easy to find the right position for one self’s to grow within his/her employer should such opportunity is not available at all. Hence the person will look for outside opportunities to fulfill their career growth. We should not look at the person’s resume and have the assumption that he/she is not loyal or not resilient enough to stay with her current employer. Each resume we should review and look out for details that describe more about the candidate’s capabilities so that we can understand what they are looking forward to achieve for their career growth.

I still continue to pursue this career path in program management, enrich myself everyday with new things and skills. One day, I will prevail! 🙂


Preparation for Project Post-Mortem Review

Before I am going away for my well-deserved 1.5 week’s vacation, I had an performance/objectives assessments for Year 2009 with my Manager.  One of the objective is to prepare a post-mortem review for the recent project that went live early this month.

To think about the template and contents to cover for this review, this is like a session on the lessons learnt from the teams’ experiences, what we have done right and share with others, what we have done wrong and how we should improve from it.  In most projects’ post-mortem reviews, most people do not like to bring the things that they had done badly partly due to the no one is ready to accept the facts.  The typical topics are usually on improper scope control management,  mis-communications on the project team members’ roles and responsibilities, improper risk management and escalations process for stakeholder’s decision-makings.

This is what I have in mind for the post-mortem report:

  1. Project Summary
  2. What we have done right and how to improve further
  3. What we have done wrong and how to improve further
  4. Outstanding Issues to review for project closure
  5. Action Plans for moving forward

Projects I have been working on…

As coming to a year of my service to my current employer (MNC logistic/transportation company), I have come to think about what are the projects/solutions I had been working on and tracking them into my portfolio for future references

Projects that I have done for last one year:

  1. Warehousing Management System (Desktop Application)
  2. Inventory reports
  3. Business Objects Reports
  4. Freight Management System
  5. Online Order Management System
  6. EDI Integration
  7. Web services
  8. Document Repository solution for scanned shipments’ PODs
  9. AS2 Gateway implementation

Starting my 2nd year of employment, the projects in the pipelines are:

  1. Web-based Warehouse Management System
  2. Electronic Proof of Delivery (POD) solution
  3. EDI ASN implementation
  4. Infrastructure Upgrades for Online Order Management Solution

Post-moterm: Workshop in Australia

I was in Sydney for the past 2 weeks to discuss on the generic Warehouse Management solution.   The agenda of the workshop changed when the discussion went onto covering commercial aspects of the project and it didn’t serve the purpose to these participants from the Customers (2 from Operations, 1 from Logistics) to make any decisions at that point.

I, myself from the regional team, went through the country’s business requirements from Customer.  The difficulties we faced was we did not have any internal business requirements or “To-Be processes” from our country’s operations on how to manage the new enhancements from Customer.  It was a total mess and the project manager was leaving the Organisation in couple of days and nothing was established within the team to discuss the move-forward plan for documentations.

Sitting down with my system analyst, we went through every single paragraph on the Customer BRD together with Korea to understand where are the similarities for both and identifying the core functionality for robustness and scalability for future enhancements and new deployments for new sites.  The high level, estimated time-line for the availability of the solution is planned for next December 2009 with the considerations of the complexity and ongoing issues that we are facing at this moment.  The Management did not like the plan as this was taking too long to develop and get ready for the requirements for the upcoming RFQs with the Cusotmer.  The teams were dismayed and objected to unrealistic comments, scope-down of the requirements to achieve this timeline as the problem we faced was more than just the complexity of the solution.  Human resources, required documents and analysis are to take care of to meet that timelines.  Last week, we sit down and look into the customer’s needs for the next 4 months’ deployments, working out several alternatives to achieve April 2009 go-live and iterative developments for December 2009.

Right now, it is up to the Steering Commitee to make their final decisions and going forward for the project in the next few days.

November 2017
« Mar    


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

Join 443 other followers