Archive for the 'Work Communication' Category


Organisation of a Financial Advisory Firm

I had been working on 1 year project that to setup a new Financial Advisory (FA) firm locally in Singapore.  There are lots of discussions with the parent Company, setting up the new FA’s organisation structure, the agents’ structure and roles & responsibilities between FA and parent financial institution.

Lots have been working on and today, I like to share the high level target operational model for this FA.  The organisations required are:

  1. Distribution Support (Agency Management, Compensation)
  2. New Business
  3. Client Services
  4. Claims Services
  5. Product Development
  6. Training & Competency
  7. Compliance
  8. Finance Accounting
  9. Human Resources
  10. Risk Management (includes Business Continuity planning)
  11. Technology Services
  12. Shared Services (outsource, if any)

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


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.

Work Ethnics, Personal Health, and managing Work Bullies

Does ethnic in one’s professional work exists in our daily work activities?  One will wonder and it is hard to draw a line to understand how we can contribute to the Company and as the same time, being ethnic and partial in delivering those results.

The definition of work ethnics say that it is not just about setting values based on diligence and hard work, it means a set of virtues and know what to get things done in the right way (Reference:

Should a staff being punished for her bad duties/results for ensuring things are done rightfully and in view to protect her Employer’s liability?  For the Management, they view the employee is not able to cope with the stress and they do not care for the health of the employee but only for the profits.  No matter what, the staff has to make a decision to take care of their personal health first.

Working with work bullies is inevitable and it happens all around the world.  We have to manage them and concentrate to develop our strengths to get things done and building our self-esteem.


Being a Forward Thinker and Good Decision Making Skill

Everyone will experience times when to decide  to raise an alarm to the stakeholders on any potential issues that post risk to the project schedule, cost and scope.   In fact, majority will feel that it is not the right time to do so or may feel that it is unnecessary while getting the project teams to solve those problem before the risks accumulate.  As the saying goes, the project team is supposed to solve the problems, rather than disturbing the stakeholders with trivial issues that do not post any risks at that moment.

Good decision making doesn’t means you have pointed out a good decision, rather it is the process to flag any issues for discussions and result in the decision making with the stakeholders.  Even if the decision is not made at that time, we have take the opportunity to reason, analyse and do not allow any chance for a problem to suddenly present itself as an obstacle to complete the project.

The process in decision-making involve:

  1. Collects all relevant information
  2. Asks for recommendations and advice from other stakeholders
  3. Sets deadline before the decision must be made
  4. Make the decision and announce it with the reasons behind it to all who are involved

Nobody will be a perfect decision-maker but without using the proper process to derive the reasonings, wrong reasons are dervied for the wrong decision after the project delay.


Effective Meetings with Stakeholders

Most project meetings are always over-do or not following according to the agenda or the topics are out of sync from what the presenter is really trying to bring out.

We need to acquire the effective ways to bring out the points to the stakeholders to deliver and close with the maximum impacts that are to bring to the stakeholders.  Herewith are my personal tips on how to prepare for effective meetings.

  1. Keep the meeting on time
  2. Keep it short and sharp
  3. Involve your audiences
  4. Open the meeting effectively to stimulate interest
  5. Communicate persuasively and effectively
  6. Involve your stakeholders in discussions

When preparing the presentation materials:

  • Understand your objectives for the meeting
  • Understand your audience’s needs and their expectations
  • Highlight key issues for discussion
  • Use visual aids appropriately

Conflict Management, to Negotiate and Resolve Them

Working as a Program manager, not only do we need to acquire the skills and knowledgeof managing projects, strategy alignments and understanding of financial analysis/reports, we must acquire the ability to negotiate and salve kind of difficult situations to maintain a win-win settlement between ourselves and the parties involved.

The relationship with the Customer is long-term and along the path problems may boil to surface from time to time.  There are ways to manage them and herewith are the negotiation styles tha can be used:

  1. Problem Solving – engaging both parties to try to find solutions that work best for each other.
  2. Compromise – a situation where both parties give in more or less regardless on how that will meet their needs.
  3. Agression – only one party forces concession from the other side.

When the negotiations gets aggressive, and involves threats and demands this will affect the relationship with the Customer.   As such, we need to resolve the conflicts.  The ways we can do to cool down the conflicts when facing the aggressiveness are:

  • Calm ourselves down.
  • Show them our willingness to work things out by talking about the issue rather then escalating it with more agressions.
  • State our point of view in a neutral tone than in an argumentive tone.
  • Try ways to resolve the dispute, and working together to find the solution that both sides can embrace/accept.

The above are strategized for win-win solutins for both parties.  It is not that simple to execute the above as it requires oneself to build the competence of self-awareness, self-confidence, self-control and empathy.

June 2018
« Jan    


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

Join 465 other followers