project manual.doc

I NFORMATION

RESOURCES &

TECHNOLOGIES

Project Planning Manual

Last revision: July 2006 by Marie Morzenti

IRT PROJECT PLANNING MANUAL

Table of ContentsIRT Project Management Methodology....................................................................................................2

Project Life Cycle.........................................................................................................................................4

Writing a Project Proposal.........................................................................................................................8

Creating a Project Folder..........................................................................................................................11

Creating the Statement of Work..............................................................................................................12

Generating a Task List..............................................................................................................................19

Project Change Management……………………………………………………………………………22

Appendix A: IRT Project Proposal..........................................................................................................21

Appendix B: IRT Project Statement of Work— Long Form................................................................23

Appendix C: IRT Project Statement of Work— Short Form...............................................................26

Appendix D: IRT Project Status Report.................................................................................................28

Appendix E: IRT Project Change Request Form……………………………………………………..31

IRT Project Planning Manual Summer 2006

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 proposalDevelop your project proposal using the on-line form or outline (available on the project web site and at \\ust-deptstore1\DeptsF-K\IRT\Projects ), 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-DeptStore1\DeptsF-K\IRT\Projects 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 WorkCreate 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 listIdentify 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 reportsStatus reports should be completed, stored in your project folder and an e-mail alert of its availability sent to your project sponsor and [email protected] 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-deptstore1\DeptsF-K\IRT\Projects .


http://www.stthomas.edu/irt/projects/management

mailto:[email protected]

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.


Project Life Cycle

Information Resources & Technologies Project Life-Cycle

Concept

Beginning of Proposal

Proposal

Project Form

Requirements

Requirements Document

Design

Design Document

Development

Coding

Testing

Completion of Test Cases

Cancelled

NA

On Hold

NA

Completed

Project Review Report

Planning

Statement of Work and Walkthru with

IRT & Project Team, Project

Task List, Status Reports begin

Implementation

Documentation, Train Users, TechDesk &

Technicians, and Installation of

Project

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.

ConceptThe 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.

ProposalIn the proposal phase, a project proposal is submitted to the IRT Project Review Group and reviewed.

PlanningIn the planning phase, you would

Prepare a Statement of Work (SOW) document. Put together the task list. 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.

RequirementsIn 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.

DesignIn 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.


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 [email protected] by the 15th of

each month.



The end deliverable of this phase is the design document.

DevelopmentIn the development phase, you would develop the end product.


Write the code for the application. Make necessary modifications to support vendor modules. Submit Monthly Status Reports to your project sponsor and [email protected] by the

15th of each month.

The end deliverable of this phase is functioning code (in the case of application development).

TestingIn the testing phase, you would engage in testing.


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 [email protected] by the

15th of each month.

The end deliverables of this phase are executed test cases and user sign-off.

ImplementationIn the implementation phase, you implement the project.


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 [email protected] 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.





CompletionIn the completion phase, you review how the project went. The end deliverable of this phase is the post-implementation review report.

On HoldIf 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.)

CanceledIf 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.


Writing a Project Proposal

Purpose of a project proposal, and how it fits into the IRT project management processA 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.

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 itThere 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


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 statementTells 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 statementUsed to convince sponsors that you and they think alike, a useful approach with innovative projects.

Historical statementUsed 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 statementIntended 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?


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 costsConsider 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 stakeholdersThese 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 suggestionsList 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 plansEvaluation 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 processOnce 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:


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 or IRT goal

Capital campaign web site; recruitment applications

High benefit/low cost or risk

Medium New product or serviceEnhances existing product or serviceInitiated by another UST departmentHigh benefit/high cost or risk

Low Nice to have but not essential Immunization web formLow 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.


Creating the Statement of Work

Purpose of the SOW, and how it fits into the IRT project management processThe 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 GuideA 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 DescriptionLarge 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 itYou 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?”)


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.


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.


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 Hour

Total Cost

Project Management 200 (1 person @ 2hrs a wk for 100 wks)

$60.00 $12,000.00

Requirements 150 (10 people @ 1 hrs a wk for 12 wks + 1 person for 30 hrs)

$60.00 $9,000.00

Design 320 (1 person @ 40 hrs a wk for 8 wks)

$60.00 $19,200.00*

Development 640 (2 people @ 40 hrs a wk for 8 wks)

$60.00 $38,400.00*

Testing 480 (3 people @ 40 hrs a wk for 4 wks)

$60.00 $28,800.00*

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-throughWhen 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 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 ManagementThere 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.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 DurationEstimating 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 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.


Generating a Task List

Affinity DiagramsThe 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.


Who are the participants?

FacilitatorMust be independent; this role is often filled by an external consultant.

ScribeTakes and publishes the minutes, and records any issues that arise.

Business Line RepresentativesExecutive sponsor; real end users; representative end users.

Technical RepresentativesProject 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.


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.


Appendix A: IRT Project Proposal IRT Project Proposal Submission date:

Project proposal titleProposal 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)


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 [email protected] 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.



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 ScopeSummary 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

ApproachMajor 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 RequirementsDetailed Plan for Human Resources Assignments

Person Role Time


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


Risks and ConcernsWith 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


Future Projects Building on this Effort

Risk Category

Risk Mitigation Plan

Acceptance CriteriaResponsibility for Acceptance Process and Criteria

Identification of Test Data

Testing Approach

Termination of Project

Estimated Time and CostsCompletion Estimate for the Proposed Work

Requirements for Special Funding


Costs for Development and Ongoing

Major Arguments or Basis for Time and Cost

Outstanding Issues

Glossary

Item Explanation


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 ScopeSummary 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.

PriorityThe priority of the project will be determined in the project proposal phase.

Major Deliverables/Key Events AnticipatedAll 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.


Resource RequirementsDetailed 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


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 ConcernsAny 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 CriteriaHow 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 IssuesDuring 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.


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


Cost Data To Date

Open Issues and Resolutions

Review of Change Requests and Change Control Decisions

Comments


Appendix E: IRT Project Change Request FormDate 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


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


project manual.doc

Business

irt project proposal

project change management

irt project status report

project completion criteria

project life cycle

description of change

appendix e

appendix d