Managing issues

Waterloo battle's plan

Waterloo battle's plan

On the Oct. 9th 2009, some items were added to the Issue Register body.

In the yesterday’s post, I finally was able to quote a good definition of “issue”.

Then, the topic was developed about the importance of sharing the same vocabulary for improving the efficiency of the communication.

Issues’ management

It is at the core of the project management. Issues arise only the rubber hit the tarmac. “No campaign[i] plan survives first contact with the enemy” said Von Moltke. Issues are the bullets shot at it. Capturing all of them, understanding where they are coming from who, and possibly understand the reason for pulling the trigger. These elements are an essential part of the process forming the stakeholders’ management.

On the operational viewpoint, these are the required actions for making the necessary adjustments to the previous plan. Adapting it to the new challenges (contained in each captured and well managed issues) makes possible to go ahead.

Issue production and management responsibility

Many proposed tools for managing issues are structured for logging and quick referencing its nature. This is a list of items forming the list:

  1. ID, fundamental for identifying the item during the whole process.
  2. Type.  Its nature:
    1. Request for Change.
    2. Off specification (the output does not respond to the “Acceptance Criteria” or Test).
    3. Problem or Concern.
  3. Date – both for reference and then to probe the quality (response time) of the issues’ management process.
  4. Author – the person who produced the issue.
  5. Description.
  6. Priority – this should be deemed by Impact Analysis and tagged with the agreed values (see post about Triage ).
  7. Severity – the level of management to be involved with
  8. Status – of the item during the process.
  9. Date of last update.
  10. Closure date.
  11. ID Impact Analysis

Finding the key elements -  4 Author

In the pm’s blogosphere there is flowing the idea of “self organized” teams (post).  To me, it is just another attempt to sell a good idea (delegation) waxed with lightweight version of concepts echoing Rousseau’s Emile: or On Education.

Empowering any stakeholder with the free and easy access to the Issue Register is an excellent tool for gaining participation to the project. Saying so, I am conscious of the potential conflicts created by misinterpretation of the arisen issues (to be read as an accusation, interfering in other department affairs etc.). These arguments can be tackled with a correct exposure of the current list. This will avoid a duplication of the listed topics and combines to maintain a public audit of the current project’s status.

5 – Description

The reason of projects is to deliver the functionalities ordered by the customer. Therefore, each problem (whatever is its classification) shall be clearly linked either to a functionality or the required activity. Sometimes, it can be referred to the process itself; however, this option should be included in the “dropdown list”.

6 – Priority

This is a value with two meanings. Paying attention to the correct management of it shall be extremely sensible. On one side, there is the person who has pointed out the problem; from his/her viewpoint the urgency cannot be obliterated by other considerations without a proper explanation.

On the other side, the project manager (and eventually the senior management) has to make his/her own decision about the effective impact of the problem on the project. The change, if any, shall be communicated to the author with a clear and sound explanation of the reasons, leaving out the chances of upgrading it.

7 – Severity

This is one of the two results (the other is Priority) of the Impact Analysis. Therefore, it is produced by the effort of the whole or at least a good part of the team. This topic will be developed in the next post.

The Project Manager, being responsible for this process, should focus his/her attention on the quality of the process more than its result. Henceforth, if the required effort is bigger than the available allowance, the issue has to be brought to the next management level; therefore, it needs to be probed in its consistency, instead of worrying about its impact on the professional image.

8 – Status

The range of possible statuses would depend upon the complexity of the process. These are the suggested items for classifying the necessary steps:

  1. received
  2. scrutinized – at PM level with the collaboration of Tech.Leaders. The scope of this is limited to address the issue to form the specific “interest group” (i.e. technical and other stakeholders who have specific information).
  3. processed - the “interest group” has been convocated for the analysis. It could result in an “expected reply date”

10 – ID Impact Analysis

Every time the PM decides to go for the Impact Analysis, the ID of the document (usually a report on the DB) shall be included for further references.

No exclusions are allowed

The importance of any alarm shall be properly assessed with the correct processes. Due to their nature (see previous post), they need to be assessed through the “Impact Analysis”. The result of it will give should to go through all the Risk Analysis process and eventually then start the Change Management procedures.

In any case, it is the Project Manager “responsibility” to separate wheat from the chaff.

The paramount value of the communication

Issues’ management involves all stakeholders. The success of the project depends upon both for the importance of the early and meaningful alarms and the sense of affiliation to the project itself.

In the (until recent) past, this process was maintained through the mailing of a spreadsheet among the managers of various levels. This way seems to confirm the policy of secrecy by obscurity; often this is accompanied by the innuendo that who whistle the blower (issue) was somewhat culprit of it.

Conclusion

This core process shall be created and maintained in tune with the existing company’s culture; especially for the need of profiling some information.

However, there is no reason for not praising the person who spotted the problem. If it has to be rejected, a good opportunity to reinforce the relationship has arisen.

I am conscious that my viewpoint could be tarnished of “paternalism”; however it is produced with the aim of being challenged.


[i] Campaign: a connected series of military operations forming a distinct phase of the war. [Merriam Webster]. Henceforth, the plans at the work-package level (just under the WBS) must be conceived for frequent reviews. This requires the availability of a strong (logically well founded) plan; namely the reasons sustaining the Business Case have to be developed in a way that smaller adjustments can be developed without too much friction.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you submit form:
Human test by Not Captcha