DELIVABLE F
March 04, 1999
Project Team:
Sophia Clay
Kamran Hussain
Adam Oxer
Julio Salazar
TABLE OF CONTENTS
EXECUTIVE SUMMARY
RECOMMENDATIONS.
APENDICES
Executive Summary
Zurich Kemper Life has used the PeopleSoft Financial Modules for the past two years to manage the financial operations of the company. The software maintains the General Ledger and Accounts Payable functions for financial reporting and generates checks as well. As the financial modules have gained acceptance, requests to create and modify software have increased. Until this point, the technical support staff informally took requests in-person, by phone or e-mail. But Management in both the Information Technology and Financial Operations departments has asked our team to standardize this process by implementing a tracking system to handle the requests efficiency.
The new tracking system needs to address the following issues:
Eliminating in-person and telephone request, deferring to email and/or Lotus Notes requests instead.
Logging each request so users and Management can view the progress of the work.
Prioritizing each request as it is made.
Documenting changes make to each request to reduce miscommunication.
Through interviews with the decision-makers in the Information Technology and Financial Operations departments, our team has collected the data needed to develop a new information system to manage these issues. Using the FAST Methodology, we have analyzed the data and processes of this system. Our report details our findings and recommendation to continue into the development phase of this project. With existing Lotus Notes database technology, the software will be a feasible and efficient alternative to the present chaos
There is a urgent need to automate the ‘support request logging, tracking and resolution system’. This will ensure that there is a priority assigned to each task. The users will be aware of all the other on-going projects. The IT management will be able to track the time of their staff. The resolutions will also be documented for future reference.
The PeopleSoft Financial System is utilized by the Financial Operations department. The CFO is the sponsor for all the production support of the system. The PeopleSoft functional support contacts will handle each task before it is reported to the technical team.
Sophia Clay - Project Leader
Kamran Hussain – Client Contact
Adam Oxer - Data Modeler
Julio Salazar - Process Modeler
All team members will take turns to be the Editor of the Deliverables.
Methodology
The team will utilize the "FAST" methodology.
Communication
The team will communicate by email, meetings after class, once-a-week off-site team meeting, and if necessary conference call. Kamran Hussain, the client-contact person will communicate with the client.
Software (Standards)
The following software will be used by the team: Visio Professional, MS Project 98, MS Excel 97, MS Word 97, MS PowerPoint 97
In order to initialize the priority and the application, the technical lead has to setup all the applications that are used in relation to the PeopleSoft system, and all the priority types. Once the application and the priority have been setup, there may also be a need to add a priority, or add or delete an application.
A requestor can make or close a request. The requestor will access the system and fill out the online form to make a request, and then submit it. If the requestor determines that the request for support is no longer needed, the requestor can also cancel the request. Once the request has been submitted, the SupportP1 system will send an email to the requestor as the confirmation for the submission of the request, and also one to the technical lead as a notification for the new request.
The technical lead will then access the SupportP1 system to look at the details of the request. If the technical lead is not able to address the request him/herself, then the technical lead will assign the request to a technical resource through the SupportP1 system. This will trigger the system to send out a notification email to the technical lead as a reference and also one to the technical resource as a notification of a new request. Once the technical resource receives the notification email, he/she will access the SupportP1 system, and get the details of the request. When the work has been completed on the request, the technical resource will access the SupportP1 system, and close the request. Closing the request will send out a notification email to the requestor and the technical lead.
Process Modeling is a technique for organizing and documenting the structure and flow of data through a system’s processes and or logic, policies and procedures to be implemented by a system’s processes. This diagram will show the flow of data from the requestor in the system. Once the request is received it will get assigned and finally closed when the work has been completed. The process model helps clarify and detail all the processes that will take place in this system.
Make a Request Every user that experiences any kind of problem that prevents him/her for doing his/her job, can make a request to the IT Department to ask for help in fixing his/her problem in order that she/he can continue working.
Close Request. The notification to the user and to the system that the problem has been resolved. This update is made for the person who worked in this specific issue.
Assign Request. This is the process when the Technical Lead actually assigns a request to the people who are supporting the system; even though he can assign that request to himself.
Initialize and Maintain the ApplicationTable. The Application table needs to be set up with the appropriate data in order that it can be utilized when a user is making a request. The IT department can update this information.
Initialize and Maintain the Priority Table. The Priority table needs to be set up with the appropriate data in order that it can be utilized when a user is making a request in determining the order that the problem is going to be solved. The IT department can update this information.
One or many request may be initiated for enhancements or modifications to an application in the PeopleSoft Financial System. If one or many request exist, it is mandatory that the request is for an application in the PeopleSoft Financial System.
An application in the PeopleSoft Financial System may have one, or many request for enhancements or modifications.
An employee, in a Functional Support Position in the Financial Operation’s Department or an employee in a Technical Support position, in the Information Technology Department, may be assigned to work on one, or many request.
If one or many request exist, it is mandatory each request is assigned (by an employee, who is an Information Technology Department Manager or by any employee who is a Functional Support contact in the Financial Operations Department) to an employee in a Functional Support Position or Technical Support Position.
An Employee who is a user of the PeopleSoft Financial System or an employee in a Functional Support Positions (in the Financial Operations Department) may initiate one or more request.
If one or many request exist, it is mandatory each request is initiated by an employee who is a user of the PeopleSoft Financial System or an employee in a Functional Support position in the Financial Operations Department.
One or many request is assigned a priority number to determine the order in which the request will be addressed by the technical contact.
If one or many request exist, it is mandatory a priority number is assigned to each request.
The Entity Relationship Diagram is a key document for the project in terms that it tells us the relationships between all entity types that are relevant for the business. It shows us what the key elements are in each entity in the organization, how it's going to be identified by each entity, and helps to prevent redundancy in the project.
In addition, it is critical for subsequent activities such as design of the database. When we have to develop the physical model, this diagram will be fundamental to achieve this goal. When we need to normalize the structure of the database, this diagram is going to be very helpful to do that because it ensures that the associations between entity types are correct.
The Entity Relationship Diagram allows project leaders to see a project's scope and its entity types - also if the relationships among them are really necessary. In conclusion, the Entity Relationship Diagram gives a general view of a project and how it may be implemented.
Entity Types and Attributes
| ENTITES: | Request | Priority | Employee | Application |
| ATTRIBUTES: | Request ID | Priority ID | Employee ID | Application ID |
| Requester Name (Employee Name) |
Priority Description | Employee Name | Application Description | |
| Date Entered | Response Time | Employee Initials | Version Number | |
| Assigned To (Employee name) |
Position (Functional Support Contact/Technical Support Contract/Manager/User) |
|||
| Assigned By (Employee name) |
Title (Technical Lead/Programmer/D.B.A/Manage) |
|||
| Application Id | Department (Financial Operation/IT) |
|||
| Application Description | Email Address | |||
| Estimated Start Date | Phone | |||
| Estimated Finish Date | Fax | |||
| Actual Start Date | Pager | |||
| Actual Finish Date | ||||
| Status (Open/Closed/Cancelled) | ||||
| Priority ID (High, Medium, Low) |
||||
| Priority Description | ||||
| Response Time | ||||
| Problem Description | ||||
| Resolution Description | ||||
Entity Business Description
Request A request is a petition made for a user who is experiencing any kind of problem with the PeopleSoft Financial System, to an employee who is a Functional Support Contact or Technical Support Contact, for enhancements or modifications to an application program in the PeopleSoft Financial System.
Application An application is a program written for a user of the PeopleSoft Financial System to accomplish user tasks that meets the business and operational needs of the Financial Operations Business Unit.
Employee An employee is a person who works for Zurich Kemper Life for the purpose of performing tasks for the benefit of Zurich Kemper Life’s business and its operations.
Priority The priority is a code established for IT Management with the purpose of determining the order in which the request will be addressed by the technical contact.
Working to structure the requests that come into the IT department, Support P1 will be a valuable software tool. By utilizing existing Lotus Notes software, easy acceptance among the functional staff is expected. Their current familiarity with Lotus Notes will allow them to easy understand the interface or "form" that they will use to input requests.
If a user of the PeopleSoft Financial System encounters a problem with the system, the user should report the issue to the PeopleSoft Functional Support Contact. If that contact person cannot resolve the reported problem, then an entry should be made in SupportP1. All the information will have to be filled in, and then a request ID and a priority will be assigned. SupportP1 will send out an email with the summary of the problem to both the main PeopleSoft Technical Support Contacts, and a copy to the sender. The details can be extracted from SupportP1. After looking at the priority, the task will be assigned to the technical team.
If the Technical Support Request is for a project that requires system analysis work (ex. new program, new report, modifications to existing program, or testing of new interfaces), then the PeopleSoft Functional Support Contacts will still make an entry into SupportP1. These kinds of projects will have to be approved by Management before any work is assigned. Therefore, there will be an option that will be checked by the requester to send the request to a manager, before the Technical team receives the request.
The Functional Support Contacts and the Technical Support Contacts are the two main groups that will need basic access to this system. The supervisors/managers will also be given access to the system. Their access will include administrative functionality to monitor the activities of their staff.
Cost Benefit Analysis is a critical factor in accomplishing all of the goals and objectives established for SupportP1. At this moment, Zurich Kemper Life is unwisely spending time and money because it does not have any control or standards to follow each user’s request. Employees are wasting time while deciding how to prioritize requests. The users' stress is getting worse because they want immediate responses to their requests, but they usually are not getting them.
These reasons have motivated Zurich Kemper Life to move towards implementing the application, SupportP1, to control these processes in order to save money, time, and improve service levels.
The costs and people who are going to participate in this project are the following:
PROJECTED DEVELOPMENT COSTS:
Personnel:
| 1 | System Analyst (100 hours/ea $65.00/hr) | $6,500 |
| 2 | Programmer/Analysts (200 hours/ea. $45.00/hr) | $18,000 |
| 1 | Database Specialist (10 hours/ea. $60.00/hr) | $600 |
| 1 | System Librarian (100 hours/ea. $10.00/hr) | $1,000 |
Expenses :
| 8 | User guides for training (6 people) | $100 |
Total Projected Development Costs : $26,200
PROJECTED ANNUAL OPERATING COSTS:
Personnel :
| 2 | Programmer/Analysts (50 hours/ea $45.00/hr) | $4,500 |
| 1 | System Librarian (100 hours/ea $10.00/hr) | $1,000 |
Expenses :
| 1 | Maintenance Agreement for Compaq Server | $700 |
| 1 | Maintenance Agreement for Lotus Notes Server software | $300 |
Total Projected Annual Operating Costs : $6,500
Hardware and software applications that the new system will require currently exist and will require no purchases.
Intangible Benefits:
Costs associated with this project will be relatively small in comparison to the benefits. Benefits will be realized by a reduction in person-hours, less troubleshooting time, and a reduction in IT costs for tracking and reporting issues.
Zurich Kemper Life’s IT department will accelerate their response time by 10%. This means that the IT department will provide better service to the users.
The automation of this process is going to reduce users' emotional stress by 5%. Therefore, based on past experience, they are going to be able to increase the quality level that they give their customer - we are estimating this to be a 15% improvement over the first two years. This will be measured by frequent feedback surveys that customers will receive after they place a request.
Tangible Benefits:
After implementing this plan, we estimate that Zurich Kemper Life will save 5% on contractors’ fees. For its employees, this means more availability to develop new applications or improve the existing ones. To calculate the required information, we will base our information on the responses make by those we interviewed. Currently, each contractor works 2080 hours per year. 2080 hours per year x 5% = 104 hours. So, Zurich Kemper Life will save 104 hours per contractor per year. ((104 hr. * $50) = $5,200/hr) * (4 contractors) = $20,800. This quantity only represents the savings regarding contractors. In addition, the plan will save at least 60 employee hours per year. (( 60 hr * $50) = $3,000/hr) * (3 employees) = $9,000.
This results in the following yearly totals:
Contractors’ fee savings $20,800.00
Zurich Kemper Life employees savings $9,000.00
$29,800.00
The investment is going to pay by itself in 2 years in the following scenario:
| Cash flow Description | Year 0 | Year 1 | Year 2 |
| Development Cost: | ($26,100.00) | ||
| Operation and Maintenance cost : | ($6,500.00) | ( $6,500.00) | |
| Discount factor for 12% : | 1.000 | 0.893 | 0.797 |
| Time-adjusted Costs : (adjusted to present value): | ($26,100.00) | ($5,804.50) | ( $5,180.50) |
| Cumulative time-adjusted costs over life time: | ($26,100.00) | ($31,904.50) | ($37,085.00) |
| Benefits derived from operation of new systems | $0.00 | $29,800.00 | $29,800.00 |
| Discount factor for 12% | 1.000 | 0.89 | 0.71 |
| Time-adjusted benefits : (adjusted to present value): | $0.00 | $26,522.00 | $21,158.00 |
| Cumulative time-adjusted benefits over life time: | $0.00 | $26,522.00 | $47,680.00 |
| Cumulative life time-adjusted costs + benefits: | ($26,100.00) | ($5,382.50) | $10,595.00 |
NOTE: The Numbers with Parenthesis and Underlines are debits.
The proposed software solution is technically practical, and would be fully supported at Zurich Kemper Life.
A survey of Zurich Kemper Life technology showed that there is available (in-house) technology and technical expertise to build the proposed system quickly, without risk, and at no additional hardware/software cost. Additionally, a review of the customers’ technology product specifications showed the proposed systems technology is mature, reliable and complies with Zurich Kemper Life Technology standards. Please note the Technology Matrix in Appendix I.
As visible in the attached organizational chart (Appendix F), the proposed Technical Support Service Request is the link between the Financial Operations group and the Information Technology department. A secure software package allows for different levels of access according to duties in each group. As part of the process - there will be better data and documentation for each request.
With requests coming in by phone or email, there will be less of a chance for error. This, in turn, makes the output cleaner. Getting a history for a user's requests allows for more efficient requests. Assigning priorities to requests is another feature that has proved to be helpful.
Recommendations
Upon completion of the Systems Analysis Phase, the project team performed a phase-end review and risks assessment of the accumulated deliverables to determine if the project should be cancelled or proceed to the design phase.
We concluded, review of the accumulated deliverables revealed: there were no changes to the project scope, budget, schedule or requirements; The project was complete, realistic and feasibly achievable; and, the requirements specification were complete and pertinent to the problem solution. As a result, risk assessment of the accumulated deliverables disclosed no potential or probable constraints that could have a major impact on the continuation of this project. Therefore, we recommend this project continue onto the design phase. We estimate the design phase to take 10-12 weeks to complete.
Appendices
Appendix A – Visual Aids.
RECOMMENDATIONSPHASE-END REVIEW
To determine if the SupportP1 project should
continue, the project team performed a Systems Analysis Phase-end review. This included:
VERIFICATION AND VALIDATION OF ACCUMULATED DELIVERABLES
Purpose:
Objective:
Scope:
| REF # | DELIVERABLES |
Completed |
|
Yes |
No |
||
| Survey Phase | |||
| A | Project Charter | X | |
| A | Project Plan | X | |
| Study Phase | |||
| B | Feasibility Study | X | |
| Definition Phase | |||
| C | Project Context | X | |
| C | Data Models | X | |
| D | Process Models | X | |
| Documentation | |||
| E | Project Report | X | |
RISK ASSESSMENT OF ACCUMULATED DELIVERABLES
Purpose:
Objective:
Scope:
REF# |
RISK |
True |
False |
| Survey Phase – Project Charter | |||
| A | Incomplete definition of Scope | X | |
| A | Evolving Project Scope | X | |
| A | Project Charter does not provide an adequate base for requirements | X | |
| Study Phase – Feasibility Study | |||
| B | Major increase in cost possible | X | |
| B | Major increase in project schedule/completion date | X | |
| B | Required/planned resources not available | X | |
| B | Organizational changes required (in terms of structure) | X | |
| B | Ill-defined Benefits | X | |
| B | Incomplete/New Technical Requirements | ||
| Definition Phase – Requirements Specification | |||
| C,D | Incomplete definition of requirements | X | |
| C,D | Evolving business requirements | X | |
| C,D | Requirements specifications does not provide an adequate base for design | X | |
| Documentation – Project Report | |||
| E | Incomplete documentation | X | |
CONCULSION
NEXT STEPS
Before proceeding to design phase:
(Management decision to proceed or cancel project)
Appendix B – Team meetings
Thursday - 1/7/99 @ DePaul Univ.
Discussed Potential Project Ideas.
Thursday - 1/14/99 @ DePaul Univ.
Discussed Plan for SupportP1 Project.
Sunday - 1/17/99 @ DePaul Univ.
Decided on who's responsible for each Deliverable in the Project. This person was designated as the Editor of their Deliverable. Worked on Deliverable A.
Thursday - 1/21/99 @ DePaul Univ.
Handed in Deliverable A; Discussed Deliverable B.
Thursday - 1/28/99 @ DePaul Univ.
Worked on Deliverable B.
Thursday - 2/4/99 @ DePaul Univ.
Handed in Deliverable B; Discussed the entity types we need for our project. Looking at the inputs and outputs.
Sunday - 2/7/99 @ DePaul Univ.
Decided on entity types for our project and worked on understanding the processes. Developed the data flow diagrams and entity relationship diagrams.
Thursday - 2/11/99 @ DePaul Univ.
Refined data flow diagrams and entity relationship diagrams.
Sunday - 2/14/99 @ DePaul Univ.
Solidified Deliverable C & D's content.
Thursday - 2/18/99 @ DePaul Univ.
Handed in Deliverable C & D; Discussed presentation and final written deliverable.
Saturday - 2/20/99 @ DePaul Univ.
Divided presentation time; assigned work for the presentation and the final written deliverable.
Thursday - 2/25/99 @ DePaul Univ.
Discussed presentation and final written deliverable.
Saturday - 2/27/99 @ DePaul Univ.
Worked on presentation and final written deliverable.
Appendix C – Interview Notes
Interview question asked by Kamran Hussain - at various times between 1/13/99 and 1/20/99. Answers from various representatives of Zurich Kemper Life.
Q. How do you currently make the requests?
A. By telephone, stopping by the technical lead or sending an e-mail.
Q. How many different applications do you use with PeopleSoft software? What are these different applications?
A. Five different applications: PeopleSoft General Ledger Module, PeopleSoft Accounts Payable Module, Crystal Reports, N Vision Reports and SQL Reports.
Q. Currently, how do you prioritize requests?
A. Two to three people are involved in making the requests. They decide on their own high and low priority items to be worked on.
Q. In the future, what are your criteria for the different priority levels in this process?
A. We want to structure the system into "Priority 1" through "Priority 5." "Priority 1" will be the top priority.
Q. Who will sponsor this project? Will we have upper-Management buy-in?
A. Mr. Bob Daniels, the company's C.F.O. is making sure this project gets completed in a timely manner.
Q. Currently, how many people are spending time on this type of request work? How much time does each person spend on this type of request work?
A. There are 4 contractors working on these requests. Each one spends a 40-hour week on this work, so the totals hours per year is (40x52)x4 = 8320 hours.
Appendix D – List of Persons Contacted
Mr. Jack Kennedy
Information Technology Director
Zurich Kemper Life Building, 18th Floor, Tower 2
Schaumburg, Illinois 60196
847-969-6381
Ms. Clare Smith
Functional Lead
Zurich Kemper Life Building, 17th Floor, Tower 1
Schaumburg, Illinois 60196
847-969-7098
Mr. Tom Nichols
Technical Lead
Zurich Kemper Life Building, 18th Floor, Tower 2
Schaumburg, Illinois 60196
847-969-7534
Mr. Bob Daniels
Chief Financial Officer
Zurich Kemper Life Building, 17th Floor, Tower 1
Schaumburg, Illinois 60196
847-969-6782
Appendix G – Context Diagram
Appendix H – Process Decomposition Diagram
Appendix I – Technology Matrix
See the five pages to follow...
