Archive for the 'project management' Category


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.


Hints to Complete Functional Specification Document

Ever experience we can’t finish to get the Customers to agree or sign-off the functional specifications as per planned and instead, it is getting longer and having more details?  In today’s business world, customers are no longer as “dumb” as most IT professionals are thinking of.  With technology advance and lots of training and courses on IT business technology, they are getting to know what they want to get for their projects or products development so that they don’t feel the suppliers are hiding any information.

The above may be true but it may not be necessary to cover everything during user requirement gathering.  This is still a preliminary stage to understand the business flows, expectations and user experiences for the software applications or products and hence put the project schedule on risk if unable to sign-off the requirements to move on to design and development stages.

With that in mind, we can prepare ourselves upfront by anticipating what they are looking for.  Below are the items I have experience and like to share on what to take note of when preparing the sign-off.

  1. Use case diagrams – Do not put in too much details e.g. the default selections, exception handling or else it will be too long and it became a technical design flows rather than user flow.
  2. Use Cases – no technical details on the functionality.  In most cases, certain level of technical information must be included and defined for the requirement.  If to the stage whereby unable to assess the technical aspect of the requirement,  we will indicate for that requirement’s feasibility will be reviewed during design phase.
  3. Screenshots – indicate that wireframes, user interfaces of the software are for illustration purposes.
  4. Messages/labels -which are static (labels) and dynamics (normally error or warning messages) to be shorten or rename.  Also to note for any language translations
  5. Field lengths – The length, field type (i.e. integer, double, string), default value (if any).  These information mainly covers for input fields.
  6. Document layout – make sure to print out the document and ensure the contents can be viewed and aligned correctly.

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.

How to work out the Service Level Agreement Document

Time is rush, the service manage has to get the service support document done within 3 weeks to deliver and get service support team to be ready for the 1 month’s warranty period before official handover of the application to them.  Sound ridiculous? Not really, it happens everywhere, in any other workplace where most project managers also forget about these important procedures prior to handover the solution to the service support team.

No panic button required here.  There are few project documents and activities to look at (if they have already prepared) to get the service manager to start to work with the support team in understand what to draft for the service level agreement document for a new application.  They are:

  • Technical specification document of the application
  • Business process documents involves the usage of this new application
  • Common issues troubleshooting guide – this helps the new support team to understand how to solve the technical issues faced during the whole project phase in case they happens again
  • Training – do ensure that the support team is invited to attend any new system training as planned in the project plan.

We must treat a service level agreement document as a legal, contractual document between the service provider and the Customer.  Therefore it must be reviewed, understood and approved by both the parties.  We also need to take note that we need to include the relevant information into the document as much as possible, and to be specific, concise and clear to everyone.

The most common mistakes that are made in drafting the service level agreement (SLA) document are:

  1. Missing descriptions of the services or applications to be supported
  2. Missing exact roles and responsibilities of the Customer and the service provider
  3. Geographic locations and time-zones details should the application is supported in a centralized support model (also known as ‘around-the-sun’)
  4. Working hours for specific locations
  5. No specific, clear escalation process
  6. Highlights on the different impacts (business impact) for each priority
  7. No communication mode for notice periods and escalation contacts
  8. Ambiguous service desk targets
  9. Missing reports metrics

With the above, we are on-track to cover all the required information into the document and share with the stakeholders for approval with minimal changes.  No pressure! 🙂


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! 🙂


The Cost-Charging Policy for Corporate IT

This morning, I have a constructive discussion with my boss to understand how do we as the IT Organization of the Company is being charged on the types of efforts, service level agreements and expenses through our Business/Operations.  Not to mention about how these costings are reflected in the Company’s Profit and Loss spreadsheet, the percent allocation to IT, to each P&L (short form for profit and loss) of each individual IT organization in a country from a regional perspective.

The business is trying to reduce the IT development costing from one of the Customer account I am managing and the topic of Corporate IT cost is being mentioned.  A substantial amount of the individual country’s P&L or annual funding as I presume is allocated to the local country’s corporate IT costing.  My doubts to the argument with my boss on this topic is what are the IT services/domains are covered in the annual allocation and from there onwards, we can determine the conditions in any SLA document (if we have at this point) that covered the parts of the development charges to be reduced.

Based on my experiences, general IT services like data migration, server maintenance, ad-hoc database scripts for data extraction and user administration’s activities should be covered as per in the SLA as a routine IT service charging.  However for any new developments to the solution, this should be a separate charging entity that we also terms as software development or release management as these are not routine IT service management activity and to be considered as a project itself.  We should not consider the resources being assigned to do IT support that is covered in the SLA to take away their headcount’s allocation for the project.  A IT project and IT service support should be treated as 2 different IT components in the Organisation’s costing.

June 2018
« Jan    


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

Join 465 other followers