First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Saturday, 14 February 2015

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Punch" but not a literal one please! In this post I describe why and how I will do it. But in all circumstances I will aim to telegraph the punch first as to hit out without the recipient knowing it is coming isn't good for long term working relationships within the Project.
Telegraph your Punches as a Project Manager

The difficulties of being a Project Manager

As a Project Manager you typically need to achieve things through team(s) and individuals that you have no line management responsibility for. This is often call matrix management, I sometimes call it managing people with one hand tied behind your back :-) Despite this you still need to get the Project delivered dealing with any Issues along the way. This may need you to land some punches!

What punches can I land?

Like a fighter you need to understand "what punches can I land and where should I land them for differing impacts, sometimes to soften up, sometimes to put on the canvas?". So what are the possible punches?

1) Establish a Project Board to own the project or at a minimum a Sponsor who owns delivering the benefits of the Project. Once you have this in place you can use the Board as a whole or individual members of the board on an informal or formal basis to deliver a punch. Some examples of punches might be:
  • an informal chat with a Senior User because there is an issue with some business resources. The message might be "We have a problem with Fred who is not delivering to the agreed plan and is making lots of excuses. Can you please have a quiet word with him and get him on track else I am going to have to formally raise this at the next Board meeting?"
  • similar informal chats with other Board members for different resources
  • using the regular Project status reports to highlight an increased probability Risk or maybe an Issue depending on the strength of the punch required
  • changing the RAG status of the regular Project status reports to Amber (or Red) citing the reason for this being <the punch you wish to land>
  • formally escalating a Project issue to the Board requesting assistance from them for resolution - the nuclear option, not your first one
2) Establish an informal network of line managers for resources you are managing. This is often the first punch approach as a quiet word with the line manager may result in a change of approach by the "problem person"

3) There may be others possibilities in individual circumstances so put your thinking cap on, "how can I land a punch on this person or team?"

But telegraph your punch first

OK, so you have identified your range of punches. But don't overuse and try your hardest not to use because they don't aid team spirit. 

Firstly, I will give the team / individual every opportunity to fix the problem I have raised through a discussion or two on a one to one basis. Secondly I will telegraph the punch by saying something like "if you don't achieve x by y" or "if I don't see a change in attitude by z" then I will need to <describe appropriate punch>. In this way you have given sufficient warning and this will minimise negative relationship impacts of landing the punch. But there will be some impact as nobody likes being hit! 

Hopefully the threat of the punch achieves the desired result but sometimes it doesn't. If it doesn't then make sure you follow through with the punch that you said you would throw else your credibility will be lost (you have cried wolf).

In conclusion

Who ever said Project Managers can't learn from the world of Boxing? So work out your Project Management versions of the jab, right cross, left hook, uppercut etc. Threaten the punch first and try to avoid using if at all possible - but if you need to, please tell the recipient that it is coming!

Sunday, 1 February 2015

A Problem Shared is a Problem Halved

You are going to be extremely lucky not to have the odd problem occur during your Project life-cycle. Therefore you need a process to deal with this eventuality which is called Issue Management. You need to remind your team of the old adage A Problem Shared is a Problem HalvedHere are my tips on the Issue Management process within Projects.
Project Issues (hopefully not all excuses)

Raising and logging Issues

I typically maintain a Project Issue Log as a separate sheet within an Excel based combined RAIDs workbookIt should be located in the central Project File e.g. on SharePoint. It has fields such as:
  • unique ID
  • Status - Open / Close
  • (Project is a Programme wide log is used)
  • Description
  • Date raised
  • Who raised (if I raise on basis of someone alerting, I'll use their name)
  • Severity - I use what some might think are strange codes but it is to allow sorting AH (Awfully High) / H (High) / M (Medium) / XL (eXtremely Low)
  • Position / Comments which are free-form but my convention is to have dd/mm initials (of person making insert into comments)
Here is an example of one Issue from a recent Project



Logic would dictate that after a bit of education mentioning A Problem Shared is a Problem Halved, Project team members would diligently raise Issues by making an entry in the Project RAID log. Well in my experience there are one or two people who would do this and the rest are too busy, too lazy or don't think in that way. There are also some that would go over the top and put lots of "problems" which I don't believe should be on the Issue Log (see later on for discussion on this). And don't think that a quick bit of training is the solution, sadly Newton's 1st law of motion needs to be considered.

So taking the path of least resistance I ask team members to send me an email if they think there is a Project Issue. I also remind Risk owners that they should be monitoring their risks and alerting me if one materialises. 

I ask them to put "Issue" in the subject title too in line with good email principles but this may / may not happen thanks to Newton!

The benefit of the "email to PM" approach is that:
  • You can act as a filter on whether it truly should go onto the log (see below)
  • You are alerted earlier than say a weekly review of RAID log
Sometimes even a quick email is too much for a team member, chiefly because some team members don't think in that way / are super optimistic the problem will be resolved very shortly / "insert reason-excuse". So as you perform monitoring and control you should be on the lookout for anything which should be tracked as a Project Issue.

What level of Problem goes into Project Issue Management?

Should every "problem" someone has go into the Project Issue process? Let me demonstrate with a few examples 
  1. "Harry has a different opinion to Joe on a design"
  2. "I'm not feeling well today"
  3. "My PC has a problem which has delayed me by 3 hours I set aside to complete the specification document"
I'm sure there are different opinions out there but I wouldn't expect to see the 3 above in a Project Issue Log. The Project Team need to take personal accountability for tasks and the 3 examples above are just low level problems which an individual should handle although all have the potential to become Project issues, I will explain further on in the post.

The way I work the process is to (try and) educate the team to let me, the Project Manager, know of a "significant" problem which might for example:
  • effect achieving a key milestone or add significant risk 
  • a known risk materialising (owners will be monitoring)
  • delay to issuing draft document for formal review and thus likely to impact signoff date
So the three examples above, could become Issues in my terms:
  1. If Harry and Joe were both approvers of the design and the document author could not facilitate an agreed compromise
  2. Person has illness which means being away from work for a reasonable period (say > 1 week), this may create one of the conditions above
  3. If the document being drafted is delayed by a day then this would not be an Issue but if this person was stupid enough to leave it late just before a 2 week holiday, then maybe

What happens after the Issue is logged in the Issue Log?

My personal preference is to email round the Issue once raised as this is the lowest common denominator for communication and enables, if necessary, a discussion on next steps tracked against the issue . Things that the email should contain in my opinion are:
  • The Subject should be of a form to enable easy email searching. I tend to use <Project short name> <"Issue" #number> <Issue description cut from the Issue Log>
  • Some points on the Issue
  • Make it clear who is accountable for owning the resolution strategy to the Issue
  • any pressing timescales for resolution? (is this issue affecting the plan critical path)
  • copy in interested parties

Issue Monitoring

I adopt two approaches with regard to Issue monitoring:
  • for certain I will review the RAIDs Log as part of my Project status reporting cycle, which I prefer to be weekly ideally on a Friday. This may cause me to chase for updates typically using the email trail established above unless it is urgent in which case I will approach the issue owner in person / telephone
  • on some bigger Projects or Programmes I will look to schedule a formal weekly RAIDs review meeting with a number of key participants from the team. I will typically pick a review topic of the week and ideally go through, say Risks one week discussing a list sorted on "Risk score" and requesting any new risks
I use the Position / Comments column in the Issue Log to allow updates on status to be recorded with date and initials. Once the issue has been resolved, the status can be marked in the log with a closing comment made.

Escalating Issues to the owning Sponsor / Board

For some Issues, you may struggle to resolve them within the Project team. Sometimes it is necessary to involve the owners of the Project either on an informal or formal basis. I will return to this topic in a future post.

Conclusion

Issue Management defines the recording of Issues defined at an appropriate level and the ongoing management and monitoring of resolution activities which need to be undertaken by individual Issue owners assigned on a case by case basis. Sounds simple!

Twitter Delicious Facebook Digg Stumbleupon Favorites More