Simon Fraser University
Project Definition Document
LIDC Management Information System^
Project Definition Document
Preamble^
LIDC presently has a number of systems used for project management and staff management. Management information tasks are presently handled either online, paper based, or verbally. LIDC has a number of different departments spread across three campuses, each of which handle management tasks in their own way. Staff are often assigned projects outside of their own group, which leads to confusion and conflict between different management systems. With multiple systems, it is difficult to get the "big picture" of LIDC: how projects are progressing and how much time staff work on each project.
The goal of the MIS project is to provide a system to centralize project and staff management. Such a system would handle data entry and reporting of:
- Project Management: generate reports for each project, detailing project details, work orders, team members, staff workload, timelines and milestones, progress and completion, and internal documentation and reporting.
- Staff Management: report on the workload and project assignments for each staff member
There should be a variety of reports, from a quick overview to high level detail for a variety of audiences, from LIDC director to staff member, the SFU community and the outside world, with care taken to present information in a manner tailored to each audience.
Management systems generally fail because they make more work than already exists. The system must be easy to use and not add to (and preferably decrease) the management burden on staff. Data should be easy to enter online and no staff member should require more than 30 minutes a week to enter requisite data into the system.
It is also important that the system be secure, and that access controls are in place to protect the privacy of staff.
Project Plan^
The implementation of this project will be broken up into several stages:
- Requirements Analysis - 4 weeks (December 4th - January 5th?)
- Design and Documentation - 3 weeks - (January 9nd - January 26th?)
- Implementation - 3 weeks - (January 29th - February 16th?)
- Testing - 2 weeks - (February 19th - March 2nd)
- Deployment (March 2nd?)
At each stage of this project, a report will be made and reviewed by management before proceeding to the next stage. It may also be desirable to present a report to the staff in general to ensure their vision for the system has not been left out at any stage.
These dates are tentative and are dependent on the scope dictated by Requirements Analysis and any delays resulting from the peer review process.
Trevor Bradley will be the project lead and be responsible for project management and all stages of documentation and implementation. Assistance will be required for: Requirements Analysis (interviews), Look and Feel (media design?), Testing, and from Dennis Humphrey and John Moore for stage completion peer review.
Requirements Analysis^
This project holds a difficult challenge: No-one really knows what is required. With different expectations from different departments within LIDC, it is critical that project scope be determined at an early stage. Decisions need to be made that may affect the workflow of the different groups and it is important that the staff and project management needs be determined before Design and Implementation begin.
To ensure that everyone's needs are satisfied, a series of interviews with LIDC staff will be held. To ensure that the variety of opinions and needs are covered by the project scope, the director, associate directors and each departmental manager should be interviewed. Additionally, it may be advantageous to have departmental staff members to be interviewed as well, either with their manager or in separate interviews (How the manager sees project workflow and staff management may not actually be the way things are done). Additionally, staff need to actually use the system, and they won't if they don't have a say in its design. Ideally one staff member from each department could be interviewed.
During these interviews, questions will be asked about project workflow and staff management. Existing workflows will be reviewed. Online systems, verbal and paper based workflow mechanisms will be studied and documented.
Examples of questions posed to staff:
- How do you record what projects your staff are working on?
- How do you manage your staff vacation time and sick leave?
- What kind of project reporting do you need to get your work done?
- How much information do you need to know about projects you don't manage/aren't working on?
- What do you feel is missing from your existing project management system?
- What would simplify the process of staff management (vacation requests, sick leave. conference requests, etc)
- What should various audiences (staff, managers, directors, SFU, public) know about the projects you're working on.
- What information should be stored in such a system that should only be seen by a restricted audience (e.g. project problems, deadline slipping, etc)
Questions wont be static will be refined after each interview.
The end result of this process will be a document detailing existing workflow, staff and management needs, as well as a "best fit" of core features that should go into a new management information system. Those features not implemented will be cataloged for possible future implementation.
We will then review this document to verify that the scope of the project is both adequate and manageable. It may be worthwhile to have a wider audience review the project at this point to ensure that information gathered in the interview process is accurate. If so, I will prepare a PowerPoint presentation for interested members of LIDC.
Resources Required: Time from directors, managers and staff for interviews and perhaps a final presentation. Interviews might be sparse in the first half of December and most of Trevor's time will be taken up near the end of this stage to determine the scope of the project and generate reports.
Design and Documentation^
Once the scope of the project has been approved by the peer review process, the Design stage will begin. In this stage:
- A preliminary "Look and Feel" (themes, colours and positioning of elements) of the site will be determined and implemented using CSS. This will dictate elements of page UI design.
- A non-functional UI mockup (forms, buttons, and navigation) of the site will be created using static HTML files.
- The development platform (i.e. Solaris/Linux/Windows, Java/PHP, Apache/Tomcat, mySQL/MS-SQL) will be chosen. NOTE: Trevor has an existing body of code for ESI's Resource Allocation tool developed in Solaris+Java+Tomcat+mySQL. It's his preference to develop a system of this complexity using this platform, but other options will be given fair consideration.
- Stubs for the site modules will be created, but no code will be implemented. A CVS code repository will be created.
- A database design will be determined and a report generated.
- Preliminary documentation. I would like to embed the user documentation into the site itself, so it make sense to develop it alongside the UI mockups.
Care will be taken to allow room for future expansion. Design decisions should allow for future system expansion (particularly those features determined during Requirements Analysis but were not brought forward to the Design phase)
Once these documents are prepared will have another round of peer review. The staff may be interested in the UI mockups to get a sense of what's coming.
Resources Required: Assistance will be required during the UI design stage. Trevor will be working at full capacity on UI mockup, design and documentation.
Implementation^
Design is complete and implementation can begin. This phase should take three weeks. Design goes much faster if the scope of the project has been clarified, and hopefully the Requirements Analysis and Design phases should make implementation go smoothly.
Implementation frequently brings out issues that were not covered in the Design phase. Revisions to Look and Feel User Interface, Database Design, Documentation are a possibility.
Extra care will be taken to thoroughly document the code in case future revision is required. If implemented in Java (possibly PHP?), an API will be generated describing the functions of classes and methods.
Initial population of the database will be done at this time: Users, existing projects, holiday dates and other important information will be seeded into the system.
Again, once this phase is complete, we'll review the results before unleashing the site on the testers.
Resources Required: Trevor will be working at full capacity on implementation.
Testing^
Once the site appears to be functional, we will need a group of testers to review functionality. Ideally we will need clients interviewed in the Requirements Analysis phase to test the systems they requested to be implemented. We may also try to recruit early adopters who wish to try out the system early, though warning them that the system is being tested and data may be lost..
Stability of this system during testing will not be guaranteed, as the website will be taken offline for any required code modification.
It may be desirable to wipe the project testing data before deployment. We should take care to check with the users to determine what data may be important and what should be deleted.
Testing should take two weeks. If the results of the testing are good, we'll move to Deployment.
Resources Required: Testers will need to be recruited. Trevor will need to take feedback from testers and implement fixes, but if previous stages have gone well, bug fixing won't take up all of his time.
Deployment^
Once the system has been tested, it will need to be deployed permanently. A final URL will be chosen for the site. The site will be expected to be online 24/7 and monitored by support staff using Intermapper.
Once the site is online and functional, we may want to look at a subsequent revision and implementation of new features. Such a review is outside the scope of this project.
Resources Required: Ongoing support staff.
Preamble^
LIDC presently has a number of systems used for project management and staff management. Management information tasks are presently handled either online, paper based, or verbally. LIDC has a number of different departments spread across three campuses, each of which handle management tasks in their own way. Staff are often assigned projects outside of their own group, which leads to confusion and conflict between different management systems. With multiple systems, it is difficult to get the "big picture" of LIDC: how projects are progressing and how much time staff work on each project.
The goal of the MIS project is to provide a system to centralize project and staff management. Such a system would handle data entry and reporting of:
- Project Management: generate reports for each project, detailing project details, work orders, team members, staff workload, timelines and milestones, progress and completion, and internal documentation and reporting.
- Staff Management: report on the workload and project assignments for each staff member
There should be a variety of reports, from a quick overview to high level detail for a variety of audiences, from LIDC director to staff member, the SFU community and the outside world, with care taken to present information in a manner tailored to each audience.
Management systems generally fail because they make more work than already exists. The system must be easy to use and not add to (and preferably decrease) the management burden on staff. Data should be easy to enter online and no staff member should require more than 30 minutes a week to enter requisite data into the system.
It is also important that the system be secure, and that access controls are in place to protect the privacy of staff.
Project Plan^
The implementation of this project will be broken up into several stages:
- Requirements Analysis - 4 weeks (December 4th - January 5th?)
- Design and Documentation - 3 weeks - (January 9nd - January 26th?)
- Implementation - 3 weeks - (January 29th - February 16th?)
- Testing - 2 weeks - (February 19th - March 2nd)
- Deployment (March 2nd?)
At each stage of this project, a report will be made and reviewed by management before proceeding to the next stage. It may also be desirable to present a report to the staff in general to ensure their vision for the system has not been left out at any stage.
These dates are tentative and are dependent on the scope dictated by Requirements Analysis and any delays resulting from the peer review process.
Trevor Bradley will be the project lead and be responsible for project management and all stages of documentation and implementation. Assistance will be required for: Requirements Analysis (interviews), Look and Feel (media design?), Testing, and from Dennis Humphrey and John Moore for stage completion peer review.
Requirements Analysis^
This project holds a difficult challenge: No-one really knows what is required. With different expectations from different departments within LIDC, it is critical that project scope be determined at an early stage. Decisions need to be made that may affect the workflow of the different groups and it is important that the staff and project management needs be determined before Design and Implementation begin.
To ensure that everyone's needs are satisfied, a series of interviews with LIDC staff will be held. To ensure that the variety of opinions and needs are covered by the project scope, the director, associate directors and each departmental manager should be interviewed. Additionally, it may be advantageous to have departmental staff members to be interviewed as well, either with their manager or in separate interviews (How the manager sees project workflow and staff management may not actually be the way things are done). Additionally, staff need to actually use the system, and they won't if they don't have a say in its design. Ideally one staff member from each department could be interviewed.
During these interviews, questions will be asked about project workflow and staff management. Existing workflows will be reviewed. Online systems, verbal and paper based workflow mechanisms will be studied and documented.
Examples of questions posed to staff:
- How do you record what projects your staff are working on?
- How do you manage your staff vacation time and sick leave?
- What kind of project reporting do you need to get your work done?
- How much information do you need to know about projects you don't manage/aren't working on?
- What do you feel is missing from your existing project management system?
- What would simplify the process of staff management (vacation requests, sick leave. conference requests, etc)
- What should various audiences (staff, managers, directors, SFU, public) know about the projects you're working on.
- What information should be stored in such a system that should only be seen by a restricted audience (e.g. project problems, deadline slipping, etc)
Questions wont be static will be refined after each interview.
The end result of this process will be a document detailing existing workflow, staff and management needs, as well as a "best fit" of core features that should go into a new management information system. Those features not implemented will be cataloged for possible future implementation.
We will then review this document to verify that the scope of the project is both adequate and manageable. It may be worthwhile to have a wider audience review the project at this point to ensure that information gathered in the interview process is accurate. If so, I will prepare a PowerPoint presentation for interested members of LIDC.
Resources Required: Time from directors, managers and staff for interviews and perhaps a final presentation. Interviews might be sparse in the first half of December and most of Trevor's time will be taken up near the end of this stage to determine the scope of the project and generate reports.
Design and Documentation^
Once the scope of the project has been approved by the peer review process, the Design stage will begin. In this stage:
- A preliminary "Look and Feel" (themes, colours and positioning of elements) of the site will be determined and implemented using CSS. This will dictate elements of page UI design.
- A non-functional UI mockup (forms, buttons, and navigation) of the site will be created using static HTML files.
- The development platform (i.e. Solaris/Linux/Windows, Java/PHP, Apache/Tomcat, mySQL/MS-SQL) will be chosen. NOTE: Trevor has an existing body of code for ESI's Resource Allocation tool developed in Solaris+Java+Tomcat+mySQL. It's his preference to develop a system of this complexity using this platform, but other options will be given fair consideration.
- Stubs for the site modules will be created, but no code will be implemented. A CVS code repository will be created.
- A database design will be determined and a report generated.
- Preliminary documentation. I would like to embed the user documentation into the site itself, so it make sense to develop it alongside the UI mockups.
Care will be taken to allow room for future expansion. Design decisions should allow for future system expansion (particularly those features determined during Requirements Analysis but were not brought forward to the Design phase)
Once these documents are prepared will have another round of peer review. The staff may be interested in the UI mockups to get a sense of what's coming.
Resources Required: Assistance will be required during the UI design stage. Trevor will be working at full capacity on UI mockup, design and documentation.
Implementation^
Design is complete and implementation can begin. This phase should take three weeks. Design goes much faster if the scope of the project has been clarified, and hopefully the Requirements Analysis and Design phases should make implementation go smoothly.
Implementation frequently brings out issues that were not covered in the Design phase. Revisions to Look and Feel User Interface, Database Design, Documentation are a possibility.
Extra care will be taken to thoroughly document the code in case future revision is required. If implemented in Java (possibly PHP?), an API will be generated describing the functions of classes and methods.
Initial population of the database will be done at this time: Users, existing projects, holiday dates and other important information will be seeded into the system.
Again, once this phase is complete, we'll review the results before unleashing the site on the testers.
Resources Required: Trevor will be working at full capacity on implementation.
Testing^
Once the site appears to be functional, we will need a group of testers to review functionality. Ideally we will need clients interviewed in the Requirements Analysis phase to test the systems they requested to be implemented. We may also try to recruit early adopters who wish to try out the system early, though warning them that the system is being tested and data may be lost..
Stability of this system during testing will not be guaranteed, as the website will be taken offline for any required code modification.
It may be desirable to wipe the project testing data before deployment. We should take care to check with the users to determine what data may be important and what should be deleted.
Testing should take two weeks. If the results of the testing are good, we'll move to Deployment.
Resources Required: Testers will need to be recruited. Trevor will need to take feedback from testers and implement fixes, but if previous stages have gone well, bug fixing won't take up all of his time.
Deployment^
Once the system has been tested, it will need to be deployed permanently. A final URL will be chosen for the site. The site will be expected to be online 24/7 and monitored by support staff using Intermapper.
Once the site is online and functional, we may want to look at a subsequent revision and implementation of new features. Such a review is outside the scope of this project.
Resources Required: Ongoing support staff.
There are no comments on this page. [Add comment]