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 Halved. Here 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 workbook. It should be located in the central Project File e.g. on SharePoint. It has fields such as:

unique ID
Status - Open / Close
(Project if 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 benefits of the "email to PM" approach are 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 that 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

"Harry has a different opinion to Joe on a design"
"I'm not feeling well today"
"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:

If Harry and Joe were both approvers of the design and the document author could not facilitate an agreed compromise
Person has illness which means being away from work for a reasonable period (say > 1 week), this may create one of the conditions above
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!