Feeds:
Posts
Comments

Archive for February, 2009

Following up a previous post on “fools with tools” I was recently asked what I would do if a team member does not want to use a standard tool or template, let it be, for example, a change request form or an issue table in a status report, for he/she does not see the value of doing so.
First of all, if you as a project manager created and introduced the tool and/or template you probably have done for a good reason. If a team member does not see the value of it there is an obvious information gap. Either the team member just doesn’t get it or you have not explained the need for the tool or template and the value which comes from them. Hence, before you blame anybody else ask yourself the question if you have missed part of the story by yourself.
If this is not the case, let’s hope this holds true for we are all good and effective project managers and leaders, you may want to consider the following option: ask the team member to leave a comment in the respective tool stating that he/she does not want to use the tool. Make sure that he/she understands that this form of documentation may be escalated. And that he/she will be held personally responsible if any new issues arise from non-compliance with standard project tools. Chances are that the team member will give in.
Sounds too easy? True, for as attractive as the second option looks at first sight, it does not resolve the source of the problem. Actually, there could be quite a few reasons for the behavior of the team member. He/she may have time management problems, does not know how to access or use the tool, is afraid of technology, or does not see the value of using it. You, as a leader, have to identify the root cause and face it. If you don’t do it, you become part of the problem for you are not exercising good leadership skills.
If all effort fails and the team member still does not use the respective tool and you cannot resolve the issue, it is time for escalation. Depending on the situation and organizational environment you can talk to the line manager of the team member or if you have the organizational authority to do so replace the team member with someone else. This may be the last resort. Still, if this is what it takes to lead your project to success, do it. Follow through. If you don’t, you are not doing your job, i.e., manage a project to success.

Read Full Post »

I have recently worked on a project which consisted of several sub-projects.  Most of them were running smoothly, i.e., milestones were met, deliverables were generally of good quality.  Unfortunately, there was one project which continually was running late.  The project objectives were clearly defined, there was a work breakdown structure the sub-project manager helped create and bought into.  In short, the setup looked promising.  Alas, reality looked different.  Deliverables were incomplete, late and of poor quality.  Colleagues and consultants helped the sub-project manager in his work.  Still, performance was dismal.  Adding to complexity the sub-project manager became sick for 3 weeks right after the Christmas holiday.  The designated stand-in attended weekly project meetings.  But he explained that he was not able to fill in for the sick project manager because this would have meant to neglect his other work.  What a stand-in!  What good does it do if you have someone standing in for you in case become sick and this person cannot replace you for various reasons.  Oh well, buttom line was that work in this sub-project basically laid still for 4 weeks.   Once the sub-project manager returned the project manager and consultants met with him to lay out a roadmap to recover the late sub-project.  Again, the sub-project manager actively participated in this exercise, committed to the newly planned deliverables and milestones.  Did anything change?  Unfortunately not.

What went wrong?  Colleagues and consultants pointed out to the responsible project managers that there were evident signs that the sub-project manager was simply not up to his task.  He had lots of practical experiences in his field of expertise but it was the very first time that he was asked to manage a project.  The organizational supervisors believed that given his experience and academic training he had to be qualified to manage and lead a project.  Sounds familiar?
It makes me wonder what drives this faulty conclusion.  Project management can be learned, there is no doubt.  But it also takes a certain mindset and attitude.  A strong project manager is solution and results oriented, has the drive to finish things. And he knows his limits, knows when to ask for help, when to raise an issue, how to identify risks.
In the case described above this was not the case.
So what could have been done?  If all fails, replace the sub-project manager.  Leadership involves making decisions.  Even when they are not pleasant.  In case of a non-performing team member who is endangering the success of a complete project the project leader has to react.  In the situation above this would have meant to “sack” the sub-project manager, replace him by someone else or distribute the workload to other team members capable of managing it.  If the project leader cannot make this decision because, for example, he is endowed with the organizational authority to do so, the issue needs to be escalated to the organizational supervisor.  If the supervisor does not react either, the issue has to be escalated to the project sponsor who has to make the ultimate decision.  At that point the ownership of the issue and its resulting risks is being transferred to the project sponsor.

Not taking any action, downplaying an obvious problem, not actively mitigating a risk is not leadership.  It is true that some issues may be resolved by inaction, letting the dynamics take care of it.  If done so on purpose and for good reasons, fine.  Principally, I think this is the wrong approach.  One of the pillars of effective leadership is ensuring delivery and results.  If it requires to sack a non-performing team member, so be it.  This reminds of how a mentor of mine, Neil Whitten, desribes a good project manager, stating that “a good project manager is a benevolent dictator”.  Think about it.  I believe that is a lot of truth in this.

Read Full Post »