Transition Meeting and the Project Plan

Information Technology Projects

Fall 2005

Prof. Arthur Goldberg

Computer Science Department, New York University

Summary

Analysis to development transition meeting goals and the content of the Project Plan

Introduction

After an IT project completes, people evaluate it by considering its accomplishments. To achieve significant accomplishments a project must be organized. In particular, I think that an appropriate balance of planning, analysis and design, followed by implementation and deployment, is crucial. Therefore, we explicitly recognize the transition from the former to the later by holding a ‘Transition meeting’1 with our clients.

Development Project

This table summarizes the division of tasks for a Development Project before and after the transition meeting:

Tasks completed before the transition meeting

Tasks completed after the transition meeting

  1. Client relationship

    1. Develop rapport with the client’s team

    2. Learn about the client organization

    3. Set up logistics for communication with client

  2. Business goals

    1. Learn about the client’s long term strategic objectives

    2. Collect ‘wish list’ of features for the project2

  3. Develop project specifications

    1. Narrow down ‘wish list’ to achievable objectives

    2. Write up project specification

    3. Clarify the project’s deliverables

    4. List problems that could hinder the project (the ‘risks’)

  4. Design

    1. Design the system’s architecture

    2. Design the system’s central algorithms

    3. Decide which tools will be used (evaluate and test tools)

  5. Development Plan

    1. Plan the project’s schedule

    2. Enumerate resources (equipment, software, advice from people) needed to complete the project

    3. Subdivide the project’s work into tasks

    4. Allocate tasks to team members

  1. Implementation

    1. Team members execute implementation tasks

    2. Partial results communicated to client for feedback

  2. Quality assurance and testing

    1. Team members review each other’s code

    2. Team members writing software unit-test their components individually

    3. Team members writing software system-test their components collectively

  3. [Deployment—not part of these projects]

  4. [Training—not part of these projects]

  5. Demo

    1. Present the system at Projects DemoShow

  6. Delivery

    1. Transfer all results (documents, code, data, etc.) at the wrap-up meeting


I would like you to write a “Project Plan” which we can discuss at the meeting.

Suggested Outline of an Implementation Project Plan34

This outline contains many of the pieces in the Project Plan for an implementation project. Use only those pieces that are appropriate for your project. I will understand if a few parts are missing because they have not been decided yet.

  1. People

    1. Who is participating in the project, and what are their roles?

      1. Student team

      2. Client team

  2. Business goals

    1. Summarize the organization

    2. Why does the organization want to do this project?

    3. What might the organization or business gain?

      1. Revenue

      2. Market-share

      3. Decreased costs

      4. Efficiency

      5. Better image

      6. Government compliance

      7. Risk reduction

      8. Other

    4. What might the organization or business lose?

      1. Project cost

      2. Opportunity costs

      3. Other

  3. Requirements: What should the system do? Should be a detailed list, with perhaps many items.

      1. Tabulate ‘wish list’ of features, including, where appropriate

        1. Detailed description

        2. Requestor’s name

        3. Importance (as a function of viewpoint, sometimes)

        4. Difficulty

        5. Category: functional or other

      2. What other systems must the system interface with, if any?

        1. System names and brief descriptions

        2. Organizations responsible for the systems

        3. References to information about these systems

        4. Documentation, URLs, books and articles, people

        5. Describe how the interface will probably work

      3. Deliverables

        1. A subset of the ‘wish list’ of features, which you plan to actually accomplish in the project. Try to be realistic about what can be accomplished, given the time and people available.

  4. Proposed System Architecture

    1. Components

      1. Their functions

      2. Their interfaces

    2. What technologies will the project use?

      1. Required and/or desirable tools

        1. OS(es)

        2. Language(s)

        3. Development environments

        4. Other

      2. Briefly, why are these tools appropriate?

      3. References to information about these tools

      4. Briefly, tradeoffs between tool choice, if a choice is possible

    3. Draft detailed designs

      1. Algorithms

      2. Data structures

      3. Protocols

      4. User interfaces

        1. Mockups usually helpful

        2. Document agreement between users and business managers, and development team

    4. Test plan

  5. Development Plan

    1. List project risks. For each risk

      1. What might go wrong?

      2. How might the risk be mitigated?

    2. Important open issues

    3. Resources

      1. A list of the resources you'll need (computers, software, reports, data) to accomplish the deliverables. Describe how they'll be provided.

    4. Enumerate tasks—break the project into at least as many tasks at team members

      1. Describe the task

      2. Estimate the effort involved in each task. At this point, the actual effort may range between 50% and 200% of the estimate.

    5. Schedule

      1. A weekly schedule for the accomplishment of tasks leading to the deliverables.

    6. Individual responsibilities

      1. An allocation of the tasks among the students. For example, Robert will write the schema, and Samantha will load the data. Allocate tasks according to interest and skill. Try to divide tasks so each person can make significant progress independently, that is, without having to talk to someone else for a while. This speeds progress.

    7. Demo plans for the DemoShow

Systems Acquisition Project

This table summarizes the division of tasks for a Systems Acquisition Project before and after the transition meeting:

Tasks completed before the transition meeting

Tasks completed after the transition meeting

  1. Client relationship

    1. Develop rapport with the client’s team

    2. Learn about the client organization

    3. Set up logistics for communication with client

  2. Business goals

    1. Learn about the client’s long term strategic objectives

  3. Develop system specifications

    1. Obtain broad ‘wish list’ of features for the project

    2. Rank the features by priority

    3. List problems that could hinder a successful deployment (the ‘risks’)

  4. Design

    1. Clarify the business process relationships, that is, how the system would with interact with the organization

    2. Design the system’s architecture, that is, how it will interact with other systems

  5. Candidate systems

    1. Identify, hopefully, all reasonable candidate systems

    1. Compare systems

      1. Identify features common to all systems

      2. Identify features that distinguish systems

    2. Narrow the field

      1. Identify subset (perhaps half dozen or fewer) systems worthy of further evaluation

    1. Plan for further system evaluation

    2. Subdivide the project’s work into tasks

    3. Allocate tasks to team members

  1. Detailed system review

    1. Read all available documentation

    2. Try to obtain independent evaluations (perhaps Gartner or similar—ask me)

    3. Try to obtain in-person demos

    4. Try to obtain feedback from existing customers

    5. Prepare comparison matrix

  2. Plan deployment, if time allows

    1. Data conversion

    2. Switch over

    3. Training

  3. [Deployment—not part of these projects]

  4. [Training—not part of these projects]

  5. Demo

    1. Present the comparison matrix at Projects DemoShow; possibly demo evaluation copy of selected product

  6. Delivery

    1. Transfer all results (documents, code, data, etc.) at the wrap-up meeting



Suggested Outline of an Acquisition Project Plan

This outline contains many of the pieces in the Project Plan for an implementation project. (An project will differ somewhat.) Use only those pieces that are appropriate for your project. I will understand if a few parts are missing because they have not been decided yet.

  1. People

    1. Who is participating in the project, and what are their roles?

      1. Student team

      2. Client team

  2. Business goals

    1. Summarize the organization

    2. Why does the organization want to acquire some system?

      1. What business process(es) would the system service?

      2. What existing systems would the acquisition replace, if any?

    3. What might the organization or business gain?

      1. Increased revenue

      2. Market-share

      3. Decreased costs

      4. Higher efficiency

      5. Better image

      6. Government compliance

      7. Reduced risks

      8. Other

    4. What might the organization or business lose?

      1. System cost

      2. Opportunity costs

      3. Transition or switching costs

      4. Costs of inadequate performance of an acquired system

  3. Requirements: What should the system do? Should be a detailed list, with perhaps many items.

    1. Tabulate ‘wish list’ of features, including, where appropriate

      1. Detailed description

      2. Requestor’s name

      3. Importance (as a function of viewpoint, sometimes)

        1. E.g., Required, desirable, necessary in x years, unnecessary

      4. Difficulty

      5. Category: functional or other

    2. What other systems must the system interface with, if any?

      1. System names and brief descriptions

      2. Organizations responsible for the systems

      3. References to information about these systems

      4. Documentation, URLs, books and articles, people

      5. Describe how the interface will probably work

  4. Candidate systems

    1. List comprehensively

      1. For each system, include

        1. Name

        2. Vendor

        3. Price

        4. Functionality (briefly summarized)

        5. Number of users and installations

        6. Vendor’s status

        7. Whether the systems warrants further investigation, and why

  5. Plan for review, evaluation and selection

    1. Data collection

      1. For systems that warrant further investigation, identify a subset of these actions to pursue

        1. Review system documentation

        2. Obtain third party reviews of system – sources include

          1. Trade press

          2. Current customers

          3. Technology analysis firms like Gartner

        3. Communicate with vendor’s sales staff

        4. View a vendor’s demonstration

        5. Evaluate a trial use

      2. Plan for further collection of client requirements, if necessary

    2. Project plan

      1. List deliverables

        1. Which of the following will be provided?

          1. Comparison matrix

          2. Running test software

          3. Vendor’s demonstration

      2. List project risks. For each risk

        1. What might go wrong?

        2. How might the risk be mitigated?

      3. Enumerate tasks—break the project into at least as many tasks at team members

        1. Describe the task

        2. Estimate the effort involved in each task. At this point, the actual effort may range between 50% and 200% of the estimate.

      4. Schedule

        1. A weekly schedule for the accomplishment of tasks leading to the deliverables.

      5. Individual responsibilities

        1. An allocation of the tasks among the students. For example, Robert will contact vendors A to L, and Samantha will contact vendors M to Z. Allocate tasks according to interest and skill. Try to divide tasks so each person can make significant progress independently, that is, without having to talk to someone else for a while. This speeds progress.

    3. Plan for selection of ‘winning’ system

      1. How will decision be made?

      2. What input will be needed?

  6. Demo plans for the DemoShow

Transition Meeting Agenda

Students present analysis report (each student presents their work)

45 to 60 min

All discuss proposed plan; hopefully achieve consensus

30 to 45 min

All discuss availability of resources

5 min

Discuss allocation of responsibilities among students and client

5 min

Discuss proposed DemoShow presentation

10 min


1 This meeting will be like the “Planning Checkpoint Review” in Steve McConnell's Software Project Survival Guide (Microsoft Press, 1998, ISBN: 1-57231-621-7 http://www.construx.com/survivalguide/). Some of the ideas come from McConnell's “Agenda for the Planning Checkpoint Review”, http://www.construx.com/survivalguide/checkpointagenda.htm.

2 Obtained by: interviewing concerned parties (users, management), dreaming up features, analyzing the competition or other methods.

3 See http://www.cs.nyu.edu/artg/itp/ExampleTransitionReports/ for some example project plans. Note that some projects involve developing software, whereas others involve evaluating software to be purchased.

4 For an interesting reference on project planning and management see the New York State Office for Technology's Project Management Guidebook, at http://www.oft.state.ny.us/pmmp/guidebook2/index.htm. New York State requires that companies who write software for the state to follow these guidelines.