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
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"
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?
- 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!
0 Comments