Standards Manual

IS Project Course






Table of Contents


General Instructions  2

Initial Deliverables  2

Deliverable 1:      Team Organization Plan  2

Deliverable(s) 2:       Weekly Reports  4

Project Reports  6

General:  All Reports  7

Title Page  7

Table of Contents  7

Deliverable 4:      Project Definition Report 8

Conceptual Data Model or alternative. 9

Deliverable 5:      Final Report 9

Presentations  12

Presentation 1:         Project Definition Presentation  12

Presentation 2:         Proposed Solution Walkthrough  12

Presentation 3:         Final Presentation  13



General Instructions


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. 



Initial Deliverables


The initial deliverables consist of a team organization plan and weekly reports.


Deliverable 1:          Team Organization Plan


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


Skills Inventory.  The team skills inventory specifies at least the following information for each member:

  • Technical skills:  The level of knowledge or skill the member possesses for specific computer languages and technologies
  • Work preferences:   Who likes to write, make presentations, write code, examine technology, design systems?
  • Role preferences:  Take charge, support other members, work individually, and organize things.


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:

  1. A statement of team purpose and goals.  The purpose should include academic as well as client goals.
  2. Initial role(s) for each person.  Initial roles can include Coordinator, Communicator(s) between client and or manager, Standards Manager.  Other specific roles should be assigned only if they are needed immediately.   Remaining members may be assigned as “Member.”  As the team matures and learns more about the project, the team may reassign roles.  Each role should be defined.
  3. A team management or governance plan. The governance plan outlines the procedures the team will follow for decision-making. 
  4. A code of conduct.  The code should include at least ­three team rules.  The code of conduct describes the norms or ground rules the team members will follow. The team should establish both task-oriented and people-oriented ground rules. Behavioral expectations, specific consequences for violating the expectations and the procedures for applying the consequences should be addressed. Each conduct rule should be objective and specific enough that an observer can tell whether a member of the team has satisfied the rule and include a consequence that is clear and enforceable.  Each rule should include sections for:

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


Deliverable(s) 2:      Weekly Reports


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



·         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



Document Name (“Statement of Work”)

Project Title

Prepared for client organization


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.


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.


Prepare signature lines for your manager and the client representative.  The team does not sign this.


Project Reports


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                       



Team Organization


Project Definition Report

Final Report

Chap Ref


Team Contract, Skills Inventory & Project Schedule






2 & 3


Title Page






Table of Contents






Executive Summary












Part I. Current Situation Analysis





Client and team

Part II Current Operations




6 & 7

Client and team

Part III. Proposed system specifications





Client and IT designers

Part IV. Alternatives evaluation and recommendation


Create an initial version




Part V. Design specifications or RFP




10 or 11

IT designers and vendors

Part VI. Implementation and Support





IT operators & users

Appendix A. Signed statement of work.






Appendix B and following.


Create as





General:  All Reports

Title Page

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 University of Oklahoma Field Project Team number (with logo)

Team members

Team sponsor


Table of Contents

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


Deliverable 4:          Project Definition Report


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



            Project Statement


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.


                        In correct form and well written. Complete and logical

Conceptual Data Model or alternative.                                

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.                 

Deliverable 5:          Final Report


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


            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.


Presentation 1:       Project Definition 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.


Presentation 2:       Proposed Solution Walkthrough


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:

  1. Data model: Relational schema or other appropriate data schema with complete metadata.
  2. Process model : Narrative of how the system operates, graphic model (program structure chart, Page Navigation Map, or similar diagram) consistent with the narrative, complete metadata of all elements of the graphic model.
  3. I/O screen/report layouts
  4. Module code or pseudo code for all modules consistent with the process model.


Option B:  Purchase or Outsource. When a team pursues a purchase or outsource solution, the documents that the team brings to the walkthrough include:  

  1. Data model: Proposed system ERD in third normal form with complete metadata.
  2. Process models : Narrative of how the proposed system will operate, graphic model (DFD, Page Navigation Map, OOD diagrams or similar) consistent with the narrative and complete metadata of all elements of the graphic model.
  3. Completed RFP.
  4. Potential packages/vendors and a discussion of each.
  5. A demonstration of how the team collected data, evaluated proposals and made a recommendation using the guidelines in the RFP.

Presentation 3:       Final Presentation


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.