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.