Equipping staff with the correct skill sets

Project_Management_(phases)Since I seem to be in the mood of drawing on my previous experience with the Air Force, I thought I will like to highlight another challenge that Project Managers in my region seem to be facing, and it is something that PMs need to be aware of as it can lead to major problems in project execution.

In the Armed Forces in general, there is an established structure and process where everyone starts from ground zero as a recruit and works his way up the system by picking up skills sets and being developed according to his aptitude (or at least that is how it is supposed to work!) If you are going to be assigned to a commando unit, they will make sure you go to commando school to learn the skills of the trade. Likewise, if you are identified to join the Air Force, you will be assigned to Air Force School to make sure you are grounded in the philosophies of the Air Force and have the necessary knowledge and expertise before being shipped out to the units.

Shockingly, in the corporate world where there are always concerns about expenditure and focus on budget cuts, staff may be deliberately put into situations that they are ill-prepared for. There is a general reluctance to spend on training staff due to the costs (both monetary and time) and the possibility that the staff may leave the organization before applying his skills fruitfully. Too often than I dare to count, I have seen people being assigned to projects that they may be ill-prepared for, but training is given lip service in the guise of “on-the-job training” where the poor soul is expected to be given a baptism of fire and come out as wisened and more competent — if he is not already burnt to a crisp.

Where possible, training should always be part of a project plan especially if the skill set may be lacking in the current resources. If it is unimaginable that an Air Force storeman can be deployed into a theatre of war as an Airborne Ranger since it may jeopardise the mission, it is also unimaginable that we should allow untrained personnel to be force-fit into the project to perform tasks that they are ill equipped for. Not training the staff to take on the project challenges is a risk. Period.

As I have seen in a somewhat humourous article before, there was this interesting conversation between a HR Manager and a Project Manager.

HR Manager: No, you cannot send this person for this expensive training course! What if he goes for the course and leaves us next month?

Project Manager: It will be even worse if he doesn’t go for the course and learns the necessary skills.¬†And he stays with us for years…

Situational Awareness in Project Management

aircraft-380740_640Back when I was serving in the Air Force, one of the important principles that they drilled into all personnel — regardless of whether they were pilots — was “situational awareness”. For the pilots, this could be a matter of life and death as they had to be constantly aware of their environment to any possible dangers. Other than the obvious dangers of being engaged by enemy aircraft, there was also the challenge of keeping that chunk of metal in the sky!

Dangers can be posed by terrain, engine failure, inaccurate instruments, etc. For the non-pilots, the emphasis was more on safety — personnel and equipment safety. Any mistakes made during training or operations can result in expensive equipment being damaged or personnel (who are also expensively trained) being hurt.

In the context of project management, it will help to keep one’s ears up and have your personal “radar” switched on to detect if there may be any factor that can affect the success of your project. Possibly a merger with a larger competitor which already has implemented something you are working on? Some other project that senior management has initiated and will take resources away from your project? Some key personnel who are vital to your project’s success leaving the organization? These are undoubtedly factors that can contribute to the success or failure to your project and will have to be highlighted as risks if you want to keep the project on course.

You should not be shy to approach the steering committee or project sponsor if you feel that the project is coming to a point where it may be canned. It can still be considered a success if you practice situational awareness and pull precious company resources and time from a project in a timely fashion once you have confirmed that the project is no longer viable.

Taking a step back

The average workday can be so full of operational and project tasks that the PM is simply inundated and may be stuck in a “reactive” mode where he is only able to react to things happening around him rather than taking a proactive approach to nip problems in the bud.

Whenever such a situation threatens to take place with you, one of the approaches can be to simply stop whatever you are currently doing, then take a step back and reassess the situation and the predicament you are in. In warfare tactics, this is known as a “strategic retreat” where some ground is given up to the enemy in order to regroup your resources, reassess the situation and redeploy resources in a more effective manner. By doing this, you may be able to find that some of the tasks that you were heavily involved in may not be that important in the larger context of things or can even be handed over to another party who is in a better position to take on the task!

However, what if you are indeed in an unfortunate situation where all the tasks are of high priority and cannot be handled by any one other than yourself? In this case, you will probably have to raise a few flags and cut your losses by informing the stakeholders that the task pipeline is full and project triage will have to be enforced so that only those tasks that are highly valued by the stakeholders will remain in the pipeline.

Minute taking for Project Meetings

The taking of minutes always seems to be such a chore that there is almost a palpable sense of relief when one finds out that it is not his turn to take the minutes for a particular meeting.

While it may be possible for some meetings to have a minute taking schedule to allow rotation of people jotting the minutes, it may not be possible for some project meetings which are small or where the project manager (PM) is actually the lowest-ranked in the corporate hierarchy amongst the attendees — which means that the PM always ends up as the one taking the minutes.

I find this practise to be quite ineffective as it is difficult to be paying attention and being active in the discussion whilst jotting down notes for the meeting at the same time. Some of my colleagues have resorted to voice recording the meeting proceedings in order to participate actively in the discussions and write the minutes at a later time. However this also does not make good use of the PM’s time.

mindmapIn the ideal situation, there will be a Project Coordinator who will be able to assist the PM in such administrative tasks so that the PM can focus on actual project tasks, but that may be an impractical request in the current cost-cutting world.



My approach to this problem is to use a mind-mapping tool like Freemind to record the minutes so I can easily group the topics of discussion in a quick fashion and flesh out the meeting minutes at a later point in time. I can even send out the mindmaps as meeting notes if the attendees are receptive to it. In fact, some of the attendees have even approached me to find out how to use mind mapping tools as they have seen how effective it can be for note taking!

Domain Knowledge for Project Managers

books-155163_640There is a school of thought that domain knowledge is not a necessity for Project Managers (PM) as that should be left to Operations Managers or other Subject Matter Experts. PMs should be able to keep a tight rein on the timeline and make sure that things run according to schedule.

Well, if the PM had no domain knowledge to offer, then he or she better be able to keep the project under close control in terms of timeline and task execution otherwise there is nothing else for that person to offer! In the course of work, we have probably come across such people who can come across as quite pushy and it can be exasperating if they do not understand what is happening in terms of business knowledge but insists on keeping to a deadline anyway.

In my opinion, a PM should also have domain knowledge as part of our Project Management skills arsenal in order to get some credibility with the stakeholders as we will be able to understand what their discussions are about as well as even contribute to the discussions — as opposed to taking minutes and maintaining a task list to distribute to attendees of the meeting.

Working in the financial services industry, I find that domain knowledge not only makes it easier to grasp quickly any new project requirements, it also makes the job much more interesting as you will be able to put the pieces together and relate to the tasks rather than just blindly executing the project.


Planning before Initiating

In the PMI process groups, the Initiating process groups comes before the Planning process group and this is generally considered to be a best practise. However in some organisations, it seems like the Planning is done before Initiating especially when it comes to the budgeting period. Not sure if this is a phenomenon also experienced in other organisations outside of Singapore (do feel free to express yourself in the comments)

What this means is that a lot of high level guesstimates are done in order to decide the amount the amount that should be budgeted for a project — if it really does kickstarted in the first place! Inevitably there will be qute a substantial project buffer due to the lack of preparedness and the need to be have conservative estimates in case the project ends up with insufficient budget. While this may be one way to ensure that the project has sufficient budget and can be executed should it be initiated, it also means that the funds may be inaccessible to other projects that have a much higher chance of being initiated.

This inevitably kicks off a vicious cycle of “budget reservation” where the various stakeholders and potential project sponsors will maintain larger and larger buffers in their proposed projects just to have something in the kitty in the event there is another project that pops up which requires the budget. It does not need to be said that this is not in the best interest of the organisation, but this still happens in many places.

I suppose one way to fix this will be to turn the budgeting process around for these afflicted organisation. Instead of letting the various departments give wild estimates in order to secure a budget, perhaps the head office should assign a budget to the various departments to let them use as necessary. The amount to be budgeted can be based on the cost estimates of previous years. A pool of money should also be kept aside by the head office in the event that some departments really need to utilise funds beyond their alloted budgets. This reserved pool can only be used after the departments present their business case to the head office. I suppose the reserve pool will need to be larger for the first 3 years since this paradigm shift in budgeting may results in some initial cost estimations being off.

Breaking tradition for some IT PM articles

I will be breaking from the tradition of “3p||<” for a few articles that I need to host here.

This is necessary to meet the PDU requirements for the PMP certification, and I don’t think they will be particularly appreciative of me posting articles consisting of a maximum of 3 paragraphs and trying to get credit!

Managing Master Data Management

I worked for an organisation that had a big goal — to roll out Master Data Management across all the global offices (spanning the globe from Asia to the Americas.) To say it was a tough challenge was an understatement. There was a dedicated team from HQ that flew around the world to gather requirements in their efforts to build this “one system to rule them all.”

This mega-project met its demise within a few months when its entire team was disbanded and let go by the organisation. The project failed to meet its timelines and objectives quickly enough, but the fault did not lie entirely with them. I suppose the management buy-in was not strong enough across the globe and the obstacles faced were too many.

Any MDM project should have strong management backing and a small series of achievable goals for the initial phases. Whilst this may not be the only approach, it will help to take baby-steps towards achieving such a big goal.

Simplifying logic

Sometime in the past, I came across this piece of SQL code:
(CASE WHEN (a.DebitBalance – b.TotScaledDown) > 0 THEN a.DebitBalance – b.TotScaledDown ELSE 0 END)

Logically not wrong, but the number of mathematical operations can be cut further to increase processing speed.

Zoom in here
(a.DebitBalance – b.TotScaledDown) > 0

There is an arithmetic operation and a comparison operation here. This can be reduced to a single comparison operation with no loss in logic. The arithmetic operation is only executed when the expression is true, otherwise the literal 0 is returned.
(CASE WHEN (a.DebitBalance > b.TotScaledDown) THEN a.DebitBalance – b.TotScaledDown ELSE 0 END)

Of course I may be wrong as I was not able to do any benchmarking to compare the code performance.