Docstoc

Risk Management Ford

Document Sample
Risk Management Ford Powered By Docstoc
					Carnegie Mellon University                 CMU-MSE-Mission Possible
School of Computer Science                                Fall 2003
Master of Software Engineering




                                          Mission:
                                          Possible

                                 Risk Management Plan
                                    November 17, 2003




                                                    Junjie Lu
                                               Jaime Oviedo
                                              Kasil Hariharan
                                                   Ming Zhao
Carnegie Mellon University                     CMU-MSE-Mission Possible
School of Computer Science                                    Fall 2003
Master of Software Engineering




Document Revisions
Revision    Date         Author(s)               Comments
  0.1    11/15/2003 Ming             Created document.
  0.2    11/17/2003 Ming             Revised document
Carnegie Mellon University                                                                                CMU-MSE-Mission Possible
School of Computer Science                                                                                               Fall 2003
Master of Software Engineering




Table of Contents:

1.       Acronyms ................................................................................................................................... 4

2.       Overview ..................................................................................................................................... 4
   2.1       Introduction ..................................................................................................................................... 4
   2.2       Document Overview ....................................................................................................................... 4

2 Approach ....................................................................................................................................... 5
   2.1       Identify Risks .................................................................................................................................. 5
   2.2       Assess Risks .................................................................................................................................. 5
   2.3       Analyze Risks ................................................................................................................................. 7
   2.4       Monitor Risks .................................................................................................................................. 7
   2.5       Mitigate Risks ................................................................................................................................. 7
   2.6       Resources Devoted to Risk Management ...................................................................................... 7
   2.7       References ..................................................................................................................................... 8

3 Risks.................................................................................................................................................. 9
   3.1       List of Top-10 Risks ........................................................................................................................ 9
   3.2       Details of Risks ............................................................................................................................... 9
Carnegie Mellon University                                CMU-MSE-Mission Possible
School of Computer Science                                               Fall 2003
Master of Software Engineering




1. Acronyms

MSE                   Master of Software Engineering
MP                    Mission Possible Team
AMC                   Automated Model Compiler
MoBIES                Model-based embedded software
RMP                   Risk Management Plan


2. Overview

2.1 Introduction

Last year, MSE studio team Synergy worked on the development of a model compiler
tool for the field of model-based embedded software development (MoBIES) for the
Ford Company called AMC (Automated Model Compiler). A model compiler is a tool
that automatically composes a larger assembly from a set of sub-models and an
architectural description of the arrangement of the sub-models. It ensures full
connectivity of all control flow and data flow signals between sub-models in the
assembly, proper sequencing of sub-models, and compatibility of sub-models. Our
studio project objective is to extend AMC capabilities, making it able to integrate some
of the functionalities of SynchroMod, a model repository tool that will provide means for
tracking process change, sharing information over an intranet / Internet and will promote
component reuse.


2.2 Document Overview

This document, the Risk Management Plan, describes our plan for managing risk
throughout the lifecycle of the project.

Section 2 describes our approach toward identifying and managing risk.

Section 3 has a list of risks we have identified, our assessments, and mitigation plans
for them.

Appendix A has a glossary of some terms and acronyms used in this document.
Carnegie Mellon University                                  CMU-MSE-Mission Possible
School of Computer Science                                                 Fall 2003
Master of Software Engineering




2 Approach

Our overall approach for managing risk throughout the project involves the following
steps: Identify, Assess, Analyze, Monitor, Mitigate.
2.1    Identify Risks
Throughout the project, we will consider risks to the successful completion of the
project. We will document those risks in the Risk Management Plan. We will continually
consider the project in light of risk and any new risks that come up will be added to the
RMP.

For discovery of the project risks and the definition of the response, the Mission
Possible (MP) team had an initial session in which it also defined the first version of the
top-10 risks list. This initial session consisted in the analysis of the actual situation,
study of the latest risk list of the Synergy project, the predecessor of MP and discovery
of new risks via brainstorming.

 The risk manager of the Synergy team also attended the meeting, shared his
experience in the previous project, and gave some advice related to risk management.
In the future, the MP team also plans to talk to a risk expert from the SEI because the
previous team did it with excellent results.

2.2       Assess Risks

The MP team wanted to use a prescriptive and verified methodology to discover risks
and chose the taxonomy-based risk identification method because it is rigorous, but
flexible and it has proven effective and efficient in surfacing risks [1].

The discovered risks were analyzed along three dimensions –time, cost, and
probability– according to the following distributions of values:

Timeframe

                    Timeframe      Description
                    Near           Within two months
                    Medium         Between two and four months
                    Long-term      More than four months

Impact
Carnegie Mellon University                                              CMU-MSE-Mission Possible
School of Computer Science                                                             Fall 2003
Master of Software Engineering



                    Impact                      Consequences
                    Low                         The project might come to a late end,
                                                satisfies the most important requirements,
                                                does not contain known bugs, and is likely
                                                to be used. Alternatively, the team faces
                                                severe difficulties.
                    Medium                      The project comes to a late end, does not
                                                satisfy the most important requirements,
                                                contains bugs, or is likely to be replaced in
                                                the future.
                    High                        The project fails, does not come to and end,
                                                or develops the wrong product. The client is
                                                very dissatisfied.



Probability

                    Low                         0% - 40%
                    Medium                      41% - 80%
                    High                        81% - 100%

Although in the beginning, the team considered scales of four values to avoid the
principle of extremeness aversion, which states that people tend to avoid the options at
the extremes. At the end, the team chose three values because personal experiences of
team members and advice from the SEI suggested that three values yield better results
than four do due the nature of our team and project.

The team assigned different weights to the impact and probability categories, and
multiplying these weights to calculate the exposure amount for each risk identified, as
shown in the following table:

                                                 Probability
                                                 Low       Medium       High
                                                 (2)       (3)          (4)
                                          Low    Low       Medium       Medium
                                          (2)    (4)       (6)          (8)
                                          Medium Medium High            High
                                          (3)    (6)       (9)          (12)
                                 Impact




                                          High   Medium High            High
                                          (4)    (8)       (12)         (16)


The team ranked these risks according to their exposures and timeframe and distributed
Carnegie Mellon University                                     CMU-MSE-Mission Possible
School of Computer Science                                                    Fall 2003
Master of Software Engineering



each of the top-10 risks among the team members. Each member prepared mitigation
strategies and contingency plans for his/her assigned risks and submitted a report to the
rest of the team for revision and filing. Each plan was required to answer the questions
of “why, what, when, who, where, how and how much”, fit on one page, specify the
actions, be clear and be traceable [2].

2.3       Analyze Risks

Based on the ratings given       to each risk, they will be analyzed to determine what action
the project will take. That      action could include immediate programmatic changes to
ensure that the risk does        not occur, development of mitigation plans that could be
implemented in the event          of the occurrence of the risk, or some other action as
appropriate.

2.4       Monitor Risks

The team will review and update the top-10 risk list monthly. In the case of high
exposure risks that have near period, this review will happen once every two weeks.
During each revision, the team shall focus in amending the three dimensions (time, cost
and probability), as appropriate. After each revision, the team will re-rank the risks and
will update the mitigation strategies and contingency plans, following the guidelines
under “Risk Resolution and Monitoring” presented in [2].

The risk list will be kept in a table available to all the members in the team’s website.
Every revision will generate a new table to allow tracking the history of every risk item.
This table will be implemented as a spreadsheet workbook. The table will be distributed
regularly by mail and remotely accessible.

2.5       Mitigate Risks

In the event that a risk does occur, the issue will be analyzed in light of the mitigation
plans and action will be taken as appropriate.

2.6       Resources Devoted to Risk Management

Assuming the following resources and constraints:

1.        Personnel resources available for schedule concerns:
           Four developers working 12 hrs per week each, until May 30, 2004.
           Four developers working 48 hrs per week each, between June 1, 2004 and
             August 6, 2004.
Carnegie Mellon University                                                     CMU-MSE-Mission Possible
School of Computer Science                                                                    Fall 2003
Master of Software Engineering



2.        The project must be completed by August 6, 2004.

          The total amount of hours available is:
                                 hours
           (a) 39 weeks 12                 4 persons  1872
                             person  week
                                  hours
           (b) 10 weeks 48                 4 persons  1920
                             person  week
           (a)  (b)  3792 hours



          As specified before, the team will revise the top-10 risk list once a month and, in
          the case of high exposure risks that have near time frame, once every two
          weeks. Assuming the worst case –that we have meet every two weeks to revise
          the risks throughout the whole project– and estimating each meeting to be one
          hour long, the amount of hours devoted to risk management will be:

                                   1 meeting    persons     hour
          (a) (26  13  10 ) weeks         4         1         98 hours
                                   2 weeks      meeting    person
          98 hours is 2.6% of 3792 hours


2.7       References

[1] J.C. Marvin, S.L. Konda, I. Monarch, F.C. Ulrich, and C.F. Walker, Taxonomy-Based
Risk Identification, Software Engineering Institute, 1993.

[2] B.W. Bohem, Software Risk Management: Principles and Practices, IEEE Software,
January 1991.

[3] A.J. Dorofee, J.A. Walker, C.J. Alberts, R.P. Higuera, R.L Murphy, and R.C.
Williams, Continuous Risk Management Guidebook, Software Engineering Institute,
1996.
Carnegie Mellon University                                    CMU-MSE-Mission Possible
School of Computer Science                                                   Fall 2003
Master of Software Engineering



3         Risks
3.1       List of Top-10 Risks

          The risks ranked as top-10 are:

               1.    Requirements unstable
               2.    Development tools too complex
               3.    Development based on incorrect requirements
               4.    Incomplete requirements
               5.    Legacy code documentation lacking
               6.    Poor development process
               7.    Developing the wrong UI
               8.    Requirements unfeasible
               9.    Inexperienced development team
               10.   Lack of team commitment/effort
Carnegie Mellon University                                             CMU-MSE-Mission Possible
School of Computer Science                                                            Fall 2003
Master of Software Engineering




Risk list details.

          ID                     R1      Risk Information Sheet               Identified    10/18/20
                                                                                            03
          Priority               1       Statement
          Probability            High    The client changes the requirements constantly and
          Impact                 High    that can cause delays.
          Timeframe              Near    Origin
                                         Requirements meeting
          Context

          This project is unique in that it is a continuation of a previous project. Because of the
          fact that the client is still evaluating the results of the previous project, their goals for
          this project have not been completely determined. As a result, a defined set of
          requirements is yet to be established.


          Mitigation Strategies.

               1. The team will set a deadline for changes to the requirements. The client will
                  be notified that changes in the requirements beyond this date will not be
                  feasible. The client will be notified of this date in advance.
               2. A requirements document will be generated and members from both the
                  team and the client will be required to sign-off on the document.
               3. Requests for changes to the requirements beyond the deadline will be
                  analyzed to determine the effects they will have on the project. Results of
                  this analysis will be communicated back to the client to determine if they still
                  want the change to be made. The client must agree that changes can and
                  will alter the deliverables of the project.

          Contingency Plan                                   Trigger

          The requirements are going to be If by the end of the semester, we still
          negotiated with the client to reduce the do not have requirements document
          scope of the development to those approved by the client.
          requirements that are clearly understood.
Carnegie Mellon University                                            CMU-MSE-Mission Possible
School of Computer Science                                                           Fall 2003
Master of Software Engineering




          ID                     R2     Risk Information Sheet           Identified 10/18/2003
          Priority               2      Statement
          Probability            High   The learning curve for the required tools is too steep and
          Impact                 High   may incorporate huge delays in the development.
          Timeframe                     Origin
                                        Requirements meeting
          Context
          There are several tools required in the project: Sychromod, Eclipse, AMC, ACMe
          Studio, Java, TSP. These tools are highly technical and each of them imposes a
          challenge to learn.
          If the team members do not have the necessary skill in each of them, they will not be
          able to work effectively and will not be able to move forward.



          Mitigation Strategies.

               1. Prepare a learning strategy, which includes tool-learning prioritizing.
               2. Contact Synergy team members and ask them to mentor us.
               3. Ask the former team which part the most useful is before learn it. We can skip
                  those things that we will not use at all.
               4. Follow a development process that supports and guides tool-learning
                  activities.


          Contingency Plan                               Trigger
            1. Seek help from the technical staff
                of the department.                       If by the end of the semester, we still feel
            2. Take courses in the mentioned             that we have not enough knowledge in
                tools.                                   the mentioned tools.
Carnegie Mellon University                                          CMU-MSE-Mission Possible
School of Computer Science                                                         Fall 2003
Master of Software Engineering




          ID                     R3       Risk Information Sheet         Identified   10/18/20
                                                                                      03
          Priority               3        Statement
          Probability            Medium   The current communication problems between the
          Impact                 High     team and the client may introduce errors in the
                                          understanding of the requirements that could lead to a
                                          defective product, time waste and a low client
                                          satisfaction.
          Timeframe              Near     Origin
                                          Requirements meeting
          Context

           The client is located in Detroit, and the only communication tools that are currently
          in use are the email and the telephone. So far, these tools have failed to help in the
          comprehension of the finer details in the requirements.
          The client does not have access to teleconference equipment and has very limited
          time for meetings.



          Mitigation Strategies.

          1. Review alternatives for desktop sharing software like Web Arrow or Timbuktu,
             and will acquire one of them to expand the set of communication tools.
          2. Recorded and analyze phone conversations.


          Contingency Plan                                Trigger

          The requirements are going to be If by the end of the semester, we still
          negotiated with the client to reduce the do not have requirements document
          scope of the development to those approved by the client.
          requirements that are clearly understood.
Carnegie Mellon University                                          CMU-MSE-Mission Possible
School of Computer Science                                                         Fall 2003
Master of Software Engineering




          ID                     R4       Risk Information Sheet         Identified   10/18/20
                                                                                      03
          Priority               4        Statement
          Probability            Medium   The requirements are too vague or incomplete
          Impact                 High
          Timeframe              Near     Origin
                                          Requirements meeting
          Context

          The requirements are too vague or incomplete. For example improving the
          performance, the client doesn’t any specific and the reason of the requirement.

          Mitigation Strategies.

               Since we already have a previous deliverable, we can use it as a prototype for
               us and ask the client for more specific requirement based on it. If possible we
               can ask the clients to show us the problems they encountered with the previous
               version and tell us the performances of which operations they don’t satisfy with,
               why and what is the number they expected.

          Contingency Plan                                Trigger

          Schedule a face-to-face meeting with the If by the end of the semester, the
          client.                                  team members still do not know the
                                                   requirements of the client.
Carnegie Mellon University                                           CMU-MSE-Mission Possible
School of Computer Science                                                          Fall 2003
Master of Software Engineering




          ID                     R5       Risk Information Sheet          Identified   10/18/20
                                                                                       03
          Priority               5        Statement
          Probability            High     There is not enough documentation from the Synergy
          Impact                 Medium   team (Author of AMC) to fix the problem of AMC.
          Timeframe              Near     Origin
                                          Requirements meeting
          Context
          This project is to extend the capability of AMC tool. According to the client’s request,
          we should fix some serious problems of the AMC at the same time with the
          designing of new system. Unfortunately, we may not have enough documentation of
          the AMC tool especially those detail designs and comments in source code. This
          makes it more difficult to fix the problem of the tool.


          Mitigation Strategies.
              1. Collect those documents from all the sources that possibly own the
                 documents of AMC tool, e.g. Ford client, mentors, tech advisors and the ex-
                 member of the synergy team.
              2. Get related document online or from Ford client.


          Contingency Plan                                 Trigger

               1. We are going to study thoroughly all     If by the end of the semester, we still
                  the documents we have. We will           cannot      fully   understand    the
                  focus on the design document and         architecture of the AMC tool because
                  source code to break through. On         of the lack of documentation.
                  the other hand, it is a good chance
                  for our team to be familiar with the
                  AMC tool quickly.
               2. Since we have an ex-member of
                  Synergy team in the studio (Not on
                  the same project), we can get help
                  from him. In fact, he has already
                  been proved to be very helpful in our
                  understanding of the AMC tool and
                  the requirements of our clients.
               3. The client will be a good consultant
                  for us in the procedure of bug fixing.
Carnegie Mellon University                                          CMU-MSE-Mission Possible
School of Computer Science                                                         Fall 2003
Master of Software Engineering




          ID                     R6       Risk Information Sheet          Identified   10/18/20
                                                                                       03
          Priority               6        Statement
          Probability            High     The development process chosen by the team may be
          Impact                 Medium   ill suited to the project and hinder progress.
          Timeframe              Near     Origin
                                          Requirements meeting
          Context
          The development process chosen by a project group may impact that project’s
          success.

           The project group consists of inexperienced personnel, so there is a high probability
          that the elicitation and understanding of the requirements is imperfect, as is the
          understanding of the advantages and disadvantages of different processes. Thus,
          the probability that the group will choose a non-optimal development process for this
          project is high.

          If the process is poorly chosen, (i.e. the waterfall model for a fast-changing e-
          commerce website) then the quality of the software, and more importantly, the users’
          satisfaction with it, will be adversely affected, so the cost to the project is high. On
          the other hand, the development team is inexperienced. Thus, the group is unlikely
          to appreciate the benefits or the liabilities of a particular process due to the limited
          exposure to process driven development in general, so the final impact on the
          project is medium.
          Mitigation Strategies.
              1. Convene monthly team meetings to assess the effectiveness (or
                  ineffectiveness) of the team’s development process.
              2. Assign a team member to become “expert” in the pros and cons of different
                  development processes. This team member will moderate the monthly
                  meetings (see mitigation strategy 1) and be trusted to determine when a
                  process deviation or change is required.

          Contingency Plan                                Trigger
          Two possibilities:
          1. A non-iterative process is chosen, but       Assigned team “expert” determines
             an iterative process is needed.              that the process needs to be
             Contingency: Assign two week’s slip          changed, based on monthly team
             time to redefine requirements for every      meetings.
             iteration and split the project team to
             parallelize the iterations.
          2. An iterative process is chosen, but a
             non-iterative     process    is   needed.
             Contingency: This case will only result
             in general inefficiency by traversing
             each phase of the process multiple
             times, but it will not result in schedule
             slip.
Carnegie Mellon University                                             CMU-MSE-Mission Possible
School of Computer Science                                                            Fall 2003
Master of Software Engineering




          ID                     R7       Risk Information Sheet              Identified    10/18/20
                                                                                            03
          Priority               7        Statement
          Probability            Medium   The client rejects the product during the tests because
          Impact                 High     the lack of usability (the user interface is difficult to use
                                          or to understand)
          Timeframe              Medium   Origin
                                          Requirements meeting
          Context

          The ACM system is part of Ford’s engineering modeling environment and its inputs
          and outputs are several complex artifacts that must be exchanged through a
          graphical user interface. The system must support large-scale models too. Although
          the engineers at Ford are used to coping with such complexity, the system’s
          interface must provide useful tools and mnemonic procedures that do not complicate
          the tasks. To achieve this, the Studio team must understand the users’ processes at
          the same level of complexity that the users do and acquire expertise in the
          development domain. Both goals are uncertain and difficult to achieve.

          Mitigation Strategies.

               1. Follow mitigation strategies for team experience and learning curve to
                  improve the team’s understanding of the development domain.
               2. Use the current version of the system as a prototype and encourage user
                  participation to gather usability data. This might not be easy or even possible,
                  due to the communication difficulties encountered so far.

          Contingency Plan                                   Trigger

          Negotiate the requirements with the client to      If, after having gathered all the
          postpone the development of those                  requirements, we don’t have usability
          requirements that demand intense and               data or a clear specification of the
          complex user interaction.                          interface, yet.
Carnegie Mellon University                                          CMU-MSE-Mission Possible
School of Computer Science                                                         Fall 2003
Master of Software Engineering




          ID                     R8       Risk Information Sheet         Identified   10/18/20
                                                                                      03
          Priority               8        Statement
          Probability            Medium   We find out that the requirements are too complex and
          Impact                 Medium   we cannot achieve the required results.
          Timeframe              Near     Origin
                                          Requirements meeting
          Context

          Because the requirements have not been detailed for this project yet, the team has
          not had a chance to analyze and estimate the costs of completing the requirements.
          Delivery of the requirements will depend on their complexity.


          Mitigation Strategies.

               Once the requirements have been collected, the team will analyze each and
               estimate the amount of work that will be needed. If the requirements are beyond
               the scope of what the team feels is feasible, this will be communicated to the
               client before sign-off of the requirements document.


          Contingency Plan                                Trigger

          The requirements are going to be                Estimation and analysis of the
          negotiated with the client to reduce the        requirements       document should
          scope of the development to those               provide a good idea of what is
          requirements that are clearly understood.       feasible for this project.
Carnegie Mellon University                                         CMU-MSE-Mission Possible
School of Computer Science                                                        Fall 2003
Master of Software Engineering




          ID                     R9       Risk Information Sheet        Identified   10/18/20
                                                                                     03
          Priority               9        Statement
          Probability            Medium   Because team members lack of experience in the
          Impact                 Medium   development domain, that could delay delivery date
          Timeframe              Near     Origin
                                          Requirements meeting
          Context

           The team members are not participated in any project similar to the actual
          development, which may bring some delays during the study of architectural
          concerns and in the coding stages.

          Mitigation Strategies.

            1. Find more documentation about the nature of the project from the client.
            2. Seek advice from Synergy team members.
            3. Search for related project information over the internet.
          Contingency Plan                             Trigger

          Try to hire MSIT students to help in the final If by the end of the semester, the
          coding phases, to recover the time lost due team member still could not grasp
          the lack of experience.                        AMC development domain.
Carnegie Mellon University                                          CMU-MSE-Mission Possible
School of Computer Science                                                         Fall 2003
Master of Software Engineering




          ID                     R9       Risk Information Sheet         Identified   10/18/20
                                                                                      03
          Priority               9        Statement
          Probability            Medium   We find out that the requirements are too complex and
          Impact                 Medium   we cannot achieve the required results.
          Timeframe              Near     Origin
                                          Requirements meeting
          Context

          Because the requirements have not been detailed for this project yet, the team has
          not had a chance to analyze and estimate the costs of completing the requirements.
          Delivery of the requirements will depend on their complexity.


          Mitigation Strategies.

               Once the requirements have been collected, the team will analyze each and
               estimate the amount of work that will be needed. If the requirements are beyond
               the scope of what the team feels is feasible, this will be communicated to the
               client before sign-off of the requirements document.


          Contingency Plan                                Trigger

          The requirements are going to be                Estimation and analysis of the
          negotiated with the client to reduce the        requirements       document should
          scope of the development to those               provide a good idea of what is
          requirements that are clearly understood.       feasible for this project.
Carnegie Mellon University                                        CMU-MSE-Mission Possible
School of Computer Science                                                       Fall 2003
Master of Software Engineering




          ID                     R10    Risk Information Sheet          Identified   10/18/20
                                                                                     03
          Priority               10     Statement
          Probability            Low    The project might suffer delays or other problems
          Impact                 High   caused by the lack of commitment from team members.
          Timeframe              Near   Origin
                                        Requirements meeting
          Context

          The Studio team is composed of members from different courses. Some of those
          members participate in the project only for one semester. Hence, not all the
          members have the same long-term responsibility with the project and not everybody
          has the opportunity of interacting as much as the core team members do. The core
          team members are not [yet] experts in the project field as to be able to lead the way
          for the rest of the members. Up to now, the team dynamics have not been the most
          effective ones. All this might end up deterring some members’ motivation and
          commitment to the project.

          Mitigation Strategies.

               1. Encourage (not enforce) the participation of every member in every
                  homework.
               2. Establish a single, formal communication channel and ensure that all
                  members recognize and use it.
               3. Keep all the team members up to date with the team’s progress by, for
                  instance, setting agendas for every meeting and distributing the minutes
                  afterwards.
               4. Realize a process to direct the team’s work. For example: for each
                  assignment and with enough anticipation, the team lead invests some effort
                  in understanding the assignment thoroughly and ensures that every team
                  member clearly comprehends the assignment. Then, the team lead proposes
                  a concrete plan to do the assignment and discusses it the whole team.
                  Finally, the team implements the plan and makes necessary adjustments on
                  the way.
               5. Discuss this process and the team dynamics openly with all the team
                  members and survey their opinions frequently.

          Contingency Plan                              Trigger

          Seek assistance from professors from the If, during the second homework, any
          Heinz School, the GSIA or the MSD course. team member still feels that other
                                                    members lack commitment or that the
                                                    team dynamics are not working for
                                                    the team.

				
DOCUMENT INFO
Description: Risk Management Ford document sample