Standards
Manual
IS Project Course
Table
of Contents
Deliverable 1: Team Organization Plan
Deliverable(s) 2: Weekly Reports
Deliverable
4: Project
Definition Report
Conceptual Data
Model or alternative.
Presentation
1: Project
Definition Presentation
Presentation
2: Proposed
Solution Walkthrough
Presentation
3: Final
Presentation
Many IS or IT groups prepare and use a Standards Manual to specify
project management and content. The manual may cover everything from how to do
the analysis and design to naming conventions for data attributes and program
variables. This standards manual provides specifications for the form and
content of each of the deliverables for an IT project. The textbook, this manual and the grading
sheets for the course can give a team a good idea of what should appear in each
report or presentation. Additional
guidelines for generating deliverables are provided by class instruction and
meetings with your manager. When in
doubt, check with your manager for how to handle deliverables for a specific
project.
The guidelines in this Standards Manual complement material presented
in the text. Review the appropriate
chapter(s) applicable to each deliverable.
The following instructions apply to all deliverables throughout the
semester.
Due Dates. Deliverable due dates are shown in the syllabus. The instructor may modify
the due dates as the course proceeds. Submit each deliverable in both an
electronic and a printed format. Late deliverables will incur a substantial
grade penalty to be determined by the faculty manager.
Client/Manager Relations. Clients and team managers are professionals
with a busy schedule. Follow the text
and Standards Manual guidelines when working with clients and managers. Stay in
contact with your team manager. Your manager can provide guidance only when
informed.
Exceptions.
Your manager must
approve in writing any exceptions to the Standards Manual or text.
The initial deliverables consist of a team organization plan and weekly reports.
At
the beginning of a project, teams develop an organization plan. The purpose of
a team organization plan is to set up the operation of the team and to help
team members gain a common understanding.
Chapters 2 and 3 contain additional information about how to generate the
plan.
At their initial meeting, members should introduce themselves, provide some personal background information, and describe the individual strengths, weaknesses, and resources that they bring to the team. Possible resources include: a meeting place, computing facilities, certain software, etc. With this information, your team can create the organization plan.
The
Organization Plan consists of three sections:
·
Skills
Inventory
·
Team
Contract
·
Preliminary
Project Schedule
Normally the skills inventory summary appears in the format
of a spreadsheet and is attached as an Appendix to the Team Contract. Follow
the format from Chapter 2. Indicate
skill levels in at least the following technologies/languages:
·
Visual Basic
·
VB.NET
·
MS Access/Visual Basic for Applications
·
Java
·
Dreamweaver/Cold Fusion
·
Front Page
·
ASP/.NET
·
XML/XHTML
Team Contract. The contract describes the norms or ground rules the team members will follow. The purpose of the contract is to enhance the effectiveness of the team by establishing operational procedures and determining a productive role for each team member. Each member of the team should agree to the terms and sign the contract. The team manager may return the contract to you for modification or changes as needed.
The contract includes:
· Purpose: What is the purpose of the rule?
· Statement: What is the rule?
· Violation: How do you know when the rule is violated?
· Penalty: What happens if the rule is violated? Exceptions?
·
Responsibility: What is the procedure for taking action? Who is responsible?
Project Schedule.
Attach an initial schedule in Gantt Chart or Activity Table format (see
Chapter 3) as an Appendix to your team contract. Completing a project within
one semester requires planning and a constant awareness of deadlines. The schedule or plan sets forth the steps
needed at each time. The initial schedule
includes:
·
Approximate
due dates for all reports and planned presentations
·
Internal
team delivery dates for draft report and presentation materials that allow for
integration of individual work products into a unified report or presentation
·
Estimated
dates for a group walkthrough or meeting to proof and check every deliverable
prior to submission.
·
The
estimated total team hours required for each activity or subtask
·
Other
items as desired by the team
Revise the plan as the project evolves and the team refines
the deliverables. A revised plan must
accompany every formal deliverable as the course progresses. In the revised
plan, update the schedule times, add additional activities and modify assigned
roles as appropriate.
The
team communicator will prepare a weekly report covering the team’s
activities and submit it by email to the team manager by 12:00 noon each Monday. Follow
the format from Chapter 3. Check with
your manager to determine any critical success measures that he/she wishes to
track each week. The weekly report
contains the following parts.
Weekly Report Format
Copy to:
All team members. Also copy your client if he/she requests it.
Subject line:
“Team ?? Weekly Report”
Body of the e-mail:
·
A text
summary of significant team accomplishments in the body of the e-mail.
This summary should include work completed on specific tasks. Refer to tasks
using the same name and numbering system used in the project schedule.
·
Any problems
and the actions the team is taking to solve them
· Plans for the next week
Attachment:
·
A summary
table or spreadsheet that shows for each
person on the team:
o A brief description of the major work performed this week by task.
o Hours expended on each project task this week.
o Estimated hours remaining on each task.
o
Total
hours expended on the project to date per person and by team.
In
addition to written weekly reports, each team should hold periodic meetings
with their manager. Keep your manger
aware of all meetings you have with your client and the progress of your group.
Deliverable 3: Statement of Work
The Statement of Work (SOW) is your agreement with your client about the work that is to be done. For a Field Project case it should be between two and three pages long. For larger projects in industry SOW documents may be tens or hundreds of pages. Your SOW should contain:
SOW Format
Heading
Document Name (“Statement of Work”)
Project Title
Prepared for client organization
Date
Organization Description
One to two paragraphs that describe who the client organization is and
what their business goals or objectives are for the project.
Problem Statement
One paragraph statement of what the project is.
Work Product
·
Solution
approach: indicate whether this is a
revise, build, buy or combination project.
·
Tasks
that are promised: describe the work
tasks that you plan to do.
·
Deliverables
and dates: indicate the work product
(documents, code, etc.) that you will produce and when they will be delivered.
Constraints
Describe any limitations that may impact the scope or contents of the
solution.
Resources Required
Any resources required from the client.
This will include permission to use the client’s name when contacting
vendors, permission to interview appropriate people for information, money for
purchasing software, etc.
Milestone Dates
List dates for significant events.
This does not include delivery of
the SOW or Proposal Presentation. It
does include three progress meetings with your client, a proposed final
presentation date and a backup final presentation date. Other dates may be included.
Signatures
Prepare signature lines for your manager and the client
representative. The team does not sign
this.
The Systems Development Life Cycle
(SDLC) process used as the framework for this course includes deliverables that
build upon each other. In this course,
the report deliverables consist of the Project Definition Report and the Final Report. All deliverables must meet
professional quality standards – at a level that one would expect from a major
consulting firm.
Format. Use the formats provided in
Chapter 3 for reports. Use a CASE tool, diagramming tool or MS Word, etc. to
create text, tables and diagrams that are neat, clear and readable. Reports should look good and read well –
clean, neat, attractive, bound or stapled, clearly and logically organized,
spell checked and proofed before submission. The project definition report
contributes major components to the final report. Make sure that the reports
are consistent. Correct all errors or problems noted by the manager. Include a copy of the previous graded report
with your team manager’s markings and notes in an Appendix of the final report.
Reports should include a Cover
Memo, a one-page memo from the team to the manager to document the date and
authors of the deliverable. The cover
memo uses memo format, lists all team members, identifies the deliverable, and
points out any significant issues to the manager. The manager can use this memo to document the
date and time of receipt for each deliverable.
The cover memo is the text of the
e-mail that transmits the document to your client and/or manager. The hard copy deliverable should have the
same text attached to it with a paper clip.
It is not a part of the report itself.
Deliverables. In this course, each stage of the project life cycle involves one or more deliverables that follow the general formats described in Chapter 3. Table 1 shows the composition and staging of the report deliverables for the course. As shown in the table, a common structure and set of components apply to the reports, but each one contains unique sections. Note that the project definition report with the errors corrected becomes part of the final report.
Table
1. Report Definitions
|
Sections |
Team Organization Plan |
Project Definition Report |
Final Report |
Chap Ref |
Audience |
|
Team Contract, Skills Inventory & Project
Schedule |
Create |
Update Schedule |
N/A |
2 & 3 |
Instructor |
|
Title Page |
|
Create |
Update |
|
Client |
|
Table of Contents |
|
Create |
Update |
|
Client |
|
Executive Summary |
|
Create |
Revise |
|
Client |
|
Introduction |
|
Create |
Update |
|
Client |
|
|
|
Create |
Include |
6 |
Client and team |
|
Part II Current
Operations |
|
Create |
Include |
6 & 7 |
Client and team |
|
Part III.
Proposed system specifications |
|
Create |
Revise |
8 |
Client and IT designers |
|
Part IV. Alternatives
evaluation and recommendation |
|
Create an
initial version |
Revise |
9 |
Client |
|
Part V.
Design specifications or RFP |
|
|
10 or 11 |
IT designers and vendors |
|
|
Part VI. Implementation and Support |
|
|
Create |
13 |
IT
operators & users |
|
Appendix A.
Signed statement of work. |
|
Create |
Include |
3 |
Client |
|
Appendix B and following. |
|
Create as needed |
Include |
|
Client |
Each report should have a title page. The title page should be in color and include
Project Title
Report Type (e.g. “Project Definition Report”)
Prepared for
Name of the Client organization (with appropriate logo)
Name of the individual Client
Prepared by
The
Team members
Team sponsor
Date
Any document longer than about 10 pages should have a table of contents. The table of contents starts on a new page. It should include
Project title
Section title and starting page for each report section
Appendix (without page numbers)
Executive Summary
Any report or memo longer than three pages should have an executive summary. For long memos this takes the form of an initial paragraph. For Field Project reports it is a separate section following the table of contents. It should repeat and summarize the key points from the report itself in a stand alone form so that it could be taken out of the report and read alone. It should contain no information that is not in the report.
The executive summary starts on a new page. The heading should include
Project Title
Report Type
Section Name (“Executive Summary”)
Prepared by The University of
Oklahoma Field Project Team number
Date
This report describes the current
situation and defines the project and the initial recommended solution
strategy. The objective of this report
is to be certain that the team is solving the correct problem and that the
approach being recommended is acceptable to the client and faculty manager. The
project definition report is written after the Project Definition Presentation
(or Proposal Presentation) and should the material presented in that
presentation along with any changes or additions agreed to at that time. It also includes the propose solution
approach or recommendation that will be followed for the project. (Note:
this approach should also appear in the Executive Summary.)
Include the following sections as shown in Table 1. Each section should include the exact title
that appears below. Each section starts
on a new page.
Project
Definition Report Format
Title
Page
Table
of Contents
Executive
Summary
Introduction:
Project Statement
Overview
Indicate what sections are in the report and
what they are intended to do. There is
no project content here.
Part
I: Current Situation Analysis
This section should give the business reason for conducting this project.
Project Statement,
Strategic Alignment Analysis
Organization, mission, goals, measures, system impact
Goals and Features
for the Proposed System
Constraints for the
Proposed System
Part II. Current Operations
This section should describe what is currently being done, what is to be
kept and what is to be changed.
Current System
Analysis
Narrative in good paragraph form, active statements, clear descriptions
Graphic Data Model of the current
situation.
Complete and correct, consistent with narrative.
Graphic
Process Model of the current situation
Complete and correct, consistent with narrative
Current Infrastructure
As
needed and consistent with the narrative
Retention Analysis for features of the
current system.
Part III: Proposed
System Specifications
This
section should describe what the new system is to look like and how it will
address the problems and goals identified in the previous two sections.
Problem Analysis
Consistent
with the discussion in the strategic analysis section.
Narrative
In correct form and well written. Complete and logical
Complete, correct and
in 3rd Normal Form. Consistent notation Entities, attributes and
relationships match narrative. Metadata
– entity and attribute descriptions
Modified Data Flow Diagram or alternative.
Complete and in correct form. Correct for time and sequence. Inputs
adequate to create outputs. Processes, flows, externals and stores match
narrative.
Metadata descriptions for all objects.
Difference
Reduction Analysis for the proposed system
Part IV:
Alternative Evaluation and Recommendation
This section should recommend a modify, build or buy approach (or
possibly some combination) for producing the solution.
Good titles and descriptions for retain, build or buy. Consider further
options
General estimates of
cost and merit
Comparison of Alternatives
Summary table to compare alternatives. Text description to go with the
summary table
Recommended Alternative
Recommendation and justification based on data presented in the
comparison
Appendix A: Signed Statement of Work
Appendix B and Following: Any documents
or diagrams that will contribute to understanding of the project or alternative
solutions.
The objectives of this report are to be certain that the team is
solving the correct problem and that the recommended approach is acceptable to
the client. In the report, the team demonstrates that it (1) understands the
client’s organization, values and environment; (2) knows what the client wants
and the client’s constraints and (3) can identify some reasonable solution
classes that are acceptable to the client. Follow the guidance in Chapters 3, 6
and 7.
Use Table 1 for guidance while preparing this report. Normally your report will contain all the
sections shown in Table 1. If one or more of the sections does not fit or if
you prefer another order for your problem, talk with your manager. Use the
order of materials and section headings shown here unless your manager agrees
in writing to a different scheme. Always use terms appropriate to your client’s
business.
Remember to correct and revise the project definition report materials
as needed for inclusion in the final report. New sections are described below.
Final
Report Format
Executive
Summary
Revised
to reflect the entire project
Introduction:
Revised
as necessary
Part I: Current Situation
Analysis
Revised to correct errors
Part II. Current Operations
Revised to correct errors
Part III:
Proposed System Specifications
Revised to reflect any necessary changes arriving during implementation
Part IV: Alternatives, Evaluation and Recommendation
Revise the version
presented in the Project Definition Report to reflect the additional work,
evaluation and recommendation. Provide
additional detail to confirm the financial and feature analysis reasons that
justify your recommendation. You must include evaluation as part of each
alternative, provide a summary evaluation table and use the summary table to
justify the recommendation.
Alternative Solutions
Good titles
and descriptions for specific options considered
Good estimates
of cost and merit
Comparison of Alternatives
Summary table to compare alternatives. Text description to go with the
summary table.
Recommended Alternative
Justification based on data presented in the comparison to explain why the chosen system was
selected.
Part V. Design Specifications or RFP
Build Option.
This section applies for a team that creates a solution for in-house
development and develops a prototype as a proof of concept model. Follow the
guidance in Chapters 11 and 12. Discuss with the manager the specific models to
include.
Purchase Option.
This section applies for a team that recommends a purchased product.
The team prepares a RFP and may evaluate bids. If possible, the team obtains
the recommended package or a demonstration version to use as a Proof of Concept
model. When a demo package is not available, the team develops a prototype for
the POC model. Follow the guidance in Chapters 10 and 12.
Part VI Implementation and Support
Follow the guidance in Chapter 13. In many
cases, the client will handle implementation; the team role is to prepare plans
to guide the client.
Appendix A: Signed Statement of
Work. Signed completion statement.
Appendix B and Following: Any
documents or diagrams that will contribute to understanding of the project or
alternative solutions.
Presentations always
should create a professional impression. The face to face presentation can
focus a client’s attention on key parts of the project. Some presentations also allow the client to
participate in key decisions. Well
organized presentations can help the client to make an appropriate choice.
Review the materials in Chapters 3 and 6 on presentations. Presentations
include: the project definition presentation, the proposed system design
walkthrough and the final presentation.
The Project Definition Presentation is a formal meeting in which the
client and the team review the scope of the project and the potential work
products. All team members must attend
the presentation. Feedback from the
client is important. The team uses the presentation to confirm and refine its understanding
of the client’s problem. The usual topics follow:
1.
Strategic
alignment.
2.
Current operations
3.
Problems
with the current situation and the
impact on the goals of the organization
4.
Goals and
features and the constraints of the new system
5.
Broad
classes of possible solutions that are acceptable to the client
6.
Initial
recommendation of solution class.
7.
Client
resources required during the project.
8.
Work
that the team plans to do
9.
Tentative
schedule for delivery of the work.
10. Closing summary of the important points, especially
any new information gained during the discussions.
The purposes of the Project Definition Review are (1) to demonstrate to
the client that the team understands the current situation and has a plan to
create a solution and (2) to obtain client feedback on the work. Present all
information in a fashion that the client will understand. Tailor the
presentation to the audience. Encourage client participation from start to
finish. Follow the guidance in Chapters 3, 5, and 6.
Option A:
Build. The proposed solution
walkthrough is made to the manager with the entire team present. The team presents the system design models, components
and documentation and demonstrates how they fit together. The team and manager look carefully at
completeness and consistency for data, process and I/O design, the
relationships between components and the ability of the design to translate
into an operational system that will address the client’s problem. The team demonstrates the connection of the
design to the proof of concept model.
While the proof of concept model may require more work to complete at
this stage, the team should have built enough to demonstrate how the design
will convert into an operational system.
Requirements for the
walkthrough include:
Option B:
Purchase or Outsource. When
a team pursues a purchase or outsource solution, the documents that the team
brings to the walkthrough include:
The final presentation is the team’s opportunity to explain and sell its
solution. Behave as if the team is a
consulting firm making a final presentation for the client to accept the work
and approve payment. Follow the guidance in Chapter 3.
The basic content is as follows.
1.
Brief
review of strategic alignment emphasizing the impact of the new system on client
values
2.
Review
of problems-solving approaches to arrive at specifications for the proposed
system. What the team did to arrive at specifications.
3.
Summary
or highlights of specifications for the proposed system.
4.
Alternate
solutions with short description and the evaluation of each solution. Include graphs
and charts as needed.
5.
Evaluation
of alternatives - a summary evaluation
table plus a discussion of the criteria for evaluation
6.
The
recommended alternative based on the information in the evaluation.
7.
The POC
demonstration. Demonstrate the solutions
primary functions and show how the solution addresses problems with the old
system and supports client values. Use realistic
test data and if possible give the clients a chance to operate the system.
8.
Training
and implementation plans for the system and a timetable.
9.
Summary
of the important points – an opportunity to reemphasize how the solution
addresses the client’s problem and values.
Important checkpoints:
1.
All
members of the team and the manager must be present for the presentation
2.
Arrive
15 minutes ahead of the scheduled time if possible to prepare the room.
3.
The
grade is based on both content and style – see the grade form.
4.
Half or
more of the charts used in the presentation should show specific content for
the client to note and/or remember -- data, a list of benefits, and so forth.
An occasional outline chart is fine, but make sure that content slides are included.
5.
The
proof of concept demonstration is a central part of the presentation. Make sure
that the POC demo will work in the client’s environment of prior to the
presentation.
6.
Limit the
presentation to about 30 minutes excluding questions and discussion.