Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 4

IX.

Project Management Plan (Nick)

Develop your opening statement. This section of the business case provides a summary of the
team's plan for managing and implementing the proposed project. Its purpose is to convince the
decision-maker(s) that the project will be managed effectively, so that the stated objectives will
be met within the time and budget allocated to the project. A complete “Project Management
Plan” would be separately developed and contain much more detail than is required here. This
section should begin with a brief introduction followed by three subsections (A, B, C.), with a
lead in statement for each:

A. Project Management

Write a description, using a paragraph for each, explaining how the following aspects of the
project will be managed:

1. Project Scope (Rahel)

2. Test and Evaluation Plan (TEP) (Rahel)

3. Time and Schedule (Rahel)

4. Cost (Rahel)

5. Quality Assurance Plan (QAP)

6. Communications Plan

7. Stakeholders

B. Project Team

List the members of the project team by their roles (not by name).

C. Schedule (Thao)

Provide a schedule that lists the major tasks involved and how much time they require. The
schedule should be detailed enough to cover all the important activities, but does not need to
include a Work Breakdown Structure.

The schedule (“C.” above) should be developed with the understanding that when the business
case is approved, many of the project planning and analysis and design steps will have been
completed. So, using the information previously documented in the business case, the team
should identify the major steps that remain to fully implement the project, and determine
reasonable timeframes for them to be accomplished. The schedule should be presented as a table
with tasks, duration, and participants, including the person who has the lead for that activity. The
following table may be copied and used, if so desired:
Task Duration Leader Participants

Task 1

Task 2

Etc.

Remember to include your identification line here.

Approach to Developing this Section

As a reminder, remember to add a single line space between each section and subsection. The six
management areas listed come from the Project Management Body of Knowledge (PMBOK) list
of about ten knowledge areas. Use the resources provided in the Week 6 Content to fully
understand what is to be included for each of the above management areas.

In developing the list of the project team members, keep in mind the scope and resources for the
project, including both people and finances. The project team

should have all the required skill sets, but team members may function in multiple roles. In order
to keep costs low, the team should be as small and efficiently designed as possible. The team
should include both functional (business) and IT personnel.

X. Acquisition Strategy (Nick)

Develop your opening statement for this major section here. This section provides a
recommendation and rationale for how the enterprise solution will be acquired. Often a
combination of acquisition strategies are used, especially when both end-user hardware and
enterprise systems are part of the solution. Then, determine which categories below apply to your
solution, adding others as appropriate to your solution. Be sure that everything that is needed is
included. (The explanations for the sub-sections numbered 1-3 follow the list.)

A. End User Hardware (Riya)

This includes all hardware to be used by the individuals who will use the system.

1. Scope

2. Infrastructure

3. Contract(s)

B. Proposed System (Brian)

This is the proposed system – how it will be acquired for use by your client’s organization.
1. Scope

2. Infrastructure

3. Contract(s)

C. Connectivity to Proposed System (Blake)

This includes whatever is needed for the end users to connect to the proposed system (both from
the business locations and remotely, as appropriate).

1. Scope

2. Infrastructure

3. Contract(s)

Remember to add a line-space following each ABC section, showing a transition has occurred.
Then, for each category of components, include

the answers to the following questions that are applicable to that item (remember not to use the
question-and-answer format, but include the information in paragraph form, using the terms of
your client):

· Scope of what to buy:

What items in this category need to be acquired (list)? Buy as a product or service? (Some items
may be purchased and others may be acquired as a service). Commercial-off-the-shelf (including
open source) or custom? Will in-house staff or external contractors support custom development,
integration, or sustainment? Ensure your project scope describes the limitations or boundaries of
work to be performed (services) or product to be provided.

· What infrastructure will need to be acquired? Will system hosting services be needed? How
will connectivity be made available? What security considerations should be included in the
contracts? Will any specific hardware or software need to be acquired to provide security? Will
Business Continuity requirements need to be included in the contract(s)? Will separate Business
Continuity solutions or components need to be included or acquired? Are there any data
management considerations to be included in the acquisition(s)? Not all of these responses are
for one specific “Infrastructure” response.

· What type of contract(s) should be used? Purchase order? Local commercial purchase?
Subscription? Service Level Agreement (SLA)? Lease? Subscription? Service Agreement?
Competitively awarded contract? Time and Materials (T&M) contract? Firm Fixed Price (FFP)
contract?

Approach to Developing this Section


Before beginning this section, read the "Basics of Defining Information System Acquisition
Strategies," in the Week 6 Content. It explains how to approach acquisition planning and will
help in responding to the questions above. That document provides a guide to completing the
documentation for a full acquisition strategy plan, which would include many of the same topics
as are included in this business case.

For this section, focus on responding to the questions above, as they apply to what will need to
be acquired for the system you are proposing. Be sensitive to the given logical order, and not
mixing end-user hardware, the proposed system, and connectivity. In the same way, do not allow
any contractual Ts and Cs (terms

and conditions) to bleed into the other two areas of each subsection. Multiple acquisition
strategies may be identified for the proposed solution. For example, some components may be
purchased outright by corporate credit card or purchase order. Other products or services may be
leased or available by subscription or service contracts. If such is the case with the proposed
solution, all of the applicable questions for each type of acquisition recommended need to be
considered and responses should be provided if they apply to what is being acquired.

Do not illogically intermix elements of this template. Simply address each element in order.
Some questions may not apply to the component being acquired (e.g., there does not need to be a
data management strategy identified for a printer that is to be purchased). Keep in mind that the
full security requirements and solution will be covered in Section XII (yet to be developed), but
your solution should have identified what security hardware and software would need to be
acquired, and you should include here any security requirements that should be included in
contracts or service requests associated with your solution.

You might also like