Thursday, July 31, 2008

Risk Response Planning Strategies

Shamsher Haider PMP

You’ve made your risk management plan, identified the risks and done quantitative analysis and qualitative risk analysis. Now how do you do your risk response planning?























For risk response planning you must have your risk register and your risk management plan at hand. You would be more interested in planning for high risks first of all and risk management plan comes handy for the situation because it has the threshold definitions for low, medium and high risks. Risk register, the most important artifact in risk management process contains the list of identified risks ranked and prioritized after qualitative and quantitative risk analysis.



The risk register will tell whether the risk under consideration is a threat or an opportunity. Yes a risk can be an opportunity as well! As defined by PMI, project risk is an uncertain event or condition that, if it occurs, has a positive or a negative effect on at least one project objective, such as time, cost, scope, or quality. The strategy for managing the risk under consideration will largely depend on its being a threat or an opportunity.



Strategies for Threats:

Avoid: This means staying clear of the risk altogether. While avoidance obviously is the best possible course, it might not be feasible in all circumstances, e.g. the impact of the cost of avoidance might dominate the benefits of avoiding the risk. Avoidance can be accomplished by changing the process or the resources to attain an objective or sometimes modifying the objective itself to avoid the risks involved. An example of avoiding risk could be avoiding use of untested third party components in the software design, or avoiding inclusion of an inexperienced resource in the project team.

Mitigate: This means trying to reduce the probability and/or impact of the risk. Reduction in probability of occurrence would reduce the likelihood of its occurrence and reduction in impact would imply a lesser loss if the risk event occurs. 100% mitigation would be equivalent to avoidance. An example of mitigation would be an early verification of the requirements by prototyping before moving on to full fledged development.

Transfer: This implies transferring the liability of risk to a third party. While this strategy does not eliminate or mitigate the risk or its consequences itself, it transfers the responsibility of its management to someone else. Insurance is a classical example of this strategy. By buying insurance you transfer your risk to the insurance company by paying the risk premium. Fixed Cost contract is yet another example of risk transfer strategy. In a fixed cost contract the risk is transferred to the seller.

Strategies for Opportunities:

Exploit: This strategy involves removing all uncertainties pertaining to a positive risk and making sure that the risk event occurs. An example could be a situation where the seller will pay an incentive fee if work is completed a week ahead of the completion deadline. Ordinarily there is a probability that the work might get completed earlier, but if we plan to exploit this situation, we will plan to complete the work a week ahead to turn this uncertainty into a certain event.

Enhance: This strategy involves planning for increasing the size of the opportunity by increasing its impact and /or the probability of its occurrence. Identification of the root cause of the presence of an opportunity can help focus on the root cause and enhance its impact and / or probability.

Share: This strategy involves sharing the fruits of an opportunity with a third party because you do not have the capability to exploit it alone. Suppose your competitor is set to launch a new product six months from now, and you identify the opportunity that by launching a product with similar features a month before your competitor’s launch you can wrest the market away. In this particular scenario the situation becomes complicated because you have all the resources to launch your product in five months except a portion requiring device driver and hardware level programming. You can launch a joint venture with another company specializing in device driver programming to share the opportunity

Strategy for Threats and Opportunities:

Accept: Sometimes we identify a risk but realize that time and / or resources required to formulate and enact response strategies overweigh the results of the effort. In such a case we just accept the risk. If we plan to face the occurrence as it is, it is called passive acceptance. On the other hand if we develop a contingency reserve to handle the situation if the risk occurs, we call it active acceptance.

Contingent Response Strategy:

Also known as contingency planning, this strategy involves development of alternatives to deal with the situation after the risk has occurred. Active acceptance of risks leads to contingency planning, whereby we anticipate a risk to occur and instead of trying to mitigate or eliminate its occurrence we plan what to do when the event occurs. Contingency reserves are a commonly used tool to handle the occurrence of a risk event. Contingency reserve can imply allocation of cash, time or resources to cope with the situation when the risk event has occurred.
Fallback plans can be developed for high impact risks. A fallback plan as the name suggests, is the backup plan, in case the original contingency plan doesn’t work out as planned. An example could be identification of risk that a certain .Net programmer will resign in middle of the project. Since under the current circumstances you can do nothing to mitigate or eliminate the risk you accept it but develop a contingency plan to hire a certain programmer on hourly wages. To cope with the situation if no programmer is available on hourly wages at the time of resignation of your programmer, you develop a fall back plan of temporarily moving a software engineer from a certain low priority project to work on the assignment till an alternative can be hired.

Wednesday, July 23, 2008

How to save on PMP exam cost - A case for PMI Lahore Chapter

Shamsher Haider MCBMSP, MCTS, PE, PMP

If you are preparing for PMP exam follow the following steps and save a fortune on the overall process. I’ll specifically discuss the case for PMI Lahore Chapter, though the same may apply to a lesser or greater extent for other local chapters as well.
  • 1. Get PMI membership.
  • 2. Get your local chapter’s membership. (PMI Lahore Chapter’s membership comes free with PMI membership)
  • 3. Get enrolled in the training programs sponsored by PMI Lahore Chapter.
  • 4. Take the exam.

Why is local chapter membership so crucial?

PMI Lahore Chapter’s membership will save you Rs.10,000 (approximately $140) on the trainings sponsored by the chapter. Thus by paying $129 for PMI membership, you will be able to recover more than the amount invested in PMI membership as soon as you enroll for the training.

The exam fee is $555 for non members and $405 for members, that’s a difference of $150 in the exam fees alone.


Member

Non Member

Training with books / study material

$280

$420

Exam

$405

$555

PMI Membership fee

$129

$0

Total

$814

$975

The total saving in cost after paying the PMI membership fee is $161. In certain cases the exam fee is also fully or partially reimbursed by PMI Lahore Chapter. The great benefits that come with the membership are as under:

  • · Access to PMI’s knowledge base; Members have download access to PMI’s publications such as PM Network, PMI’s Career Track, Leadership in project Management, Project Management Journal, PMI Today and e-newsletters
  • · Access to downloadable soft copies of PMI standards documents including PMBOK.
  • · Invitations for chapter meeting, seminars and annual dinner weigh a lot in terms of of networking opportunities
  • · Opportunities to earn PDUs after getting certified

Monday, July 21, 2008

Managing Successful Public Sector Projects

Globally public sector IT projects have a reputation of having dynamics of their own and in our particular public sector cultural setup the situation becomes even more complex. Managing public sector IT hence requires a different approach than conventional IT project management.
Requirements specification is the very foundation on which the edifice of the project is erected. Wrong or misinterpreted requirements can thus lead to a typical death march project. The ailments inflicting our public sector environment make requirements management a Herculean task.

The Ailments

Lack of Ownership and direction
IT projects in public sector are typically initiated by a central authority designated by the government. The end user management in many cases is oblivious of the need for the initiatives and hence it becomes difficult for them to spell out their IT needs in precise terms. When the task of stipulating the requirements is delegated to the technical staff they fail to see the entire canvas and steer the requirements according to their own whims. Since the decision makers rely on their technical staff for assessment and approval of the work done by the suppliers, the project may snow ball to a size manifold it’s originally envisaged size
Since IT initiative is viewed as a low priority business in the government departments and contribution of the staff towards requirements specification initiatives do not add any value to their visible professional performance, the concerned officials give time to the requirements gathering resources more as a matter of personal courtesy than as a matter of professional obligation. In some instances resources assigned for gathering requirements had to wait for several days before they were able to get some time from personnel busy in their routine tasks.


Legacy Systems
Existence of makeshift legacy systems can prove to be a stumbling block too. An organization might have a number of scattered standalone applications with inconsistent data on different platforms and systems to cater for individual needs of various offices. As the users model their business flow around these systems, they start viewing the newly initiated IT solution as next version of their existing systems and try to mould the requirements in a way that at the end of the day the model that emerges is an integrated replica of the existing sub systems which might or might not be the ideal solution

Resistance to change and fear of transparency
One of the reasons for lack of cooperation is resistance to change and fear of transparency. Source of much of the power wielded by lower and middle tier staff is their ownership and concealment of information. Since an IT solution capable of hierarchical and public reporting has the potential for making the information transparent it might be viewed as a demon bent upon snatching the power and authority away from the bureaucratic machinery.

Security Issues
Entry into client’s premises sometimes proves to be a major problem. Security passes are usually valid for a short span and much of the requirements collection team’s effort is wasted in maintaining the validity of the passes.

Confidentiality of information and artifacts

It is not uncommon for public sector officials to implicitly or explicitly refuse access to any information perceived confidential. It is impossible to talk about business process automation or reengineering when the existing process is kept hidden in shrouds of confidentiality. The situation worsens when an incomplete or erroneous process description is provided to hide a fact.

Clash of interests
As the benefits of the IT initiatives become visible to the middle level management they start perceiving it as a means towards increasing their power by manipulation of the ownership/ visibility of data across the departments. From the organizational perspective the requirements might turn out to be out of synch with the organization’s rules and stipulated work flow. If a desperate stake holder manages to get such requirements incorporated in the specifications, it might lead the project to a quagmire due to the resulting interdepartmental political standoff at a later stage.

Volatility of requirements

Volatility of requirements is yet another predicament. Since the end users usually have a very vague idea of their needs, they begin realizing the actual potential of the IT solution once they see the implementation. It is not uncommon for the public sector users to request a multitude of additional features after getting the release as per their original requirements. Yet another reason for volatility of requirements is lack of interdepartmental consensus on requirements due to clash of interests cited above and a limited posting tenure of the senior officers. To quote an example there was a requirement for production of Machine Readable Passports (MRP) in a public sector project. A lot of effort and time was invested in the venture and the performing organization successfully produced MRPs which were verified by NADRA. Much to the dismay of the excited development team, due to posting of a high level stakeholder the requirement was changed overnight to production of conventional passports.

The Cure

While it is impossible to change the dynamics of the public sector mechanism, it is possible to adapt our project management practices to avoid the known pitfalls.


Ownership Leadership and Responsibility

Identification of a senior level owner and project sponsor in the end user’s organization is the most important factor in a public sector project.. Identification of a Senior Responsible Owner (SRO) in very initial stages can do wonders towards a projects success.

SRIE

  • A clearly outlined stipulation of the project objectives thus saving it from scope creep
  • Contribution in requirement specification process becomes a professional obligation for the middle and lower levels
  • Mitigation the difficulties associated with security and confidentiality of the artifacts
    Prototyping and GUIs

Investing some time and effort on prototyping is usually more beneficial than trying to make the Requirement Specification documentation more precise, since the later might be treated by the end users as a formality and it might be impossible for them to visualize the scenarios and interfaces until they get to see it on the screen. Since typically much of the rework is required due to changes in the graphical interfaces (GUIs) than the actual functionality, it is a good idea to get the GUIs finalized before starting actual implementation.


Mapping Existing Business Processes

It is generally expedient to directly map their existing business process in the automation, because an attempt to reengineer the basic flows might get accepted but most likely it would render the solution unacceptable later when it is actually used. In case of any apparent discrepancy regarding requirements given, officially published rules of business and official instructions manuals should be consulted and matter should be escalated where pertinent


Modular Approach


A key characteristic of the public sector projects is their size and complexity. No matter how well a public sector project is planned, the peculiarities cited above will ultimately drag it towards chaos. The best practice in this scenario would be visualizing the project as a collection of several small projects (chunks) and managing and delivering the chunks instead of trying to manage and deliver the project in its entirety. The feedback from a delivered module can help in further refinement of the understanding of requirements for rest of the modules