Team Project Manager (TPM)
LCO Analysis
Omar Ghishan
Brian Harris
In this paper we present our LCO analysis for our project proposal, a Team Project Manager (TPM). We envision a web based tool that will help team members make informed proposals for meeting times and project features. We will give an overview of how our system would be used, how it will be different from existing project managers, the necessary technology to create it, the timeline for developing and supporting it, and its overall feasibility.
The idea is to have an online project management tool which allows group membersto suggest project features they would like to see, and to find common availabilitiesin their schedules to assist in meeting time proposals. Each group member submits their personal schedule of unavailability (Figure 1), and a group schedule is generated by ranking the merged availabilities of group members during different time periods (Figure 2). This group schedule is interactive, and meeting proposals can be created through it.
Both meeting and project feature proposals are supported by a voting system. Acceptance of a proposal is determined by specific acceptance criteria that can be set, including the number of team members required to agree, specific team members that have to agree, or both. Emails are generated and sent out when proposals are created, consensus is reached, and before meetings or deadlines as reminders.
The products we have found which offer similar tools are either unintuitive to use because of unnecessary complication, hard to obtain because of prohibitively expensive costs, or in the common case both. Demonstration of how to use the TPM should take a maximum of ten minutes and could be carried out live during class time, and the entire system would be free to university students.
A few things the TPM is not: a wiki, a blog, a code concurrency utility, or a mailing list. In addition, this product does not aim to be the centerpiece of a project; it is meant to be used as a helpful tool alongside a project by increasing efficiency and reducing difficulty of communicating with teammates.
In order to develop and support a TPM, some essential system features exist. These include a database to store group information, schedules, and preferences, a web browser capable of displaying .asp files for the visual calendar, a scheduling algorithm for finding common availabilities, and possibly UWnetID login based authentication support and access to student’s class schedules. A set of technologies to develop this product include Microsoft SQL Server, Microsoft Visual Studio (ASP.NET, C#, Web Developer, Team Suite) (Figure 3).
The TPM is created with university students and instructors in mind and would be useful for teams of any size. It would be developed during Spring quarter of 2006 by a professor-selected number of CSE403 students, and would be supported by technologies provided by the UWCSE department. Upon completion of the quarter, anyone or any department wishing to continue supporting and using it will be able to reference a how-to guide describing installation and maintenance on their own system. In addition, any developers wishing to continue improving, optimizing, or extending the TPM are welcome to obtain the source and release new versions asthey see fit. However, the original release at the end of its initial development will also be made available for users wishing to opt-out of additional extensions.
This product will be made specifically for UW, in that the authentication system and class schedule integration will be specific to UW’s system. In the case that a different university wanted to integrate the TPM in their system, they would be require to alter the authentication and scheduling parts of the code themselves.
The feasibility of this project is great. Completion of the core system would only take about four to five weeks, leaving a lot of time to test the system, increase ease-of-use and add features such as group management and feature tracking. We know that implementation is possible because of the technologies we have access to, however if we find that it’s not possible to interface with UW’s UWnetID authentication system, development time will increase to build our own.
Risks for this project that we have identified are as follows. Inability to access UW’s UWnetID authentication system; this will probably add an additional half week to development time. It can be managed by identifying early on whether or not we can use it. Inability to gain access to student’s class schedule data; this will require team members to manually enter their class times as not available into their schedules. We can offset the inconvenience this provides by making sure the availability schedule is easy to use. Development of a non user-friendly interface; since our goal with this project is increasing the ease of communication between team members, if our UI doesn’t prove effective, teams will opt-out of using it. Feature creep; trying to add too much functionality at once could lead to a big, useless, half-completed mess. A solution to this can be to take advantage of the staged delivery method and have shippable releases every one and a half to two weeks.
Figure 1: An interactive personal unavailability schedule.
Figure 2: An interactive group schedule of availabilities
Figure 3: TPM system architecture