Project Manager Important Quality- Being Thick skinned

To illustrate, if a project team member is unhappy towards the PM due to some personal grudges and that being so after rounds of clarifications, the PM still has to take the initiative to approach that team member and involve him as part of the team.
That member may behave unprofessionally but the PM can't afford to. PM has to be thick skinned enough to engage that team member as part of the team.
Being thick skinned is a tool that the PM may employ to remain professional and objective especially if the Management doesn't discipline that team member or remove him from the project due to whatever reasons. The PM has to remain cautious too of any possible damages that team member may bring to the project. But hopefully, that team member will ask to be removed from the project after not being able to contain his frustrations while the PM remains cool, professional and thick skinned enough to involve him/her objectively.

Where Project Management & Industry Domain Meet

Having worked in a Telco environment, Manufacturing MNC, Government agency, Healthcare organization, aviation industry and my own startup company, I had the opportunity of working with different stakeholders, including those who have been in the organization for many years. I benefitted a lot by learning from resources who hold the domain expertise and in-depth organization climate knowledge.
From my end, having worked in different industry domains, I could contribute by bringing along a broader set of experience and knowledge on the use of technology as well as a strong management skill set of diversified user groups, domain experts and stakeholders.
One is not above the other. An experienced Project Manager would need these resources' in-depth knowledge of the industry domain as well as the organization culture and processes to manage the project effectively. Vice versa, these resources may not be able to function effectively as a Project Manager without any project management training.
What happened when a Project Manager possesses the experience and training in project management as well as the domain expertise? Well, he/she would be a well sought after Project Manager within the industry domain.

A Situation When There Are Too Many Cooks

Being a PM in a healthcare project that aims to deliver a GP Clinic Electronic Medical Record & Operation System with multiple external interfaces, I have to work with subject matter experts (SMEs) on several different streams due to the multi-disciplinary areas that are involved.

Each of these SMEs, assigned from other functional departments in a matrix setup, are driving their respective streams with the vendor.

To be effective in the management of the schedule and scope, its critical for the PM not to lose control on the progress of each stream. The PM should be able to build up the competency on each stream to a certain level fast and contribute effectively in the streams' discussions. Only with a fair amount of competency and "technical" knowledge in all the streams, the PM will be able to exert control and display creditability as the overall person responsible for the project.

Without being able to maintain control over the project, I have witnessed when all the stream leads attempt to lead the out-sourced vendor from different angles and the PM not able to manage and control the situation well. That contributes to the project complexity and risks as well as completely swings the vendor into position where they have to fulfill multiple different requests, thereby thinning their resources and losing control of the progress.

It is definetly a good sign when each SME taking the role as a stream lead proactively followup and push for their items to be achieved. However the PM needs to be able to convince, influence and value add as an overall person in charge of the project by effectively demonstrating he/she has a good understanding and knowledge of each streams' progress, issues, status and risks as well as an excellent integrated project view.

Only when there is one single, competent "cook", endorsed by the team to be made responsible for the project, can the vendor be well managed and the project progress smoothly in its schedule and scope.

Is it a wise move to outsource project management?

Imagine a IT service provider or main contractor S who outsources the project management portion to company A, systems integration portion to company B, building an integrated solution from 4 different product companies- companies C, D, E and F.
You may ask so what would be the role of the IT service provider S then? Well it would be just for pure account management and escalation of critical issues to the customer.

The fact that once the project management portion is outsourced it would mean the control is taken away. In one of my projects, that is exactly what happened. Company A while managing the scope creep, risks, issues and schedule delays as best as they could, their lifeline would remain there as long as they keep S informed and seek direction from S.
A has a difficult time managing B, C, D, E and F since S is the one who fronts the monetary and contractual stuff with B, C, D, E and F. A tries to keep everything professional and raises to S for any issues. S underestimates the criticality of the issues and brush the issues aside resulting in an accumulation of tension in the inter-working relationships among the different companies.
S also underestimate and remain out of touch with the issues the customer faces with the project since S relies on A to front them.
At the end of it, the project suffers resulting in frustrations from the customer, delay in the progress and scope mismanagement.

Is it a wise move then for S to outsource the project management aspect? Not in my opinion, cause project management is not just a delivery nor an adminstrative function for S. Rather project management means to S the vehicle to materialize the planned payment milestones in each of the project phase gates. Project management is core function to S in my view, and that makes it illogical for S to outsource it.

   

Argh...this is not what I wanted!

Analyzing and determining accurate user requirements is one of the most critical task in a role of a project manager (PM).
Sometimes simple requirements may also end up being misunderstood resulting in the wrong item delivered.
Like in my case last week, I had asked my brother to buy my first watch winder for my small collection of automatic mechanical watches. Simple right? He got one that looked like this:
Yah it look alright but it is so different from what I had wanted. What I had wanted was a watch winder that is more compact....more stylish looking that does not look like a box......what I wanted was a watch winder that looked like the one below.

After I overcame my initial disappointment and regained my logical frame of mind, I knew this could have been avoided if I had been more pro-active in describing my requirements for my first watch winder to my brother.

Instead of just stating my requirements as a watch winder that cost $xx, that could hold up to 6 watches, I could have elaborated on my requirements like compactness, without drawer, etc. Instead of assuming all watch winders are like the one I have seen before, I could have provided a supporting picture.

As PMs, we can't allow requirements to be vague, whether its requirements from users or our requirements to vendors else we will risk ending up with the wrong deliverables.

In a huge project, the impact is rework and incurring more cost. At a smaller scale, the impact is ending up with a wrong watch winder.
Cheers.