- Join over 1.2 million students every month
- Accelerate your learning by 29%
- Unlimited access from just £6.99 per month
Risk Management and Assessment for IT Projects.
Extracts from this document...
Dania Ghalayini of
Project Management and Control
Assignment One of Two
Risk Management and Assessment for IT Projects
IT Project Management Methodologies
2. An Overview of Project Risk Management
2.1 Risks and Project risk management principles
2.2 Effective Risk Management
2.3 The Elements of Project Risk Management (Risk Assessment and Risk Control(
• Identify Uncertainties (and Constraints)
• Analyze Risks
• Prioritize Risks
• Mitigate Risks.
• Plan for Emergencies.
• Measure and Control.
3. When To Perform Risk Identification
3.1 Risk Categories
• Technical, quality, or performance risks.
• Project management risks.
• Organizational risks.
• External risks.
3.2 Risk response strategies include:
• Risk Avoidance.
• Risk Transference/Deflection.
• Risk Mitigation.
• Risk Acceptance.
4. Selection, Evaluation and Initiation stages of IT Projects:
4.1 Selection Phase
4.2 Project Initiation
• Barriers and constraints considered as risks during the Project Initiation.
• Areas that can affect a project's risk level.
• Contingency plans used at this phase.
→Link the 2 parts of the assignment.
5. What is a Project Management Methodology?
6. How to adopt a Methodology?
7. Some methodologies:
7.2 DSDM Project Management
7.3 Achievement-driven Project Management: AdPM™
8.1 Risk Management and the PMBOK® 2000 Edition
9.1 Process Overview
• Guiding principles of the TenStep Project Management Process™
10. Comparison of TenStep to the PMBOK®
General Readings from Books (to know basics and concepts about the assignment subject)
Search the internet
Search for articles in the press
Start writing the assignment
IT project has deliverables: a delivery date and a budget, and each stage of the project lifecycle carry its own risks. Since IT projects are often difficult to estimate and manage, the project should not be allowed to go from one phase into the next until a formal Risk Assessment has been performed, in order to achieve deliverables and expectations and to meet with user's satisfaction.
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).
- 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.
- 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.
- How to adopt a Methodology?
To successfully implement a project management methodology,
- 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.
- Obtain an "Off The Shelf" methodology.
- There is also the hybrid option of purchasing a methodology and then customizing it to meet the specific needs of your organization.
- Some methodologies:
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.
- DSDM Project Management
The Dynamic Systems Development Method is a project methodology designed to deliver IT systems to tight time constraints without sacrificing quality.
- 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.
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).
- 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.
The TenStep Project Management Process™ is a methodology for managing work as a project.
- 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:
251 - 5000 hours
over 5000 hours
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.
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.
- 4PM.com Project Management Training & Consulting (2002). Achievement-driven Project Management: AdPM™. http://www.4pm.com/. Accessed 15th April 2003.
- AIMD IRM-Policies & Issues Group (1998). Information Technology Investment Evaluation Guide. http://www.gao.gov/ . Accessed 15th April 2003.
- Duncan, W. R. (ed.) (1996). A Guide To The Project Management Body Of Knowledge, USA: Project Management Institute.
- Hughes, B. and Cotterell, M. (2002). Software Project Management. UK: McGraw-Hill International (UK) Limited.
- Information Resources and Technologies University of St. Thomas. (2003a). IRT Project Planning Manual. http://www.stthomas.edu/irt. Accessed 15th April 2003.
- Information Resources and Technologies University of St. Thomas. (2003b). Risk Assessment and Management Overview. http://www.stthomas.edu/irt. Accessed 15th April 2003.
- Infopulse. (2002). Project Management Methodology. http://www.infopulse.ro. Accessed 15th April 2003.
- Key Skills Ltd (1998). PRINCE2TM. http://www.prince2.com/. Accessed 15th April 2003.
- Kumar, R. L. (2002). " Managing risks in IT projects: an options perspective ", Information & Management, 40(1), pp. 63-74
- Kwak, Y. H., Stoddard, J. (2003). "Project risk management: lessons learned from software development environment", Technovation, In Press, Corrected Proof.
- 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.
- Li, E.Y,Chen, H.G. (2001). " Output-driven information system planning: a case study", Information & Management, 38(3), pp. 185-199
- Metagy Ltd (2001). DSDM Project Management And Facilitation. http://www.metagy.com/. Accessed 15th April 2003.
- State Of Michigan Project Management Methodology (2001). Project Management Methodology.
- TenStep, Inc. (2003). TenStep Project Management Process™ (TenStep).http://www.tenstep.com/. Accessed 15th April 2003.
- Tilk, D. (ud) Project Success Through Project Risk Management.PricewaterhouseCoopers LLP.
- Tormos, P., Barber, F. and Lova, A. (ud) An integration model for planning and scheduling problems with constrained resources.
- Tusler, R. (1996). Reducing Project Management Risk. http://www.netcomuk.co.uk. Accessed 15th April 2003.
This student written piece of work is one of many that can be found in our University Degree Computer Science section.
Found what you're looking for?
- Start learning 29% faster today
- 150,000+ documents available
- Just £6.99 a month
- Join over 1.2 million students every month
- Accelerate your learning by 29%
- Unlimited access from just £6.99 per month