Risk Management and Assessment for IT Projects.

Some examples are:

• Failure to understand who the project is for (selection phase)
• Failure to appoint an executive user responsible for sponsoring the project (initiation phase)
• Failure to appoint a fully qualified and supported project manager (initiation phase)
• Failure to define the objectives of the project (selection phase)
• Failure to secure commitments from people who are needed to assist with the project
• Failure to estimate costs accurately (evaluation phase)
• Failure to specify very precisely the end users' requirements (selection, evaluation and initiation phases)
• Failure to provide a good working environment for the project (initiation phase)

Analyze Risks

Define the expected impact of risks on schedule, budget, and ability to meet the user's requirements.

Prioritize Risks

Rank risks (very low, low, moderate, high, and very high) or work breakdown structure level, such as Phase, Activity, and Task.

Mitigate Risks.

Is to reduce the probability or the impact of risks. An example is building a pilot phase of the project.

Plan for Emergencies.

Are predefined action plans that can be implemented if identified risks actually occur; it uses allocated contingency reserves, depending on the risk's impact.

Measure and Control.

To monitor risks and take appropriate action to prevent it from going on, or to take recovery action if the problem occurs.

3. When To Perform Risk Identification

Risk identification is a recurring event. And risks exist throughout every stage of the project life cycle, even the project early stages of selecting, evaluating and initiating projects.

4. Risk Categories

Sample categories that might exist during IT Projects early stages include:

• Technical, quality, or performance risks. Examples include reliance on unproven or complex technology, changes to the technology used, and changes to industry standards during the project.
• Project management risks. Examples lack of project manager delegated authority, and use of project management disciplines.
• Organizational risks. Examples include cost, time, and scope objectives that are internally inconsistent, lack of prioritization of projects, inadequacy or interruption of funding, and resource conflicts with other projects in the organization.
• External risks. Examples include a shifting legal or regulatory environment, labor issues, changing customer priorities, local-based risks, and weather. Also vendor contract risks, including contractor relationships.

5. Risk response strategies include:

• Risk Avoidance. Is changing the project plan to eliminate the threat of a specific risk event.
• Risk Transference/Deflection. Is to shift the consequence of a risk to a third party via a contract provision. Noting that transferring the risk to another party does not eliminate it.
• Risk Mitigation. Is reducing the probability and/or the consequences of an undesirable risk event to an acceptable threshold.
• Risk Acceptance. Deals with, the consequences of a risk event, either actively (developing a contingency plan) or passively (accepting the consequences).

4. Selection, Evaluation and Initiation stages of IT Projects:

6. Selection Phase

It consists of 3 phases: Screening, Evaluation, and Prioritizing. The costs, benefits, and risks of all IT projects are then assessed, and the projects are compared against each other and ranked or prioritized. The systems and projects that are selected for funding make up the portfolio of IT Projects.

• Screening

Is preparing and collecting data that will constitute inputs for the Evaluation Phase.

• Evaluation

Uses information gathered in the Screening Phase, to determine whether the idea warrants a project effort, integrates into the organization strategy, fits within current budget constraints, and whether the idea conflicts with ongoing projects. This phase may include the use of technological forecasting.

• Prioritizing

Some techniques that can be used are:

• Checklist/Scoring Models: a spreadsheet-type analysis weighting various projects.
• Cost Benefit Analysis: a comparison of benefits from completing the project versus the outcomes of not instituting the project.
• Risk Analysis.
• Decision Trees (flow networks).

7. Project Initiation

The purpose of the Project Initiation Phase is to specify what the project should accomplish.

Some Barriers and constraints that might be considered as risks during the Project Initiation are:

• Project Team Frustration

The project staff wants to get the project moving and to start designing the solution, which never seems to come.

• Lack of Management Commitment

When too little is known about the idea of the project.

• Customer Indecision about definitions and concepts of what the required product or service is to provide.
• lack of Resources
• Lack of Coordinated Leadership
• Lack of Consensus on Project Objectives

Lack of objectives can kill a project before it starts

• Lack of Management Support/Sponsor
• Lack of Business Strategy and Expected Outcomes within the Organization

There are various areas that can affect a project's risk level:

• The technology used on the project
• The environment in which the project is executed
• The relationships between team members
• Conformance of the project with the culture or business area or strategic objectives of the agency

Some contingency plans that might be used at this phase are:

• Using the agency’s business strategy and strategic objectives as a baseline for consideration for project initiation will save time and effort later. (Can be used at the project selection phase)
• Include an assessment of the customer's involvement in the definition of the technical product specifications, and the potential for these requirements to change.
• create surveys, and interviews with users, to collect necessary data in order to have a full idea about the users needs. (can be used at the project selection phase)
• Try to engage customers, stakeholders and users. (can be used at the project selection phase)
• Provide appropriate training
• Hire trained specialists
• Install temporary hardware
• Utilize internal hardware temporarily
• Purchase additional equipment/facilities
• Implement product functionality in a phased manner
• Get agreement on who has decision authority; designate customer project coordinator (can be used at the project selection phase)
• Locate project team in our offices
• Negotiate better environment
• Ensure that all the resources are provided
• Suggest/sell functional specifications before development
• Unilaterally develop functional specifications
• Adjust deadline and get Customer buy-off
• Do not commit to third party performance
• Get third-party commitment at least equal to (if not more than) commitment
• Get customer commitment to participate in the project
• Increase estimates for the related tasks (can be used at the project evaluation phase)
• Do not commit to a resolution time unless absolutely necessary and then only if a study is done by knowledgeable persons (can be used at the project evaluation phase)
• Establish access to product support personnel
• Hold regular meetings with customer
• Maintain constant written and oral communication with remote personnel
• Visit remote sites as needed
• Demonstrate incremental results
• Divide staff into teams and assign team leaders
• Dedicate management resources
• Establish final authority of project manager
• Use proven hardware for development if possible
• Reduce functionality to meet deadline
• Document assumptions and understandings and get customer signoff before investing substantial resources

Considering the fact that the System Development Life Cycle and Project Management Methodology are two different processes, it may be difficult for the project manager to distinguish between the two and discern his role within each process. The intent of the methodology is to integrate the need for project management with the processes performed in the System Development Life Cycle.

The figure below, compares the Project Management Phases against the steps in the System Development Life Cycle over time.

5. What is a Project Management Methodology?

A methodology is a documented method or system adopted by organizations for the management of projects, to guides the whole course and life of a project, ensuring that all the correct steps, reviews and approvals are completed to minimize the likelihood of failure of a project.

6. How to adopt a Methodology?

To successfully implement a project management methodology,

1. Develop you own. The benefits to the organization will be dependent on the skills and experience of the developers and may take a long time to bear fruit.
2. Obtain an "Off The Shelf" methodology.
3. There is also the hybrid option of purchasing a methodology and then customizing it to meet the specific needs of your organization.

7. Some methodologies:

8. PRINCE

PRINCE is an acronym for PRojects IN a Controlled Environment. The methodology was extensively revised and broadened in 1996 to cover all types and sizes of projects and re-released as PRINCE 2.

PRINCE 2 is a structured method for effective project management.

9. DSDM Project Management

The Dynamic Systems Development Method is a project methodology designed to deliver IT systems to tight time constraints without sacrificing quality.

10. Achievement-driven Project Management: AdPM™

Is built upon the Project Management Institute's PMBOK™ concepts with tools and techniques that add a strong focus on:

• Building dynamic project models to simulate alternative ways of doing the project.

8. PMBOK

One of the recognized standard project management methodologies is the Project Management Body of Knowledge (PMBOK), which is the standard put forward by the Project Management Institute (PMI).

11. Risk Management and the PMBOK® 2000 Edition

The risk management knowledge area was significantly revised in the 2000 edition of A Guide to the Project Management Body of Knowledge (PMBOK®Guide). In the 2000 edition, there are six processes in risk management:

• Risk Management Planning: how to approach the project’s risk management activities.
• Risk Identification: determining the risks that might affect the project.
• Qualitative Risk Analysis: analyzing conditions and risks qualitatively to determine and prioritize their impact on project objectives.
• Quantitative Risk Analysis: determining the probability and consequences of risks and estimating their impact on objectives.
• Risk Response Planning: determining how to enhance opportunities and minimize threats to objectives.
• Risk Monitoring and Control: executing risk response plans, monitoring risks, identifying new risks and evaluating the effectiveness of responses.

9. TenStep

The TenStep Project Management Process™ is a methodology for managing work as a project.

 

12. Process Overview

The TenStep Project Management Process™ is a scalable process based on the size of the project. All of the basic TenStep processes provide guidance based on whether the project is small, medium or large. Each organization that utilizes TenStep needs to determine what criteria it will use to classify projects. TenStep uses three basic criteria for determining overall project size.

The first is the estimated effort of the project. The general guidelines utilized by TenStep are as follows:

The second factor is the experience level of the project manager.

The third factor is the complexity and business criticality of the project.

.

Next, start at Step 1.0 of the TenStep Project Management Process™ - Define the Project depending on the size of your project.

Do the same for Step 2.0 - Build the Workplan, Step 3.0 - Manage the Workplan and Step 4 - Manage Issues. Start by understanding the recommendations for your sized project, and then add any activities from the other sized projects that will help your project. For the most part, all projects should follow the processes in Steps 1.0 through 4.0.

Now on to Step 5.0 - Manage Scope.

The rest of the TenStep Project Management Process™ works the same way.

• It is important to recognize that the ten steps of the TenStep methodology do not imply a sequential progression. So, steps 1.0 and 2.0 would be done before the rest. However, the applicable activities in steps 3.0 through 10.0 are done in parallel. This means that a project manager will be managing the workplan (step 3.0), managing scope (step 5.0), managing quality (step 9.0), etc., all through the project.
• The higher steps of the TenStep process do imply a higher level of project management sophistication. For instance, smaller projects do not necessarily need to manage documentation (step 8.0) since a small project typically does not have enough documentation to get messed up.

The following represent a set of guiding principles of the TenStep Project Management Process™:

1. A project management process must be flexible and scalable, based on the size of the underlying project. TenStep refers to this concept as "small methodology for small projects, large methodology for large project™".
2. The TenStep Project Management Process™ is designed to be applicable to all projects, regardless of the project life-cycle methodology used.
3. The project is at higher risk of failure without active participation from the client.
4. Project managers must have a sufficient level of authority to be successful.

10. Comparison of TenStep to the PMBOK®

One of the recognized standard project management methodologies is the Project Management Body of Knowledge (PMBOK®), which is the standard put forward by the Project Management Institute (PMI). The PMBOK® contains a lot of valuable information, and includes most all of the processes that TenStep contains. However, there is a difference in the packaging and emphasis. In the opinion of TenStep, Inc., the PMBOK® provides a basic foundation for understanding how to manage work as a project, but is not necessarily a methodology that you can take to manage a project directly.

On the other hand, there is nothing that is published in the TenStep Project Management Process™ that directly contradicts the PMBOK® either. The table below provides a mapping of some of the knowledge areas and project management processes within the PMBOK®, with the corresponding processes within the TenStep Project Management Process™.

 

11. Conclusion

To deliver successful IT projects that meet the three deliverables (budget, time, and customer satisfaction), project managers should spend time assessing and managing risk, and allocating contingency and management reserves, so that any risk that arises will be mitigated, following risk assessment and planning.

Without maintaining a contingency reserve, the project manager is forced to go back for additional time or dollars for every risk as it becomes a problem.

Also to attain successful projects, the project managers have to follow a good Project Management methodology to ensure that the project starts with a chance of achievement.

References:

1. 4PM.com Project Management Training & Consulting (2002). Achievement-driven Project Management: AdPM™. http://www.4pm.com/. Accessed 15th April 2003.

2. AIMD IRM-Policies & Issues Group (1998). Information Technology Investment Evaluation Guide. http://www.gao.gov/ . Accessed 15th April 2003.

3. Duncan, W. R. (ed.) (1996).  A Guide To The Project Management Body Of Knowledge, USA: Project Management Institute.

4. Hughes, B. and Cotterell, M. (2002). Software Project Management. UK: McGraw-Hill International (UK) Limited.

5. Information Resources and Technologies University of St. Thomas. (2003a). IRT Project Planning Manual. http://www.stthomas.edu/irt. Accessed 15th April 2003.

6. Information Resources and Technologies University of St. Thomas. (2003b). Risk Assessment and Management Overview. http://www.stthomas.edu/irt. Accessed 15th April 2003.

7. Infopulse. (2002). Project Management Methodology. http://www.infopulse.ro. Accessed 15th April 2003.

8. Key Skills Ltd (1998). PRINCE2TM. http://www.prince2.com/. Accessed 15th April 2003.

9. Kumar, R. L. (2002). " Managing risks in IT projects: an options perspective ", Information & Management, 40(1), pp. 63-74

10. Kwak, Y. H., Stoddard, J. (2003). "Project risk management: lessons learned from software development environment", Technovation, In Press, Corrected Proof.

11. Levin, G. (2001). " Risk Management and the PMBOK® 2000 Edition", ESI Horizons Newsletter. http://www.esi-intl.com/Public/index.asp. Accessed 15th April 2003.

12. , E.Y, , H.G. (2001). " Output-driven information system planning: a case study", Information & Management, 38(3), pp. 185-199

13. Metagy Ltd (2001). DSDM Project Management And Facilitation. http://www.metagy.com/. Accessed 15th April 2003.

14. State Of Michigan Project Management Methodology (2001). Project Management Methodology.

15. TenStep, Inc. (2003). TenStep Project Management Process™ (TenStep). http://www.tenstep.com/. Accessed 15th April 2003.

16. Tilk, D. (ud) Project Success Through Project Risk Management. PricewaterhouseCoopers LLP.

17. Tormos, P., Barber, F.  and Lova, A. (ud) An integration model for planning and scheduling problems with constrained resources.

18. Tusler, R. (1996). Reducing Project Management Risk. http://www.netcomuk.co.uk. Accessed 15th April 2003.