Project Manual.doc
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Project Manual.doc

on

  • 4,824 views

 

Statistics

Views

Total Views
4,824
Views on SlideShare
4,824
Embed Views
0

Actions

Likes
1
Downloads
313
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Project Manual.doc Document Transcript

  • 1. I NFORMATION R ESOURCES & T ECHNOLOGIES Project Planning Manual Last revision: July 2006 by Marie Morzenti
  • 2. IRT PROJECT PLANNING MANUAL Table of Contents I...................................................................................................................................................................1 IRT Project Management Methodology..................................................................................................4 Project Life Cycle......................................................................................................................................6 Writing a Project Proposal.....................................................................................................................10 Creating the Statement of Work............................................................................................................14 Generating a Task List............................................................................................................................21 Project Change Management.................................................................................................................23 Appendix A: IRT Project Proposal .......................................................................................................24 IRT Project Proposal ..............................................................................................................................24 Appendix B: IRT Project Statement of Work— Long Form...............................................................................................................................................26 Description and Scope.............................................................................................................................26 Approach..................................................................................................................................................27 Resource Requirements..........................................................................................................................27 Risks and Concerns.................................................................................................................................29 Acceptance Criteria.................................................................................................................................30 Estimated Time and Costs......................................................................................................................30 Outstanding Issues...................................................................................................................................31 Glossary....................................................................................................................................................31 Appendix C: IRT Project Statement of Work— Short Form...............................................................................................................................................32 Description and Scope.............................................................................................................................32 Major Deliverables/Key Events Anticipated.........................................................................................32 Resource Requirements..........................................................................................................................32 Risks and Concerns.................................................................................................................................33 Project Completion Criteria...................................................................................................................33 Outstanding Issues...................................................................................................................................33 Appendix D: IRT Project Status Report................................................................................................34 Appendix E: IRT Project Change Request Form.................................................................................36 1. Description of Change Requested and Benefits.................................................................................36 2. Changes to Major Deliverables/Key Events Anticipated..................................................................36 3. Changes to Resource Requirements...................................................................................................36 IRT Project Planning Manual Summer 2006
  • 3. 4. Changes to Risks and Concerns..........................................................................................................36 5. Changes to Project Completion Criteria............................................................................................36 6. Outstanding Issues Regarding the Change Request.........................................................................36 IRT Project Planning Manual Summer 2006
  • 4. IRT Project Management Methodology While there are many project management models available, we have not found one that fully suits the unique needs of Information Resources & Technologies and the University of St. Thomas. Because our projects vary in type – from computer installations to programming to adopting new services – as well as in size, priority, leadership style, and scope, we have identified the common elements that should be completed when managing any new project in IRT. The tools that you use, the development methodology, and the team process will vary from project to project. However, every project initiated in IRT after January 1, 2003, should include the following: 1) Project proposal Develop your project proposal using the on-line form or outline (available on the project web site and at ust-deptstore1DeptsF-KIRTProjects ), and submit it through your project sponsor to the IRT Cabinet. The IRT Cabinet will review all project requests bi-weekly, and respond with approval, questions, or rejection of the proposal. 2) Project folder in IRT/Projects A folder in the UST-DeptStore1DeptsF-KIRTProjects directory, named for your project will be created upon approval of the project. Storing all of your documents related to the project in that folder ensures easy access for your teammates, and will allow documents to be accessed using a web crawler from the project web site. 3) Statement of Work Create a Statement of Work (long form for large projects, short form for medium and small projects), and review it in a “walkthrough” meeting with members of the proposed project team, as well as any other individuals inside of or outside of IRT who might be interested in learning about the project. 4) Task list Identify all project tasks and create a task list as a “roadmap” for your project team. MS Project is the preferred tool for IRT project managers. 5) Status reports Status reports should be completed, stored in your project folder and an e-mail alert of its availability sent to your project sponsor and IRTProjects@stthomas.edu by the 15th of each month as long as the project is active. Periodically, you and your project team may be called upon to deliver a report in person. The forms described above are available on the IRT projects web site (http://www.stthomas.edu/irt/projects/management and at ust-deptstore1DeptsF-KIRTProjects . IRT Project Planning Manual Summer 2006
  • 5. What is a project? A project is a work effort that is separate from your day-to-day duties; it wouldn’t appear in your IODP or Job Profile as a routine job function. A project involves more than one person and 40+ hours of work, with a definite end deliverable and a scheduled end date. Why all the fuss about project management? Having a standard project management methodology is an attempt to ensure that projects in IRT are successful. A successful project is defined as being on time, on budget, and results in meeting user expectations. Recent surveys report that 28% of IT projects fail and 46% finish later than scheduled. We strive to not be included in those statistics. Who can help me get started with a project? Dave Naugle, Randy Sauter or Ann Burke can serve as mentor to anyone who would like help getting started. Dave Naugle also has a number of excellent books and other resources to recommend. IRT Project Planning Manual Summer 2006
  • 6. Project Life Cycle Information Resources & Technologies Project Life-Cycle Requirements Design Development Requirements Design Document Coding Document Concept Proposal Planning Implementation Completed Documentation, Statement of Work Project Review Beginning of Project Form Train Users, and Walkthru with Report Proposal TechDesk & IRT & Project Technicians, and Team, Project Installation of Task List, Status Project Reports begin Cancelled NA Testing On Hold Completion of Test NA Cases The phases described below are immediately applicable to software and systems type projects; not so easily applied to other types of projects. Please use your best judgment as to how these phases might or might be adopted and applied to your project. Concept The concept phase is by nature informal. It begins when someone comes up with the idea, and ends when a formal project proposal is made. Typically, during the concept phase, there would be hallway conversations and e-mails about the idea, and possibly a few meetings. Proposal In the proposal phase, a project proposal is submitted to the IRT Project Review Group and reviewed. Planning In the planning phase, you would  Prepare a Statement of Work (SOW) document.  Put together the task list. IRT Project Planning Manual Summer 2006
  • 7.  Identify milestones and delivery dates.  Conduct cost estimation.  Conduct risk assessment.  Put together a risk mitigation plan, if necessary.  Identify roles and responsibilities. The end deliverables of this phase are:  Statement of Work (SOW)  Task list (sometimes can be included in SOW)  Statement of Work and Task List Walkthrough. Requirements In the requirements phase, you would determine what (exactly) the end product will do. In the case of an application development project, you would detail the functions, interfaces, reports, and screens that the end user needs, and you would specify the business rules that the system must adhere to. You should write the requirements document with enough detail to allow you to test it. During this phase, you might:  Conduct interviews with customers.  Hold brainstorming sessions with customers.  Hold Joint Application Development (JAD) meetings.  Define process flow.  Submit Monthly Status Reports to your project sponsor and Ann Burke by the 15th of each month. The end deliverable of this phase is the requirements document. Design In the design phase, you would explain how the end product will function. In the case of an application development project, you would design the database, develop modules, and identify classes and objects. You would design interfaces, reports, and screen layouts. The design documents should be written with enough detail to be traceable back to the requirements document. During this phase, you might:  Determine database structure.  Create Data Flow Diagrams (DFD).  Create Entity Relationship Diagrams (ERD).  Determine file layouts.  Identify object classes.  Define objects.  Submit Monthly Status Reports to project sponsor and IRTProjects@stthomas.edu by the 15th of each month. IRT Project Planning Manual Summer 2006
  • 8. The end deliverable of this phase is the design document. Development In the development phase, you would develop the end product. During this phase, you might:  Write the code for the application.  Make necessary modifications to support vendor modules.  Submit Monthly Status Reports to your project sponsor and IRTProjects@stthomas.edu by the 15th of each month. The end deliverable of this phase is functioning code (in the case of application development). Testing In the testing phase, you would engage in testing. During this phase, you might:  Write a test plan: who will test, what will be tested, when and how the testing will be conducted.  Write test cases.  Create a test case matrix.  Execute the test cases.  Track problems.  Submit Monthly Status Reports to your project sponsor and IRTProjects@stthomas.edu by the 15th of each month. The end deliverables of this phase are executed test cases and user sign-off. Implementation In the implementation phase, you implement the project. During this phase, you might:  Write user documentation.  Write Tech Desk documentation.  Train the users.  Train the Tech Desk.  Conduct “Train the Trainer” sessions.  Write Policies & Procedures documentation for the users.  Write Policies & Procedures documentation for the administrators.  Install the project in the production environment.  Submit Monthly Status Reports to project sponsor and IRTProjects@stthomas.edu by the 15th of each month. The end deliverables of this phase are user documentation and training, and the migration of the project into the production environment. IRT Project Planning Manual Summer 2006
  • 9. Completion In the completion phase, you review how the project went. The end deliverable of this phase is the post- implementation review report. On Hold If a project is on hold, it is temporarily stopped. The plan is still to complete the project at some later date. If a project is placed on hold, notify the customers that the project is on hold, and notify your project sponsor. (While a project is on hold, you don’t have to submit Monthly Project Status Reports.) Canceled If a project has been canceled, it has been stopped with no plans to restart it. If a project is canceled, notify the customers and your project sponsor. IRT Project Planning Manual Summer 2006
  • 10. Writing a Project Proposal Purpose of a project proposal, and how it fits into the IRT project management process A project proposal is the first formal notification that a project is under consideration by an individual or group. Moving from concept to proposal means that the “good idea” someone had is ready to start the journey toward fulfillment. Concept Proposal Planning Implementation Completed Documentation, Statement of Work Project Beginning of Project Form Train Users, and Walkthru with Review Report Proposal HelpDesk & CCS Mgmt Team, Technicians, and Project Task List, Installation of Status Reports Project begin Remember, a project is defined as a work effort involving more than one person and/or more than forty hours of work, with a definite deliverable and a definite end date. Once you’ve identified a project, and want to start the project process, you’ll need to complete a project proposal form. Completed forms will be reviewed by the IRT Cabinet, assigned a priority within the scope of other IRT projects and work, and assigned preliminary resources to do the initial project work. This sounds very formal, but given the number of wonderful ideas people have for using technology at the university and the limited human and financial resources available, this helps us to better manage the work we take in departmentally so that we can deliver quality results. The project proposal form and tips for completing it There are two version of the form available to individuals or groups who want to propose a project; one is a web-based form, with fill-in fields, and the other is a Microsoft Word document. Both are accessible from the IRT projects web site, and contain the same information fields. (You can see a sample project proposal form in Appendix A, below.) The project proposal includes the following information:  Introduction (a non-technical description of what you plan to do and the expected results—in other words, the purpose of the proposal, or the problem)  Benefits (statement of why this problem needs to be solved now; payoff in solving the problem and possible consequences of inaction)  Proposed Solution to Problem (brief statement of how you propose to solve the problem, including description of pros and cons of all alternative solutions)  Program Details (including estimated costs, key stakeholders, suggested members of the project team, communication plans, and evaluation plans)  Implementation Schedule IRT Project Planning Manual Summer 2006
  • 11. Completing a form is one thing; developing a persuasive proposal is quite another. What follows are some tips for developing good project proposals, excerpted from Proposal Planning and Writing by Lynn Miner, Jeremy Miner, and Jerry Griffith. Introduction The introduction is a credibility statement that establishes the significance of your idea. It establishes the tone of the whole proposal. There are four general types of introductions: • Summary statement Tells who, what, where, and why. Presents the basic facts of the proposal in a succinct manner. This is perhaps the most common approach to proposal writing. A lead paragraph typically outlines the high points of the proposal and is followed by one or two “so what?” paragraphs explaining the proposal background and significance. • Philosophy statement Used to convince sponsors that you and they think alike, a useful approach with innovative projects. • Historical statement Used to indicate that you are uniquely able to carry out a proposed project because you have special ability or experience to solve a problem. Also useful approach if making a “comeback” from a “rocky road.” • Crisis statement Intended to immediately gain sponsorship for a project. Must communicate a sense of urgency without overkill. The introduction should clearly state the problem you are trying to solve through this project; it should identify a gap between what exists today and what could exist tomorrow. Benefits In the benefits section, describe what benefit this project would bring to the university community. Specify who will benefit, and how, if the problem identified above is resolved. Proposed solution The next step is to identify how you intend to solve the problem you’ve described. In this section specify the outcomes of your project. To create a persuasive proposal, try to ensure that your solution is:  Specific. Indicate precisely what you intend to change through your project. What will be different when your project is finished? What will people be able to do once the project is completed that they couldn’t do before?  Measurable. Indicate what you would accept as proof of project success. What qualitative and quantitative data will you gather? What standard of comparison will you use to measure project success?  Practical. Demonstrate that each objective is a real solution to a real problem. Are your objectives realistic and feasible? Do you and your project team have the skill, experience, qualifications, resources, and personnel to carry out each objective? IRT Project Planning Manual Summer 2006
  • 12.  Logical. Show how each objective systematically contributes to achieving your overall goal or goals.  Valuable. What impact will your project make? Program Details This section describes some of the brass tacks of the project – how much it’s going to cost, who should be part of the project, how information will be communicated, and how the project’s success will be evaluated.  Estimated costs Consider both direct costs and indirect costs. Direct costs include personnel (salaries, consultant fees, etc.) and non-personnel costs (equipment, supplies, travel, publication charges). Indirect costs include operating expenses, and can be difficult to pin down.  Key stakeholders These are individuals who have an investment in the success or failure of the project. Typical stakeholders in IRT projects include students, faculty, staff, administrators, alumni, neighbors, parents of students, prospective students, prospective employers, etc.  Project team suggestions List the individuals who should be part of the project team, as well as the role they will play in project development.  Communication plans (dissemination) Indicate the means by which you will let stakeholders know about the project’s progress. Reports, presentations, articles in the Bulletin, meetings, direct mailings, and posting information on the IRT web site are some of the ways project information is communicated to stakeholders.  Evaluation plans Evaluation is important to determining your project’s success. There are different types of evaluation. Formative evaluations generate information that will improve the effectiveness of the project during the development period; they help determine whether processes and procedures are working, and whether participants are satisfied with their experiences. Summative evaluations involve collecting data to judge the ultimate success of the completed project; the goal here is to document to which the project objectives are achieved. Impact evaluations generate information to measure the overall worth and utility of the project, focusing on the project’s larger value; this assessment provides essential information about the direction that the project should take in the future. Implementation Schedule A brief timeline is required here. Submission and review process Once your proposal is complete, submit it through your department head to the IRT Project Review Group. Project proposals are reviewed in the IRT Project Review Group meetings on Mondays of every week. The proposals are reviewed and assigned a high, medium, or low priority, according to these criteria: IRT Project Planning Manual Summer 2006
  • 13. Priority Initiation/Purpose/Benefit Example High External Mandate State or Federal regulation; financial institution requirement UST Mandate Address verification bolt-on to Banner Addresses University strategic direction Capital campaign web site; or IRT goal recruitment applications High benefit/low cost or risk Medium New product or service Enhances existing product or service Initiated by another UST department High benefit/high cost or risk Low Nice to have but not essential Immunization web form Low benefit/high cost or risk Projects assigned medium or low project status may not be pursued immediately. Projects that are not accepted are typically deferred until refinements are made to the proposal, or may be denied because of a lack of resources or a conflict with another project. Once a project proposal has been accepted, a project manager will be assigned. The project manager is expected to move forward with developing the project according to the IRT project management process, taking the project proposal forward into the planning process. IRT Project Planning Manual Summer 2006
  • 14. Creating the Statement of Work Purpose of the SOW, and how it fits into the IRT project management process The Statement of Work (SOW) is a complete description of the project including descriptions of major product deliverables. The SOW is the principle deliverable of the Planning Phase. It may be updated throughout the project as the understanding of the project changes. Project Sizing Guide A SOW is required for all projects in IRT. It is expected that the SOW will take some time to complete. The SOW should be developed collaboratively and could include the project manager and sponsor, one or more end users, and the members of the proposed project team. The long version of the SOW must be used for large projects. The SOW Short Form may be used for small and medium projects. See the table below to determine project size. Size Description Large Over 1000 estimated hours of work by IRT staff members. Medium 100 to 1000 estimated hours of work by IRT staff members. Small Under 100 estimated hours of work by IRT staff members. The SOW form and tips for completing it You can find a copy of the SOW long form in Appendix B and the SOW short form in Appendix C. The short form is largely self-explanatory; it may be used on small and medium projects at the discretion of the project leader. The SOW long form will be used for large projects. Each section of the long form is explained below. 1. Description and Scope 1.1 Summary of Work Requested This is a general description of the purpose of the project. Explain in broad terms what the project is expected to accomplish. 1.2 Background Provide historical and other background information on what led to the creation of this project. Include information on any studies, research, or surveys that contributed to the decision to proceed with the project. 1.3 Description of Major Elements (Deliverables) of the Completed Work List all the major identifiable results or outputs of the proposed work. For example: the SOW document, a procedures manual, installation of a particular hardware or software component, or completion of a testing phase. 1.4 Expected Benefits List the major benefits that will result from this project. (In other words, the answer to the question, “why are we doing this?”) IRT Project Planning Manual Summer 2006
  • 15. 1.5 Items not in Scope In many cases, over the course of the project, issues will come up that are not essential to the project and that would delay the project if they were included in the work. These issues should be declared out of scope and set aside to deal with later. List such items in this section. 1.6 Business and/or Educational Objectives List any identifiable objectives for the project. This section may include some of the items listed under Expected Benefits, as well as items that fit with the mission or goals of the university or department. 1.7 Priority The priority of the project will be determined in the Project Proposal Phase. 2. Approach 2.1 Major Milestones/Key Events Anticipated List all events that are crucial to the successful completion of the project, along with the target completion date for each. 2.2 Methodologies or Special Standards to be Observed List any special techniques or tools that will be used during the course of the project. This could include a development model, or specific testing methods. Any special standards that will be followed should be listed here also. 2.3 Impact on Existing Projects or Systems This could include contention for financial or human resources as well as impact on physical resources. Note where existing systems will require changes. 2.4 Rationale for Build/Buy Decision Describe the decision-making process that led to the conclusion that this project needed to be done in- house, rather than bought as an off-the-shelf product. 2.5 Assumptions Critical to the Project These are resources that must be available to complete the project, but which may be out of your control. For example, one assumption might be that a previous upgrade will have been completed on schedule before the project starts. 2.6 Plans for Periodic Status Reporting The present IRT policy calls for a status report to be submitted by the tenth of each month. Any additional methods that will be used to report progress should be listed here as well. 2.7 Procedures for Change of Scope and/or Work Effort (PCR's) The IRT Project Change Request form is to be used for any changes in scope, work, or timeline. The PCR is then submitted to the Project Sponsor and the IRT Cabinet for approval. 3. Resource Requirements 3.1 Detailed Plan for Human Resource Assignments List every person or work group that will perform actual work on the project. Provide a brief description of what they will be doing along with an estimate of actual hours that they will devote to the project. 3.2 Other Resources (Hardware, Software, Money, etc.) List all additional resources that will be needed to successfully complete the project. 3.3 Expected Commitments from Other Departments or People List work commitments from staff outside of IRT including other UST departments and vendors/consultants. IRT Project Planning Manual Summer 2006
  • 16. 3.4 Concerns or Alternatives Related to Staffing List any concerns relating to staffing issues and possible alternative solutions. 3.5 Any other Resources Required List anything not noted above. 3.6 Sizing Any project using this form is a large project 3.7 Ownership Indicate the project sponsor, project manager, and who will own the project when completed. 3.8 Stakeholders List all individuals or groups that will be affected by the project. 4. Risks and Concerns 4.1 With Respect to the Environment This would include issues such as adequate physical space, rapidly advancing technology, and sufficient technological infrastructure. 4.2 With Respect to User Expectations What happens if user expectations are not clearly identified or properly managed? 4.3 With Respect to Competing Projects Identify the projects that may compete for the resources needed to complete this project. 4.4 With Respect to Project Assumptions Examine the Project Assumptions and list those that are the least likely to be true. 4.5 Constraints that are Significant to the Project This would include such things as the implementation date, funding, or related construction activities. 4.6 Current Related Projects List all related projects, the nature of the relationship, the status of the project, and possible workarounds to mitigate the risk. 4.7 Future Projects Building on this Effort List any proposed projects that are dependent on the successful completion of this project. 4.8 Risk Category (Probability X Impact) See Risk Assessment and Management, below. 4.9 Risk Mitigation Plan See Risk Assessment and Management, below. 5. Acceptance Criteria 5.1 Responsibility for Acceptance Process and Criteria Identify the person who will be responsible for the development of any acceptance process and criteria. 5.2 Identification of Test Data Identify the data that will be used in testing, and how it will be created. 5.3 Testing Approach Describe the general method that you will use to conduct the test. IRT Project Planning Manual Summer 2006
  • 17. 5.4 Termination of the Project Identify how it will be determined that the project is complete. (“What does ‘done’ look like?”) Describe what will happen if the project is not completed on time. 6. Estimated Time and Costs 6.1 Completion Estimate for the Proposed Work Provide an estimate in hours for all proposed work in the project, indicate the hourly rate for each, and the total cost. Include an estimate for all materials needed for the project. For example: Area Hours Rate per Person per Total Cost Hour Project Management 200 (1 person @ 2hrs a $60.00 $12,000.00 wk for 100 wks) Requirements 150 (10 people @ 1 hrs a $60.00 $9,000.00 wk for 12 wks + 1 person for 30 hrs) Design 320 (1 person @ 40 hrs a $60.00 $19,200.00* wk for 8 wks) Development 640 (2 people @ 40 hrs a $60.00 $38,400.00* wk for 8 wks) Testing 480 (3 people @ 40 hrs a $60.00 $28,800.00* wk for 4 wks) See Methods for Estimating Task Duration, below, for help in estimating time to perform work. 6.2 Requirements for Special Funding Describe any situations or incidents that would require funding from outside of the project budget. 6.3 Costs for Development and Ongoing List any additional costs for required development tools, along with an estimate of ongoing support costs after the project is completed. 6.4 Major Arguments or Basis for Time and Cost Describe the method used for estimating hours of work required and the related cost. 7. Outstanding Issues During the development of the SOW and the subsequent walk-through, additional issues may arise. These issues should be listed here. As the process moves forward, these issues may end up as tasks in the project, deemed to be out-of-scope and passed to another body, or determined to be unimportant. 8. Glossary Define any terms in the SOW that may not be known to an average reader. SOW Walk-through When the initial version of the SOW is complete, a walk-through meeting should be scheduled with the players and others interested. In this walk-through, the project leader will go through the SOW item by item, adding explanations or providing clarification as necessary. This process is valuable because scope IRT Project Planning Manual Summer 2006
  • 18. issues can often be resolved, funding issues can be discussed, and other outstanding issues can be resolved as well as identified. The walk-through meeting should include as many interested people as possible. Risk Assessment and Management There are four steps to assessing and managing risk. These are: Identifying the Risk Items This is generally done through brainstorming. The objective is to find as many things as possible that could cause problems on the project. These problems can occur both during the project itself (a technical challenge that may not be overcome, a lack of funding, etc.) and after implementation (the system doesn't work, people don't have access to the tools to use the system, etc.). Some ideas to get started when looking at risks are these frequent causes of project slippage:  Requirement changes  Design changes  Task omissions  Estimating and scheduling errors  Technical errors  Staff turnover, illness/death, unplanned vacation/leaves of absence  Late delivery of external deliverables  Priority changes that result in loss of resources  Late approvals and acceptances  Weather and other random events  Extended learning curves  Unavailable or unreliable tools and methods Quantifying the Impact There are several methods available to quantify the severity of a problem, ranging from a simple scale to precise dollar values. In IRT, we use a three value scale based on the dollar value of the impact or how many people would be impacted by the problem. High—The problem would involve more than $100,000 or impact the entire university or several departments/areas. It is likely that the President or Executive Vice-President would hear about this and contact IRT. Medium—The problem would involve more than $20,000 or impact several people in one or two departments. The managers of these departments would contact IRT. Low—The problem would involve less than $20,000 and impact three or fewer people in one department. These individuals would contact IRT. Determining the Likelihood Estimate the chance that this risk will occur. In IRT, we use a three value scale. High—Over a 50% chance. Medium—10% to 50% chance. IRT Project Planning Manual Summer 2006
  • 19. Low—Under a 10% chance. Developing a Risk Mitigation Plan The final step is to develop a plan to account for the important risk elements. The two variables identified above determine which risks require this step: If the impact would be high and the likelihood is either medium or high, a risk mitigation plan is needed. If the impact would be medium and the likelihood is high, a risk mitigation plan is needed. If the either the impact or the likelihood is low, no risk mitigation plan is needed. The risk mitigation plan states how the risks will be monitored and managed during the project. In some cases we may decide to accept the risk. In others, the plan may be nothing more than a monthly review. Conversely, controlling other risks may require development of secondary code that will be used if the preferred method turns out to be technically impossible. A risk mitigation plan typically includes key dates that certain items must be complete or alternative methods will have to be employed. Methods for Estimating Task Duration Estimating the time required to perform a specific task in a project can be a challenging process. In some cases, there will be historical data to draw from; others will be in completely uncharted territory. In any case, you’ll need to make your best effort in estimating the task duration if the project will have any chance of success. When estimating the duration for a specific task, you should focus on the actual time needed to complete the task, not just how long it would take a particular person or group to do the work. Resource allocation will determine the total time required to complete a task. The time estimation should be expressed in hours. Following are some generally accepted techniques for estimating task duration. Similarity to Other Tasks Some tasks may be similar to tasks performed in other projects. Your recollection (or someone else’s recollection) of how long those tasks took can be used to estimate duration for tasks in the new project. All projects are different, and are affected by different constraints and assumptions, but it many cases this is a fairly accurate way to estimate task duration. Expert Advice When a project involves new technology, there may not be anyone in IRT who has experience with it. In this case, you might talk with consultants, vendors, or other people who have used this technology for their expertise. Nominal Group Technique This is a group method that extracts and summarizes the knowledge of the group to arrive at an estimate. It assumes that each member of the group has a good understanding of the project and a general knowledge of the nature of the task. Each member of the group is asked to estimate the duration of the task. The results are then tabulated and presented to the group in graph form showing estimates from shortest to longest. The graph is then divided into quartiles. Those whose estimates fall in the outer two IRT Project Planning Manual Summer 2006
  • 20. quartiles are asked to share the reason for their guess. After discussing these rationales, each member of the group makes a new estimate as to the duration of the task. This second pass should result in a smaller range of durations. The group then repeats the process from the first pass. A third pass is then performed and the average of the estimates is used for the duration of that task. Three Point Technique This method utilizes a formula that comes from probability theory. Three estimates are made for the duration of a task: O = Optimistic. The shortest duration one might expect to experience if everything goes as planned. P = Pessimistic. The duration that would be experienced if everything that could go wrong did go wrong and yet the task was completed. M = Most Likely. The duration that would most likely occur if the task were to be repeated over and over again. The formula is then expressed: Estimate = O + 4M + P 6 An individual or a group may perform this method. When done by a group, the averages of the estimates are used for O, P, and M. IRT Project Planning Manual Summer 2006
  • 21. Generating a Task List Affinity Diagrams The Affinity Diagram is a useful planning tool when you want to “add structure to a large or complicated issue, break down a complicated issue into easy-to-understand categories, or gain agreement on an issue or situation.” (Richard Chang Associates, Continuous Improvement Tools, Volume 1). It’s a useful tool for generating project tasks since it helps to break down a complex project into tasks, it is easy to use, and many people are familiar with it and/or similar techniques. There are essentially five steps in an Affinity Diagram session: Step 1: State the goal of the Affinity Diagram session At the start of the Affinity session, tell participants what the goal is for the session (do you want to generate tasks for the entire project, or for a certain aspect of the project?) and provide a time limit for the session. Step 2: Generate ideas on post-it notes or 3 x 5 cards Provide a small pad of post-it notes or a stack of 3 x 5 cards to each participant. Ask them to think of the tasks that will be required to complete the project, and record one task on each post-it or card. To foster a productive brainstorming environment, the group should be instructed to remain quiet during the session. Step 3: Collect the post-it notes or cards Once the group has stopped generating task ideas, the facilitator should collect the post-its or cards and arrange them on a flat surface. Using post-its works well because they can be displayed on a wall or flipchart. Step 4: Arrange the post-it notes or cards into related groups All participants should work together in selecting notes or cards that are related and setting them aside. This process should be repeated until all of the cards or notes have been placed in groupings. Step 5: Create a title or heading for each group Develop a title or heading that best describes the theme of each group of notes or cards. Headings should be short and describe the main theme/focus or the group it represents. If groups are very similar, two or more groups can be combined to create one large group under a new title or heading. Now that the tasks have been defined, they can be placed into a project plan. It is likely that you will modify or change the groupings and tasks, but this provides a good foundation for the group’s understanding of what needs to be accomplished within the context of the project. Joint Application Design (JAD) What is JAD? JAD is a participatory process for designing information systems. It involves a series of facilitated meetings that explore the business needs, system requirements, environmental constraints, and other factors. The focus is on business/user needs and desires, not technical issues and concerns. IRT Project Planning Manual Summer 2006
  • 22. Who are the participants?  Facilitator Must be independent; this role is often filled by an external consultant.  Scribe Takes and publishes the minutes, and records any issues that arise.  Business Line Representatives Executive sponsor; real end users; representative end users.  Technical Representatives Project manager; systems experts; outside experts. What are JAD sessions like? JAD sessions are typically two hours to one week long. The scope and objectives must be defined in advance. The meeting room is set up with flip charts and other devices to aid in discussion; the facilitator walks the participants through the agenda, moving the discussion towards the objectives. When is it appropriate to use JAD? JAD is useful in all phases of the project life cycle. However, it is normally used to determine project objectives, system requirements, and system design. JAD is most effective when the situation requires input from multiple individuals/areas and there is a need to build consensus. What are the benefits of JAD?  Builds consensus and ownership  Improves design quality  Focuses the project team  Reduces project life-cycle costs (A 1989 Casper Jones study found a 20% reduction in the costs resulting from missed requirements.) Where can I learn more about JAD? Joint Application Development by Jane Wood and Denise Silver (Contributor). John Wiley & Sons; ISBN: 0471042994. “Joint Application Design: Business Requirements Analysis for Successful Re-engineering” by Bill Jennerich. http://www.bee.net/bluebird/jaddoc.htm. “Introduction to JAD” by Magdy Hanna, 1992. IRT Project Planning Manual Summer 2006
  • 23. Project Change Management Project change management is the process of determining which requested changes will be made and what impact they will have on the project plan. The single most common cause of project overruns or failure is uncontrolled changes in requirements or major deliverables leading to expansion of the project scope. While no project plan is ever written in stone, there will always be new tasks identified and some tasks discarded, it is important for the project manager to keep a watchful eye out for requests for changes that could have an impact on the timeline or budget for the project. This is particularly important on large projects. If the project sponsor wants significant changes for a deliverable or has major changes in the requirements, a formal change request should be required and reviewed by the IRT Cabinet. This will allow all parties to agree to the additional costs, changes in the timeline, and any additional risks that might be identified, whatever the case may be. The project change request form used in IRT follows the same general outline as the Statement of Work (SOW). You can follow the guidelines for completing the SOW when completing the Project Change Request Form. See Appendix E for an example of the change request form. IRT Project Planning Manual Summer 2006
  • 24. Appendix A: IRT Project Proposal IRT Project Proposal Submission date: Project proposal title Proposal submitted by (name) Proposal sponsor (IRT Cabinet member sponsoring your project) Department Phone number E-mail address Introduction (A non-technical description of what you plan to do and the expected results - the purpose of the proposal and the problem.) Benefits (Statement of why this problem needs to be solved now; payoff in solving problem and possible consequences of inaction.) Proposed Solution to Problem (Brief statement of how you propose to solve problem, including description of pros and cons of all alternative solutions.) Key stakeholders (List individuals, groups or programs that will benefit from this project) Project Details (Brief description of the project’s critical success factors) • Resources: Human resources Person Role Est. Time (hours) IRT Project Planning Manual Summer 2006
  • 25. Other resources (hardware, software, money, etc.)  Expected commitments from other departments or people? •What resources from IT will be required and/or how will this project impact IT? •What resources from Client Services will be required and/or how will this project impact Client Services? •What resources from Web & Media Services will be required and/or how will this project impact WMS? •What resources from Libraries will be required and/or how will this project impact the Libraries? •What resources from NTS will be required and/or how will this project impact Network & Telecom Services? • Known risks: • Evaluation/assessment plans: • Implementation schedule: Send completed proposals via e-mail to IRTProjects@stthomas.edu or Project Sponsor, if you are an IRT employee. Project Sponsor will review with appropriate colleagues, including department head of individuals proposed for project team, and then put on IRT Cabinet agenda for discussion, approval and next steps. IRT Project Planning Manual Summer 2006
  • 26. Appendix B: IRT Project Statement of Work— Long Form IRT Project Statement of Work - Long Date Submitted Revision Number Project Name Project Number Report Prepared By Description and Scope Summary of Work Requested Background Description of Major Elements (Deliverables) of the Completed Work Expected Benefits Items not in Scope Business and/or Educational Objectives Priority IRT Project Planning Manual Summer 2006
  • 27. Approach Major Milestones/Key Events Anticipated Date Milestone/Event Methodologies or Special Standards to be Observed Impact on Existing Projects or Systems Rationale for Build/Buy Decision Assumptions Critical to the Project Plans for Periodic Status Reporting Procedures for Change of Scope and/or Work Effort (PCRs) Resource Requirements Detailed Plan for Human Resources Assignments Person Role Time • • • • • • IRT Project Planning Manual Summer 2006
  • 28. • • • • • • • • • • Other Resources (Hardware, Software, Money, etc.) Expected Commitments from Other Departments or People •What resources from IT will be required and/or how will this project impact IT? •What resources from Client Services will be required and/or how will this project impact Client Services? •What resources from Web & Media Services will be required and/or how will this project impact WMS? •What resources from Libraries will be required and/or how will this project impact the Libraries? •What resources from NTS will be required and/or how will this project impact Network & Telecom Services? Concerns or Alternatives Related to Staffing Any other Resources Required Sizing Ownership Stakeholders IRT Project Planning Manual Summer 2006
  • 29. Risks and Concerns With Respect to the Environment With Respect to User Expectations With Respect to Competing Projects With Respect to Project Assumptions Constraints that are Significant to the Project Current Related Projects IRT Project Planning Manual Summer 2006
  • 30. Future Projects Building on this Effort Risk Category Risk Mitigation Plan Acceptance Criteria Responsibility for Acceptance Process and Criteria Identification of Test Data Testing Approach Termination of Project Estimated Time and Costs Completion Estimate for the Proposed Work Requirements for Special Funding IRT Project Planning Manual Summer 2006
  • 31. Costs for Development and Ongoing Major Arguments or Basis for Time and Cost Outstanding Issues Glossary Item Explanation IRT Project Planning Manual Summer 2006
  • 32. Appendix C: IRT Project Statement of Work— Short Form IRT Project Statement of Work - Short Form Date Submitted Project Name Project Sponsor (IRT Cabinet Member) Project Number Report Prepared By Description and Scope Summary of Work Requested and Benefits This should include a detailed description of the work that will be performed and the benefits that the work is expected to achieve. If items are identified that are clearly out of the scope of this project, they should be noted here. Priority The priority of the project will be determined in the project proposal phase. Major Deliverables/Key Events Anticipated All major identifiable results of the work being performed on the project should be listed here along with the estimated date of completion. This could include a decision on a particular hardware component, the installation of software, or the date training is to begin. Date Milestone/Event Resource Requirements Detailed Plan for Human Resources Assignments List every person or work group that will perform actual work on the project. Provide a brief description of what they will be doing and an estimate in actual hours worked that they will devote to the project. Person Role Time • • • IRT Project Planning Manual Summer 2006
  • 33. Other Resources (Hardware, Software, Money, etc.) All additional resources that will be needed to successfully complete the project should be listed here. This could include hardware and software, documentation and training materials, space, and consultant time. Expected commitments of staff from outside of CCS should be listed here also. Expected commitments from other departments or people? •What resources from IT will be required and/or how will this project impact IT? •What resources from Client Services will be required and/or how will this project impact Client Services? •What resources from Web & Media Services will be required and/or how will this project impact WMS? •What resources from Libraries will be required and/or how will this project impact the Libraries? •What resources from NTS will be required and/or how will this project impact Network & Telecom Services? Risks and Concerns Any event or activity that has the potential of affecting the timeline for completion of the project should be listed here. Pay particular attention to any assumptions made in identifying work and scope and to items that are obviously out of our control. This could include vendor deliveries, labor strikes, or staff turnover. Project Completion Criteria How do you determine that the project is completed? If there will be testing, the testing plan must be developed. If user acceptance is required, these criteria must be defined. Outstanding Issues During the development and walk-through of this statement of work a number of unresolved issues may arise. They should be listed here. As the process moves forward these issues may end up as work or tasks in the project, they may be passed on to another body, or they may be identified as unimportant after all. IRT Project Planning Manual Summer 2006
  • 34. Appendix D: IRT Project Status Report Date Submitted: Project Name Project Number Report Period Report Prepared By Planned Activities for the Period Accomplished Planned Activities Planned Activities Not Accomplished Activity Reason Expected completion Unplanned Activities Performed or Identified Activity Reason Impact on project Planned Activities for the Next Period IRT Project Planning Manual Summer 2006
  • 35. Cost Data To Date Open Issues and Resolutions Review of Change Requests and Change Control Decisions Comments IRT Project Planning Manual Summer 2006
  • 36. Appendix E: IRT Project Change Request Form Date Submitted: Project Name Project Number Project Manager Project Sponsor Report Prepared By 1. Description of Change Requested and Benefits 2. Changes to Major Deliverables/Key Events Anticipated Date Milestone/Event 3. Changes to Resource Requirements 3.1 Detailed Plan for Changes in Human Resources Assignments Person Role Time 3.2 Changes to Other Resources (Hardware, Software, Money, etc.) 4. Changes to Risks and Concerns 5. Changes to Project Completion Criteria 6. Outstanding Issues Regarding the Change Request IRT Project Planning Manual Summer 2006