Sample Outline for Team Project Specifications

Team Project
INLS 582_003, Systems Analysis

The final specifications should document your findings, recommendations, and justifications for your entire project. Excluding the final "Team Appendix", its two main audiences are your client and me, but you may also wish to include it (with permission of your team members), in the portfolio of your work that you might show to potential employers.

The Team Appendix is for internal use only. In addition to the required presentation plans and lessons learned, it should include any information you would like me to know about your project, but that will not be shared with your client.

The specifications should be written in a straight-forward, business or technical style. Tables and figures should be numbered, and explained in the text. Proofread your work for clarity, completeness, accuracy, grammar, and spelling. This document reflects the quality of your work.

Specifications should be submitted as a single file (.doc, .docx, .pdf), not as a collection of individual files. You may include links to a prototype (e.g., web page) if desired. If there are other materials you'd like to include that don't fit gracefully into the .pdf file, please discuss presentation options with me at least 2 weeks prior to the due date.

The following outline is an example of how you might organize your final specifications. The content it described is likely to apply to any project, but you may organize it differently. Your goal is to create a clear, professional proposal that will be helpful to your client.
1. Title Page
Project name, author(s), date.
2. Table of Contents
A list of report sections.
3. Executive Summary (required)
A summary of the entire report, not to exceed 2 pages. This section should give a general overview of the entire proposal, without providing specific details. An upper-level manager might read this section just to get an idea of what you've done. A client who will be responsible for implementing your proposal might read this to get a quick orientation before diving into the details of your proposal, or may skip this section entirely. Remember that this is a summary; you will be repeating information from your full proposal. There should not be information given in this section that does not appear in the rest of the proposal, except for material in the Team Appendix. The summary should include:
Brief description of old system and problem(s).
Brief description of method of investigation and design.
Recommendations: description of new system, in terms of the changes it introduces, and anticipated benefits. (How it will solve problem.)
4. Description of Current System
This section presents your team's findings concerning the current system and system environment (organizational, technical, etc.), the problem and symptoms, and needs and requirements. It presents your team's perspective, which may not necessarily be the same as the client's view. For example, it may seem obvious to you that a high turnover rate contributes to the problem, but the client may not have considered it, and may not even realize how high the turnover rate is. In other words, this is your opportunity to frame the problem. The description should include:
Brief narrative description.
Representation of current system, using/integrating models and techniques discussed in class. Choice of specific models depends on type of system and problems or issues that you wish to highlight.
5. Recommendations for New System
In addition to laying out your recommendations, you should also describe how you developed the ideas (e.g., standards guidelines, product surveys, interviews), and justify each recommendation. If you provide a choice of proposals (for example, a bare-bones version and a deluxe version), lay out the advantages and disadvantages of each. If there are parts of the problem that your proposed system does not solve, explain what will remain, and why. The recommendations should include:
Narrative summary of changes introduced in new system.
Model of proposed system, using/integrating models and techniques discussed in class. This should provide a complete and specific description of the proposed system. Choice of specific models depends on type of system and features you wish to highlight, or that require detailed specification.
6. Implementation Plan for New System (required content)
This section should lay out what is required to implement your recommendations, and should provide sufficient information for a manager to decide if this is a feasible idea, and if so, where to prioritize it in relation to other projects. It should describe the activities needed for implementation, along with estimates of the time, people, equipment and costs required. This might be where a manager would turn next, after reading the Executive Summary, to see if the implementation plan is at all feasible for the organization.
7. Client Appendix
Use this optional section for reference materials, coding or technical details, or other information that is not likely to be of immediate interest to your client. Examples include a glossary of terms, detailed product specifications, or a script for data cleaning.
8. Team Appendix (required)
The previous sections should be appropriate for your client's use. This required section, in contrast, is specifically for our use as part of the class experience. It should demonstrate work you did that is not included in the client's sections, as well as your thoughts and reflections on the project and the systems analysis experience. This appendix should include:
Any models the team used for internal purposes. These might include strong competing models for which you still see some advantages, or cultural models that helped you understand the client better.
Any lingering issues or concerns you have about your proposed system.
REQUIRED Your plans for presenting your proposal to the client.
REQUIRED Lessons learned. As a team, how do you assess your team's performance and results? What were your strengths and weaknesses?  What would you do differently if you had it to do over again? What lessons can you carry with you for the next project? You should reflect both on the specific project, and on what you've learned about systems analysis in general.

This page was last modified on July 17, 2012, by Stephanie W. Haas. Address questions and comments about this page to Stephanie W. Haas: shaas at email dot unc dot edu
© Stephanie W. Haas All rights reserved.