Impact Analysis

By Eugenio, on October 9th, 2009

“Sometimes it’s the smallest decisions that can change your life forever.”

This quote contains the nightmare of most Project Manager dealing with “issues”.

The necessity of creating and maintaining a high spirit among the stakeholders requires that any message is received and properly analyzed. Therefore, the system (the triad people, processes and technology) for collecting and sifting the “issues” shall be designed for processing efficiently a high number of petitions.

Scoping the “Impact Analysis[i]”

In essence, this is a process for evaluating whether or not there is a need for starting a proper Risk Analysis, that could be followed by a Change Request procedure. As said yesterday, The planning phase does not require a formal process like this; it is the Business Analyst task to collect and share the incoming requests.

Pricing the issue – the value of documentation

Issues are arisen when the production has started. This means that most of the resources (L.O.E. needs a special consideration) are allocated to defined activities. The time for well planned (bottom up) estimations has gone; however, it is still necessary to evaluate the adaptation of the plans to the new instances without creating disruptions (multitasking).

In yesterday’s post, there was a suggestion centered on the usage of triaging .Namely, having set three thresholds (proven, probably and possible) the first grade of evaluation consists into ranking the importance of the request into one of these three “categories”.

Having the complete documentation available (it should cover from scheduling to detailed plans where “major” activities are linked to functionalities and key producers) allows to make some basic questions:

Is the task on the Critical Path?
Are the dependencies (either functional or technical) highlighted?
Who is responsible for this item?
Is this person already “booked” on other critical activities?
After an informal chat, does this person/team grant his/her ability and interest in dealing with this problem?

These kinds of questions should be answered quickly and then registered (either in the “Daily Log” or in a specific section of the “Issue Register”) both for a short term schedule of ad hoc meetings and for future analysis (Learned Lessons).

Obviously, these questions are limited to the start of the process. The core question aims to evaluate the importance of the request from the “issuer” against the impact (alteration of the resources’ allocation and dimension – people, money, quality and time).

There is a template with a complete list of technical evaluations to be done for completing this process.

The “Impact Analysis” output

The “nominal” result will be contained in just one of these three words:

Accepted
Pending
Rejected

However, a well documented process offers a good deal of information for the next incoming requests. Being a very high recursively process – tracing all the dependencies can be related to the examined functionality (or procedure) is a work that can be “easily” mapped with tools (i.e. mind mapping[ii]). The whole “reverse” trip must include the Business Case in all its sections (from Reasons to Risks). A suggested template will be provided soon.

Cause and Effect diagram

The “Fish Bone” can offer a valid integration in the evaluation process. Notwithstanding the tool (see link[iii]) could reach a high level of complexity, the concept is useful for understanding and then explaining the reasons behind a choice.

Conclusion

In the new edition of Prince2, the product description has been included in the “Benefits Review Plan”. This fits perfectly with the communication to the upper echelons. However, a “detailed” outline of the product – as indicated in the previous version (see template) – can be very useful when dealing with the product manager or customer.

By the way, in the PMBook “Issue Management” has not been cited at all. “None is perfect”.

[i] http://en.wikipedia.org/wiki/Change_impact_analysis

[ii] http://freemind.sourceforge.net/wiki/index.php/Main_Page

[iii] Fish Bone diagram