Decide how data will be captured during the project and used in the future
Every implementation project will collect data. At a minimum, it should collect the various objectives throughout the organization along with the associated risks. Why objectives? They are the context for the risks. It is much easier to initially identify these organizational objectives, at whatever level of specificity is appropriate, than to simply start brainstorming risks without a context. They could be strategic objectives, department objectives, individual objectives, or any combination of these. Once the objectives are identified, though, the associated risks are often obvious and intuitive.
As this information is being collected, the project leader must devise a method for organizing it. The identified objectives should be associated with individual units and/or people. Risks should be associated with specific objectives. Beyond that, an implementation project may commonly wish gather and store information relative to:
- Ranking the relative importance of individual objectives and risks
- Linking lower level goals to the higher level goals that they support
- Rolling up information so that managers can see views that incorporate the totality of their responsibilities
-
Ongoing monitoring whether objectives and risks are in line with expectations (key performance indicators and key
risk indicators) - Identifying processes (internal controls) that help to mitigate specific risks
Tools exist to help manage this data. Some tools are more flexible than others. Problems can arise when a tool is used that is either inflexible or requires a significant
Management should also consider how this data will be updated. Will it be maintained by a wide variety of people throughout the organization or will it be centrally administered? Will some pieces of this data be updated as an integral part of the management process (e.g., in some cases perhaps daily) or will it only be updated as part of a recurring specific project?
Critical Implementation Requirement
Decide what data will be captured during the implementation project, how much will be captured, and how it will be stored.
Determine how and when risks are to be rated
A common goal for an implementation project is to rate or rank the identified risks. Some organizations choose to rate these items, using a common scale, as they are initially identified. The advantage to this approach is that the conversations that identify the risks are often with the same persons who have the most knowledge to also be able to rate the risks.
There are disadvantages, however, to immediately rating the risks as they are identified. Often, more senior managers are in a better position to apply meaningful ratings than lower level managers who work with these risks day-to-day. At the lower levels of the organization, a risk may seem critical to a person because it is the primary focus of their job. To more senior managers, however, the risk may be of far lesser importance to the organization overall.
It is often more advantageous to ask the person who works with the risk day-to-day to rate the likelihood that the risk might actually occur, but to have more senior people provide the value for the impact of that risk upon the organization.
Critical Implementation Requirement
Determine at what point numbers or other rating scales will be applied to objectives and risks as they are identified in the implementation project.
The next post will talk about the two final implementation project considerations.