THE WALLACE E. CARROLL SCHOOL OF MANAGEMENT
MD 240: Management Information Systems
Fall 2001
MD240 Home
Syllabus/Schedule
Guidelines/Grading
Notes/Slides
Study Guides
Quizzes
Technology Project
Consulting Project
Useful Links
MD 240
Group Consulting Project
Your Project Team:
You will be asked to form groups of approximately 5 students each. While the natural tendency when doing so is to pick a group made up of your friends, or to pick those sitting closest to you in class, these approaches may or may not work well, depending upon the makeup of your team.
You may want to make sure that your group has a mixture of people with tendencies toward project management ("Team Project Manager"), concept development and brainstorming ("Concept People"), documentation ("Document Managers"), and abilities to envision how to choose and adapt technologies to create systems ("Techie Types"). One person MUST volunteer or be chosen to serve as the Project Manager (projects without a leader always seem to lag behind significantly).
Your Client Organization:
Your group will pick a client who has a problem that you believe could be solved using IT. This must be a real organization with a real problem. I will allow you to choose from among the following three options:
(I) Boston College - Carroll School
This is in some ways easier in that it is local, but hard in that it means that all of the people you would need to talk with are right here, so the quality of your project must be a bit higher. Also, it is very obvious what IT resources are here right now and which are not. However, it is very unclear as to what are the strategic IT resources that a business school should have to create a competitive advantage for itself. So, choosing the Carroll School means that you have to apply some "vision" and "dream" about what the school might need to improve the IT services it provides to students and faculty in a way that allows some improvement in business school rankings.
If you choose to use the Carroll School to examine the SDLC, you will have to do the following:
1 - Briefly characterize the current IT architecture.
2 - Describe the "ideal" IT architecture (using a pictorial representation of the layout of its components) for a set of "strategic objectives" identified by your team for the Carroll School, that will lead the Carroll School into a top competitive position relative to other business schools.
3 - Pick a single IT service or system [i.e., this cannot just be something really simple like "we need to buy software package ABC" ... before doing any work on it, verify with me that your idea is okay] that your team (as the end users) feel the Carroll School should have available for students, and follow through the SDLC, as described below.
(II) Boston College - Student Organizations/Services
The BC student community itself can provide interesting consulting opportunities. I suggest you contact either this year's or next year's student government, as they may be able to identify for you the IT services that would be helpful to the BC student body.
NOTE: Projects performed by previous semesters' teams, WHICH YOU MAY NOT USE AS YOUR PROJECT, are as follows:
(a) Student government online/WWW voting system
Add last semester's projects
(III) Greater Community
(1) Perhaps a relative or friend of a team member works for a company that would allow you access.
(2) It could be an organization for which someone on your team has worked.
(3) You might pick an organization someone has a current or past non-work related affiliation with (e.g., a school, community group, or non-profit organization).
(4) You might want to contact people in organizations you have an interest in working for.
(5) You might want to contact recent graduates who are working in MIS.
(6) You might pick an organization based on your experience as a consumer.
The Client Problem:
Your problem should be complex enough to be a good learning experience, but you should not pick a problem that is so complex that you end up doing a superficial job.
Try to pick a problem that all of the members of your team can get excited about. Research shows that design project teams are often much more effective when everyone in the team is "On Board", or has been picked because they really want to work on the project. Because you must work on a project, it becomes important to choose something that each member of the team will have a great interest in doing.
I will be available to help you with your project process, project politics, ideas for leads, ideas for your presentation, and so on. If you need help finding a client organization, please let me know. As the semester will go by very quickly, it is in your interest to find a client as early as possible.
Goal:
The goal of this project is for you to experience first-hand the elements of the Software/Systems Development Life Cycle (SDLC) process by actually working through several of the SDLC stages, documenting the system you design, and then communicating your results with a presentation and write-up. During the project, you will follow the steps of the SDLC as described on pages 603-610 of the text. The components of the project are as follows:
(1) Project Initiation: You will provide a high level overview of the concept or vision for the new system (a Vision Statement), including a problem statement and a description of the goals of the new system.
(2) Systems Analysis and Feasibility Studies: You will analyze and identify the present IT architecture. You will then provide a description of how the present IT architecture may need to be modified, how current systems will be affected, and a discussion of costs versus benefits of the old and new systems. You also will analyze the feasibility of the envisioned system.
(3) Logical Analysis and Design: You will analyze and model the current system and the proposed system on a logical level. This should be done using tools and approaches that will be understandable by your classmates during your presentation, as well as by your clients. Usually, pictorial diagrams and/or flowchart diagrams are the best way to map out the architecture of and processes within such systems. If your system will need to store data or incorporate a database, you should identify what the data are that will be required by the system, either through a table of data attributes -- or even better -- through an entity-relationship diagram.
(4) Acquisition or Development: You will describe your technical solution. You must specify the exact technology your are suggesting to use in the system (i.e., brand name, product name, etc.). If alternative technology choices are available, you must present (e.g., via a simple illustrative table that compares technology attributes side-by-side) the simple comparative analysis you went through -- and the variables (e.g., price, features, etc.) used -- to choose between the technology options. Once again, you should display a pictorial model of how the chosen components fit together. A prototype of part or all of the proposed system can be nice here, but is not required. You should also create a list of documents that will need to be created to enable documentation and training with the system.
(5) Implementation, (6) Operation, (7) Post-Audit Evaluation, and (8) Maintenance: Since you will not actually build the system, you will just provide a recommended plan for how the organization should accomplish these steps. These steps will have less emphasis placed on them, but nevertheless should be analyzed and communicated in reasonable depth..
Some Examples:
Here are some examples of documents and personal experiences of friends of mine who are or have been systems developers that might help you get a better idea of what you might end up doing during the SDLC.
Example #1: A request for a proposal for an actual MIS engagement (edited for confidentiality) similar to what you'll be doing
Example #2: A response to a Request For Proposal (RFP)
Experience #1 - Designer/Concept Person/Program Coder
Experience #2 - Systems Maintenance
Experience #3 - System Developer Experience Reports
Experience #4 - End-User Experience Reports
The Project Process:
(1) Brainstorm on potential organizations for your project. Prioritize the ideas and pursue leads. Call me if you need some leads. You must delegate one person to be the project manager. You may want to designate another person to be in charge of controlling any documents produced during the project.
(2) Arrange for an interview with a contact person in the organization. Managers are often quite busy, so it may take a while to get an appointment set up. Start early and be persistent. Once the interview is scheduled, make sure that you are prepared for the interview with questions you may have about the organization's needs, their objectives, their desired budget, etc. Do not go in unprepared and waste the manager's time. Assign one person to record or take notes of the meeting.
(3) Prepare and submit a Vision Statement and Project Plan to me.
(4) At this point, you will be sequentially working on the stages of the SDLC.
(5) During subsequent meetings with your contact, present your work in progress, ask your contact to comment on whether your plans are "on the right track," take notes, and ask for copies of documents or pictures you are shown. (In some cases, you may be asked to sign confidentiality statements. Please talk to me about this if it arises.) Before you leave a meeting, ask if you can phone back later with any follow-up questions.
(6) Work on your write-up and prepare your presentation. Often this will involve picking and choosing between the materials you have created and gathered during your project. Call your contact to check facts and figures, and to clear up loose ends. Rehearse your presentation and proofread your report.
(7) Turn in your write-up, and deliver your presentation to the class.
(8) Download the team evaluation form and fill it out.
(9) When you finish the project, you will probably be asked to send a finalized copy of your report to the contact at your client organization. Send a copy of the report, as well as a thank you note.
Project Roles:
Teams often include a variety of individuals who take on different roles in the teams. Your team should decide who will take on what roles, and which roles are needed for the project.
(1) Team Leader/Project Manager: This person is responsible for coordinating team members and creating and updating the project plan.
(2) Concept People/Systems Analysis/Systems Design: Certain people may concentrate on the more abstract tasks involved in analyzing and modeling the envisioned system on paper.
(3) Document Management: Knowledge work often involves the creation of many documents, and the dissemination of those documents to team members. This role often includes document control, in which one must make sure that documents are archived as they are created, and that two individuals are not editing the same document at the same time, thereby potentially corrupting the other's work.
(4) Implementation People: These people often have some experience in the actual creation of systems. People who have worked on programming -- or are at ease with making technology choices for their own home computer systems -- may be more open to these roles. These people often have to help the Concept People understand the nuts and bolts of how IT actually works together, and not just the vision of how it might work.
Managing Your Project's Timeline:
An ideal schedule for the group project is as follows:
(1) In the next couple of weeks, select a client for your project and interview your client to find out the nature of the business, the kinds of problems the organization faces, and possible IT remedies;
(2) By Easter break, define the particular problem you will address, research possible IT solutions, and present options to the client to get feedback;
(3) Reserve the remainder of the semester for finalizing your proposed solution, and developing your write up and presentation.
Your team may want to use some sort of project management software to help with controlling this project (and to experience such software).
Deliverables:
The timeline of deliverables for this project is as follows:
(1) a vision statement and project plan (DUE DATE: October 15, 2001)
(2) a write-up of the project (DUE DATE: Second day of presentations)
(3) a presentation of your findings to the class (DUE DATE: Day your team is assigned to present)
(4) a team evaluation form for reviewing the performance of your fellow team members (DUE DATE: Second day of presentations).
The Vision Statement and Project Plan:
Vision statements help to describe the general concept of the IS project and what strategic value the project has to the organization. Your project plan should briefly outline the steps that you plan to take during the semester in order to complete the project. The project plan may include a timeline of the project or a simple Gantt chart that can help visualize the order of the steps. While a vision statement and project plan can often end up being 50-100 pages in a corporate project, this report need not be more than a page or two. Your project plan should also include a list of your team members, and the roles they will play in the team. (DUE DATE: October 15, 2001)
The Write-Up:
The write-up for your project will consist of eight sections, one for each stage of the SDLC, as described above. Your full write-up should be around 20 pages of double-spaced text (easier for my old eyes to read), although you can attach diagrams on additional pages. Typically, the first four sections will be longer than the last four. If you have drafts ready early, I will be happy to comment on them and give feedback on whether they include what I want. (DUE DATE: Second day of presentations)
The Presentation:
Your group will present your findings in a 15 minute in-class presentation, to be followed by a 5 minute question and answer period. In the presentation you will cover the same five topics as the write-up, although here again, it is not necessary (or even recommended) to devote equal time to each stage. It is better to devote more time to the most important and interesting elements of your project.
It is critical that the presentation be well designed and rehearsed for length. A common problem with team project presentations is that teams try to say too much, and/or are not well rehearsed for what they do say. The best solution to this is to time your presentation during several practice runs. This practice helps you cut out extraneous material, and decide on what material is most interesting, informative, and relevant to telling the "story" of your project. (DUE DATE: Day your team is assigned to present)
Team Evaluation Form:
At the end of the semester you will be asked to evaluate the contribution of the other members of your group, and using that evaluation and my own observation, certain group members may have their grades for the group project adjusted. (DUE DATE: Second day of presentations)