1        Requirements Evaluation and Proposal Phase

NOTE: For the Purposes of this Documentation, MARVEL is a sample project codename.

The Requirements Evaluation and Proposal Phase is designed to focus on initial steps needed to get the Marvel project rolling. The Marvel project Organization Documents needed in this phase all have templates in the Marvel project Binder.

Before proceeding to Phase 2, view the Phase 1 roadmap and complete the Phase 1 checklist.

1.1    User Requirements Document Target Completion Notice (TCN)

The User Requirements Document Target Completion Notice is a memo that should be completed by the Marvel project sponsor and sent to all users affected by the Marvel project. The memo should also be forwarded to all involved department heads.

1.2    User Requirements Document (URD)     

Allows users to submit requirements regarding prospective projects. This document describes the customer problems that need to be solved and focuses exclusively on defining those problems - not the solutions to those problems. The Core Team and select end-users should be pro-active in the drafting of this document. Areas to be addressed include:

·         Fundamental Problem to be solved

·         Tasks/functions the tool will perform

·         Benefits/Savings/Cost Justification

o        Economic

o        Productivity Gains

o        Contribution to stated management goals and objectives

·         User's current mode of operation, including

o        Current software tools in use

o        Current hardware tools in use

o        Current manual tasks

o        Forms in use

·         Environment

·         Ease of use

·         Hardware/Software

·         Information/Data that will be included

·         Publication Media

·         Quality

·         Performance Requirements

·         Security

·         Compatibility/Migration

·         International

·         Service and Support

·         Pricing/Licensing

·         Publications

·         Standards/ISO Compliance

·         Employee laws

·         Product integration

·         Packaging

·         Competitive offerings

·         Related/Dependent Projects; Other Dependencies

1.3      Project Organization Documents (POD)

Project organization documents ensure the involvement of all team members necessary for project success, gain commitment from all parties and clarify roles and responsibilities.

1.3.1            Sponsor Formalization Letter (SFL)   

Letter to formalize the appointment of a sponsor and the sponsor's acceptance of the responsibilities involved in the role. This letter should be completed by the sponsor and forwarded to all involved departments.

1.3.2            Letter of Appointment (LOA)

Letter sent by the Sponsor to publicly identify and appoint the Marvel Project Manager and to state his role, responsibilities, and authority to get the Marvel project done; can also state other team's/department's expected role/responsibility on the Marvel project. A written appointment:

·         Minimizes confusion

·         Makes a public statement about the Marvel Project Manager’s role

·         Is communicated to all groups that may be involved in the Marvel project

1.3.3            Core Team Roster (CTR)            

List of core group representatives participating on the Marvel project team. Information includes:

·         Name

·         Role

·         Organization

·         Phone

·         Email Address

Default members of the Core Team should include a representative from the development team management, MIS management, production management, and Enterprise Best Practices. Other members should include representatives from each of the user communities involved or affected by the Marvel project. The Core Team is responsible for producing the Framework Rules as well as evaluating the scope of the Marvel project and producing a document that outlines the steps, documents, and deliverables applicable to the Marvel project at each phase. This document should be kept in the Marvel project Binder and used as a tailored roadmap to guide the Marvel project through its entire life cycle.

1.3.4            Risk Officer

The Core Team should identify and appoint by letter one member to serve as the Risk Officer. The Risk Officer’s function is to play devil’s advocate at all stages of the Marvel project, continually looking for potential problems and unrealistic planning. Preferably, the Risk Officer should be a senior member of the team who brings previous experience as an asset.

1.4    Framework Rules (FR)         

Framework defines agreements made by the Marvel project team as to how the team will operate. It should clarify the expectations of the Marvel project participants and insure that important decisions are made early and documented. The Core Team should participate in the drafting and finalization of the Framework Rules. The decisions in this meeting do not need to be unanimous. Fill in the decisions below by typing the answers beneath the headings as listed.

1.4.1               PLANNING DECISIONS

1.4.1.1              Development

• Who is responsible for developing the Marvel project plan?
• If more than one person, who should be involved?
• What are the specific roles and responsibilities of each participant?
• What does the plan include?
• Does it meet customer’s/management’s needs?
• What product or service life cycle will it follow?
• Will meetings be needed to define the Marvel project plan?
• When and where should they be held?
• Who will attend?
• Who needs to be informed of decisions made?
• How will they be kept informed?
• Will a list of terms be distributed for better comprehension?
• Is there a plan to continuously improve our management of the Marvel project?
• Is there past experience on similar projects?
• How can we use it?

1.4.1.2              Planning Output

• What are the outputs from the planning process?
• In what format will they be presented?
• How detailed should they be?
• Who needs to receive them?
• Who is responsible for them?
• How will we know that each output is completed?
• Who will assess the quality of each output?
• Who needs to approve and sign off at the completion of each output?
• How will we know that it has been signed off?

1.4.1.3              PM Tools

• What project management tool(s) are we going to use?
• What equipment is required to support the tool(s)?
• Will all sub-projects use the same tool?
• Who will operate the chosen tool?
• Who will enter planning and tracking information?
• Who will need training to operate the tool?
• Who will provide technical support for the users of the tool?
• What additional software do we need in order to support the Marvel project management tool?
• For financial related issues?
• For action items, follow-up, etc.
• For documentation.

1.4.2               TRACKING DECISIONS

1.4.2.1              Tracking

• How will we assess progress?
• How will we get data from the Marvel project team members and others about the progress of each activity?
• How often will we get this data?
• At what level of detail will we track the Marvel project?
• Who will assess the impact of each variance?

1.4.2.2              Progress Review Meetings

• What types of meetings will we hold? (e.g. general, top level, activity specific, etc.)
• Where will they be held?
• How often will they be held?
• What’s the process for calling an emergency meeting?
• Who will define the strategy and method for managing meetings effectively?
• Who will run these meetings?
• Who will produce an agenda to be distributed before each meeting?
• How will the meetings be run?
• Who should be included in each type of meeting?
• In what format should the meeting information be presented?
• Who will keep minutes of the meetings?
• Who will produce them?
• To whom should they be distributed?

1.4.2.3              Reporting

• What project reports will be generated?
• Who will generate, analyze and distribute them?
• To whom should they be distributed?
• What content is appropriate for each audience?
• How detailed should status reports be for each audience?
• What formats (tabular, narrative, graphic) communicate best to each audience?
• What criteria will we use to define an exception for exception reporting (e.g. deviation, spot light, urgent action, etc.)?
• Who initiates these reports?
• Who will receive and analyze exception reports?
• Note: Exceptions may be defined differently depending on the roles and levels of people to whom they are addressed.

1.4.3               PRACTICES DECISIONS

1.4.3.1              The Marvel project File (click here for a sample)

• What should the Marvel project file contain?
• How will all project information be kept?
• Who will create the Marvel project file?
• Who will update and maintain it? Will changes to the file be allowed?
• If so, by whom? Has a filing system been set up for all documents?
• Where will the file be located (on-line, paper copy, library, etc.)?
• Who will have access to the file (to update, change for information only, etc.)?
• For how long will the file be kept after project completion?
• Who will keep it after project completion?
• How will it be used?
• Where will it be stored?

1.4.3.2              Managing Change

• When will the plan baseline be frozen?
• Who will make the decision to freeze the plan?
• What will the decision to freeze it be based on?
• What criteria will we use to define change (e.g., design changes, baseline changes, schedule changes, etc.)?
• Who will define the change management process we will use?
• Who will maintain the change log?
• Who will have change approval authority?
• What documents will be presented for change approval?
• How will we document approved plan changes?
• How will we assess the impact of changes?
• Who will set adaptive actions?
• How will we track the effectiveness of these adaptive actions?

1.4.3.3              How will we decide whether to update the baseline plan?

• How much deviation from the plan are we willing to accept before doing a total reschedule?
• How will we link revision to the change management process?

1.4.3.4              Continuous Improvement/Project Assessment

• Will a project assessment meeting be held?
• Who will attend?
• What subjects will be addressed?
• How often during the Marvel project life will an assessment be done?
• How will we document the Marvel project assessment so that others can learn from our experience?
• What information should be kept to provide a historical basis for continuous improvement?

1.4.3.5              Project Lifecycle

• Which lifecycle will be used?
• Is there a standard (common) lifecycle?
• Are we going to define one for this project?
• Who is responsible for defining it?
• By when should it be fully defined?
• What is the release plan process for this project?
• Is the product release part of this project?
• Who owns the release plan?
• By when should the plan be fully defined?
• Who has the authority to approve it?

1.4.4               RELATIONSHIP DECISIONS

1.4.4.1              Ownership

• What departments or organizations will we need to interact with during the life of the Marvel project?
• What are the roles and responsibilities of each organization (reviewer, approver, creator, etc.)

1.4.4.2              Communication

• How do we communicate?
• Among ourselves (project team) and with others outside the team?
• How frequently do we need to communicate?
• How will we keep all involved parties informed of deliverables, schedule dates, expectations, problem areas, etc.?
• Are there specific communication milestones dates or intervals?
• What information will and will not be exchanged?

1.4.4.3              Escalation

• What is the process we will use to resolve disagreement?
• What is the conflict resolution process?
• What is the standard decision making process?
• What is the escalation process we will use for making decisions?
• Who has final decision making authority?
• Who decides when to escalate a problem?

1.5    Framework Rules Document (FRD)

The Core Team is responsible for drafting a document to address all of the issues listed in section 1.4. The document must be included in the Marvel project Binder.