• +1 (317) 799-6577
  • support@sharksavewriters.com
Hire Writer

Service Management and Support Project

Service Management and Support Project

Student’s Name

Institution Affiliation

Date

Abstract………………………………………………………………………………………………………………………….3

Introduction…………………………………………………………………………………………………………………….4

Background………………………………………………………………………………………………………….4

Problem Statement………………………………………………………………………………………………..5

Audience……………………………………………………………………………………………………………..5

System Requirement………………………………………………………………………………………………………..6

Requirements Modelling………………………………………………………………………………………..6

Data Process Model……………………………………………………………………………………………….7

Data Flow Diagram……………………………………………………………………………………………….8

Data Dictionary…………………………………………………………………………………………………….9

Object Modeling………………………………………………………………………………………………….10

System Design……………………………………………………………………………………………………………….12

Systems Specifications…………………………………………………………………………………………12

Data Design………………………………………………………………………………………………………..13

User Interface Design…………………………………………………………………………………………..14

System Architecture…………………………………………………………………………………………….17

Feasibility Analysis……………………………………………………………………………………………..19

Project Plan…………………………………………………………………………………………………………………..22

Work Breakdown Structure…………………………………………………………………………………..22

Project Monitoring and Control Plan……………………………………………………………………..24

Timeline…………………………………………………………………………………………………………….24

Summary………………………………………………………………………………………………………………………26

References…………………………………………………………………………………………………………………….27

Abstract

The following system study is about a new opportunity for Learning Technology Resources (LTR) in acquiring a new course service software & customer support ticket system for assigning and responding to portal issues. The reason for this study was to perform an overall analysis of LTR’s current system and the opportunity to fix many outstanding glitches and problems with it. Being that POST has over 600 agencies participating in its program, adequate customer service is key to building a lasting relationship with its customers. The result of this document is to outline and suggest the best possible system that will fit our customer’s needs.

Service Management and Support Project

Commission on Peace Officer Standards and Training (POST) is a medium-sized California agency that was “established by the Legislature in 1959” (“About POST,” 2018). POST’s goal is to set minimum selection and training standards for all of California law enforcement (“About POST,” 2018). With more than 600 agencies participating in the POST Program, Learning Technology Resources (LTR) provides 24/7 access to the Learning Portal for Continuous Professional Training (CPT) for all participating agencies. With over 80,000 active users on the Portal, LTR IT staff use the JIRA Service Desk software to track, assign, and fix Portal bugs. JIRA Service Desk is a full-featured sevice desk platform built off the Atlassian JIRA Software. The JIRA Software is cloud and subscription-based software designed to track issues and coordinate teams for agile software development (“Atlassian JIRA,” 2016). Its crucial feature is managing software bugs and their eventual removal, a task for which this platform is used in many commercial enterprises (Martinez, 2017).

Background

In the past couple of years, LTR has tried to consolidate its Portal Helpdesk software (JIRA) with outside vendors that develop LTR courses to analyze better, design, implement, and support the classes thought its entire system’s development life cycle (SDLC). Management has determined that users, internal and external, interacting with the Portal and courses would be better served using a single system than relying on multiple systems to communicate Portal and course issues. To achieve this goal, LTR has decided to task its IT personnel by (1) analyzing the JIRA Service Desk software to determine if any changes can be made and (2) to look for appealing new products that meet LTR’s requirements for both course development and helpdesk support.

Problem Statement

In recent months, POST has increased urgency from its stakeholders to be financially responsible for its budget. To accommodate this budgetary responsibility, the executive office has delegated each bureau to be accountable for their internal budget. The anticipated direct benefits to LTR with a single system are as follows:

The direct impact of not implementing the solution above is LTR would not have a standard platform for testing each project delivered to the Portal, resulting in a significant amount of resources and time being used to learn multiple individual systems. Furthermore, the funds spent on the vendor’s side would decrease, including any onboarding to POST’s system and costs needed to implement the course within the vendor’s ecosystem.

Audience

For the most recent courses, LTR has launched the project managers (aka lead instructional designers), and Portal support staff have emphasized the importance (to their efficiency) of getting a more centralized and robust system for Portal and course issues. The Portal currently resides on multiple servers that LTR’s Portal vendor provides and a separate system to track Portal bugs. Approximately 63 testers are used in both Alpha and Beta phases, with the project manager funneling and entering all technical issues into a separate system for each course. All of this information is housed in multiple inconsistence systems that project managers and Portal support staff must use to track, fix, and archive bugs.

To respond to LTR’s call for the rapid introduction of a more successful and centralized system, LTRs Portal Administrator has recommended that management initiate a systems study of the current systems. This systems study will apply structure and object-oriented analysis modeling techniques to analyze, design, and manage how issues are tracked, fixed, and archived within the current ecosystem LTR has. This would provide direct and easier access for Portal support staff and project managers, regardless of application, to communicate current issues with Portal and course framework, and deliver an achievable record to draw upon as new applications are implemented. This document is the output of the LTRs Portal Administrator efforts.

For LTR to implement a new system for its Portal support staff and project managers, a systems requirements section will be needed to layout prerequisites. These requirements will describe, at the system level, the functions that the system as a whole should fulfill to satisfy user needs and requirements. To accomplish this requires a combination of textual statements, views, and non-functional requirements; the latter is expressing the levels of safety, security, reliability, etc., that will be necessary (“System Requirements,” 2015). Going forward, LTR will be making recommendations on the hosting platform deemed essential for the new software to run. Upon implementation, the new software will be running on an internal or external server with users accessing the application through a client interface.

Requirements Modeling

The current system is a self-hosted Jira product for projects and issue tracking. This system is primarily used by Computer Service Bureau (CSB) for their internal projects and issues. LTR has been given access to this system for its projects and issue tracking needs. However, the main problem in using this system is the lack of initiating external communication with customers. As such, the proposed new system will not be a complete “rip and replace,” but rather a system designed in the ecosystem of Jira to function alongside CSB. The proposed method would allow LTR to measure:

Data Process Model

The diagram below shows an example of a data process model for the new issue tracking system. The data model explains the data processor for the system, which is the JIRA SERVICE DESK. For the process, the CUSTOMER logs into JIRA SERVICE PORTAL and submits a ticket directly. Also, an ISSUE can be sent via email and uploaded to JIRA SERVICE DESK without requiring the CUSTOMER to log into the Portal. Once logged in, the CUSTOMER submits an ISSUE in JIRA SERVICE PORTAL, which produces the CUSTOMER’S TICKET.

 

Figure 1. Jira Service Desk Data Process Model

Data Flow Diagram

The diagram below shows the Data Flow Diagram for the new issue tracking system process for LTR.  There are four entities for the issue tracking system.  The objects are Customer, Jira Service Portal, and Helpdesk Agent. The CUSTOMER can send an issue via email directly or enter into JIRA SERVICE PORTAL, which will carry the problem to the system. JIRA SERVICE DESK will compile the collected information and create an open ticket for the HELPDESK AGENT. The HELPDESK AGENT will then initiate a conversation to help alleviate the issue the CUSTOMER has. Once the problem is resolved, the HELPDESK AGENT will denote the matter is closed. Then, JIRA SERVICE DESK will initiate a closed message notification directly to the CUSTOMER or to JIRA SERVICE PORTAL based on how the CUSTOMER started the issue.

 

Figure 2. Jira Service Desk Data Flow Diagram

Data Dictionary

Table 1

Data Dictionary for Jira Service Desk

Entity

Name

 Entity Description Column Name Column Description Character Count Primary Key
Customer A customer is a person that uses the Learning Portal. Customer ID Customer’s unique number 6 TRUE
    Type Type of issue (i.e., bug, question, etc.) 25 FALSE
    Priority Priority level 25 FALSE
    Full Name Name of Customer 25 FALSE
    Email Users Email 25 FALSE
    Agency Users Agency 25 FALSE
Helpdesk Agent A helpdesk Agent is a person that uses Jira. Helpdesk Agent ID Agent’s unique number 6 TRUE
    Full Name Name of Agent 25 FALSE
    Email Agent’s Email 25 FALSE
Jira Jira Issue Record is a ticket that is created from a customer’s inquiry. Jira ID Jira’s unique number 6 TRUE
    Assign Name of Agent 25 FALSE
    Status Categories Identify where the issue is in its lifecycle 25 FALSE
    Issue Statuses Indicates the stage of the issue 25 FALSE
    Resolutions How the issue was resolved 25 FALSE
    Email Email sent to the user 25 FALSE

 

Object Modeling

The figure below shows three different types of objects for the new system.  The CUSTOMER object has specific attributes such as name, email, and agency. The CUSTOMER object can perform methods such as submit a ticket email and submit a ticket via the Jira Service Desk Portal. The HELPDESK AGENT object has attributes such as name and email. The HELPDESK AGENT can perform specific methods such as pick up a ticket, assign a ticket, respond to a customer, and close a ticket. The JIRA object has particular attributes such as Jira ID, status categories, issue statuses, resolutions, and email. The JIRA object can perform methods such as sending communication between the agent and the customer.

Table 2

Object Modeling for the System

Customer   Helpdesk Agent   Jira  
Attributes Name Attributes Name    
  Email   Email Attributes Jira ID
  Agency Methods Pick up ticket   Status Categories
Methods Submit a ticket via email   Assign a ticket   Issue Statuses
      Respond to customer   Resolutions
      Close a ticket Methods Send out Emails

Use Case Diagram

This diagram shows how online interaction will be carried out between the various actors. Within this diagram, the actors are the customers and the helpdesk agent. In the chart, the customer fills out a ticket registration form with various information on the issue. This request is submitted to the service portal, which then initiates an update to the Jira Service Desk queue. The queue notifies the helpdesk agent that an issue has been created, whereby they pick it up or assign it to another agent. Once appointed, the agent will complete an initial assessment and prepare to send a communication back to the Portal for the customer to answer.

 

Figure 3. Case Diagram for Service Request.

It has been decided that obtaining and modifying an application software called Jira Service Desk is the best approach for LTR. In acquiring a new system, LTR must concentrate on the design of the system. One might ask why focusing on the design is so important. The answer to this is simple: without a suitable plan, the issues discussed in the Systems Requirements section will not be overcome. The formation of a suitable user interface will allow LTR’s support staff to better care for its clientele, maintain records more efficiently, and reduce errors from occurring. As a result, the analysis in the following sections will assist the design of the system before any execution is to commence.

Systems Specifications

In thinking about any new application, LTR must ensure that all the system requirements are checked. To operate the Jira Service Desk by either the cloud or self-hosting, some decisions need to be considered before the application can be installed. First, the number of users needs to be selected. In looking at LTR’s past projects and support staff’ roughly 16-25 agents will cover current and future needs. Simultaneously, LTR must maintain some considerations such as government regulations, technology, and budget issues while looking at acquiring this application. The table below shows the system requirements of the Jira Service Desk per LTR’s needs.

Table 1

System Specification

FEATURE REQUIREMENT RECOMMENDATION
Agents Self-Hosted License:

· 16-25 Agents = US $7,200 (Annual)

Cloud License:

· 16 – 25 = $4,500 (Annual)

 Cloud License: Anything under 5K only requires only an intra-office requisition.
Software Maintenance Self-Hosted License:

· 16-25 Agents = US $3,600 (Annual)

Cloud License:

· Part of Annual License

 Cloud License: Maintenance is part of the license fee.
Application Usage Self-Hosted License:

· Medium Scale

o Users = 500

o Concurrent Users = 200

o Issues = 60000

o Issues/month = 1000

o Custom Fields = 150

o Permission Schemes = 15

o Projects = 80

o Parent Issue Types = 20

o Resolutions = 20

o Priorities = 15

o Workflows = 20

Cloud License:

· Part of Annual License

 Cloud License: Storage is part of the license fee.
System Requirements Self-Hosted License:

· System Memory > 8GB

· JVM Heap Size > 2GB

· App Install Dir ~200MB

· Backups > 200MB

· Attachments = 50-100GB

· Application Logs = 50MB

· Total disk space = 50 – 100 GB

Cloud License:

· Part of Annual License

 Cloud License: Servers are part of the license fee.

(Atlassian, “Jira Service Desk Licensing,” Atlassian, “Jira Sizing Guide’)

Data Design

In the system analysis stage, after the logical model is made, the next step is to decide how the data will be organized, stored, and managed. The database administration framework is produced to understand the underlying data design concepts, including data structures and the evolution of the relational database (Tilley & Rosenblatt, 2017, p275). The focuses of data design are to look at the entity-relationship diagram (ERD) and to show the logical relationships of how various files or tables interact with the system. In designing an ERD, one essential makes the general blueprint for physical system structure. The proposed solution to LTR’s application is to create a system where helpdesk tickets or application bugs can be submitted from a USER. The below figure uses Crow’s foot notation to represent LTR’s entity-relationship diagram for USER, ISSUE, ISSUE TYPE, RESOLUTION, and SUPPORT STAFF as it is stored within the system.

 

Figure 4. An ERD for USER submitting an ISSUE.

User interface Design

Designing or acquiring a good user interface is considered an essential task in the systems planning period of the SDLC. The interface must be simple, dependable, and even practical so as not to hinder expectance or productivity for the users. A good interface comprises of graphical screens, menus, functions, which allow for communication between the user and program. Considering the standards for a good interface, an interface cannot be difficult to learn and utilize. Many experts believe that a good interface is one the users do not notice because they make sense and do what users expect them to accomplish. (Tilley & Rosenblatt, 2017, p 237).

The primary user interface for Portal clients will comprise of a customer portal and knowledge database. The customer portal will let users submit a request with ease-of-use, and the integrated knowledge base will use machine learning to wisely recommend the right service, so to allow answers to be found easily. This Portal will help users check the status of their support requests and review updates to their knowledge base. Users can also search through previous interactions or tickets they’ve been CC’d on to find answers to previous questions, allowing them to save time and the team from responding to repetitive items. Alternatively, users can submit an issue via email (either by an email application or in the mobile form). The customer portal interface will look something like the following:

 

Figure 5. Customer Portal User Interface

Likewise, IT support staff will need a robust and easy to under standard interface for them to fix incidents faster and push changes with confidence. The interface they interact with will allow them to have an out-of-the-box service request platform for issues, the automation of repetitive tasks, and metric reporting.

 

Figure 6. Support Staff User Interface

 

Figure 7. Ticket User Interface

These interactions fall under the Human-Computer Interaction (HCI) domain. This domain describes the relationship between computers and how people use them to perform their jobs (Tilley & Rosenblatt, 2017, p 238). HCI, in this case, focuses mostly on productivity between the user and the support staff. Allowing users and support not to limit their productivity from a single domain, but letting them have multichannel support across the web, email, and mobile will result in increased productivity. To accommodate for multichannel support, the interface will not be developed in-house, but instead, use a web-based platform. For this reason, the seven principles of successful interface designs will be followed.  Atlassian, the company behind Jira, has designed a successful users’ interface around completing tasks more efficiently, which for our solution, revolves around users being able to submit, track, and manage requests submitted to support staff.

System architecture

The system architecture point of the SDLC is to determine the physical framework of the system. Here one translates the logical design into components such as hardware, software, data, procedures, and people to accomplish a specific set of functions. In understanding these components, you are creating a flexible system that can become cost-effective, technically sound, and able to support the information needs of the business. However, before the system can be implemented one needs to understand how the system interacts with one’s corporate organization, including the enterprise resource planning, total cost of ownership, scalability, integration and interface requirements, and security. (Tilley & Rosenblatt, 2017, p 323).

Jira Service Desk fits well into the corporate organization and culture of POST. POST’s goal is to continually enhance the professionalism of California law enforcement in serving its communities. POST strives to give its stakeholders the highest-quality, most cost-effective, and relevant law enforcement training available (State of California Commission on POST). The new system operates in a cloud-based info-structure eliminating the need for constant updates and support for the Computer Service Bureau (CSB). All servers, storage, and maintenance will be a part of Atlassian umbrella, thus allowing for the resource at POST to be geared to providing more cost-effective training and support. The overall design correlates with the current POST standards, by providing a user interface with a mock look and feel of the current website. The installation of software will not be an issue, this application is entirely web-based, and no special software is needed for the product to work. Initial cost and the Total Cost of Ownership (TCO) is the most exciting part of this application.

The TCO for this application is affordable versus other competitors. They are two different fees associated with this software. The first fee is an annual subscription based on the number of agents using the product. For LTRs purposes, this would amount $4,500 for 16-25 agents. The second fee would be the interrogation of Atlassian Confluence (aka a knowledge base) that will integrate with Jira Service Desk. This application only charges for KB authors and centralize support documentation in a self-service knowledge base. For LTRs purposes this would amount $1,250 for 16-25 agents. This application will most likely be eliminated and will not be included in the economic feasibility analysis. These amounts could be subject to change if Atlassian needs to adjust is pricing scheme to meet and ever-changing market. If fees were to change, it would affect how POST can continue to use their product. After those fees are paid, the registration system will be active and we will be able to enter all data to go live immediately.  For a system like this, that’s a total cost of $4,500, not including tax.

Scalability will not be an issue for this design due to the software being cloud-based.  Cloud-based software is needed in this design, being that a system needs to support a dynamic, growing business.  POST will continue to grow, so it is a smart decision to have a scalable design that can improve along with the company.  There should not be any replacements or upgrades needed from this system for some time, as all enhancements are taken care of by the vendor. Once again, with this design, integration issues will not be a problem.  This system is entirely cloud-based and web-centric. The interface will be able to function on any device platform such as Windows, Mac OS, or Chrome.  Security is fundamentally essential no matter what the business is, government or private.  Atlassian cloud-based services use the encryption technology Transport Layer Security (TLS) with Perfect Forward Secrecy (PFS). Atlassian’s implementation of TLS uses strong ciphers and key-lengths by default. They rigorously test their programs by doing threat-modeling, manual code review, automated scanning, and third-party assessments (Atlassian, “Security at Atlassian”). Atlassian has gone the extra mile to ensure that security will not be an issue when it comes to their cloud-based application.

Feasibility Analysis

Keeping in mind the end goal of this document is the execution of this application, a study known as plausibility needs to be performed. To perform plausibility study, four areas are utilized known as operational achievability, specialized practicality, financial plausibility and timetable possibility. In looking at these four areas, Atlassian’s Jira Service Desk will be argued as the appropriate solution to solve LTR’s problem.

Operational

Atlassian offers adequate training for its clients, as well as a user-friendly interface that will be easy to learn for our users. With Atlassian’s 24×7 support, they can make any changes and adjusting to any feedback given to enhance our design. Jira Service Desk can be accessed from any tablet, smartphone, laptops, or desktop computer by an agent or by users. Being a cloud-based application only internet is needed along with the user name and password to access the application. LTR can foresee that a problem within operation feasibility can occur with users understanding the interface.  It is confident that this can be solved after a brief tutorial and interaction with the application. LTR also needs to have access to the data stored in the cloud. This will allow for LTR to backup and download its data in case it needs to migrate to another system.

Technical feasibility

In looking at the technical feasibility, LTR will be basically be accessing this application via a web interface. Since the application will be web based, just internet connectivity will be needed to operate the application.  The equipment and systems behind Jira are set up in a manner that enabels future extension. Atlassian hosts Jira Service Desk on their own servers with a 99.9% uptime and 24x7x365 customer support. They also handle the upgrades and maintenance releases for ther clients.

Economic Feasibility

In estimating the TCO for the application, one ought to gauge the associated Return on Investment (ROI) that a company will get when purchasing a new product. LTR needs to understand the cost/benefits of the project. This helps LTR determine the practicality, cost, and benefits associated with the project before financial resource are allocated.

Financial Summary (risk-adjusted estimates)

Based on the input of 16 agents with a 2% growth, an average annual salary of $73,434, and monthly license fee of $375 per agent, the ROI over the next two years would be 3.07%.

Table 2

Cash Flow Analysis (risk-adjusted estimates)

    Calculation Initial Year 1 Year 2 Total
A1 Total costs.   $4,500 $4644.90 $4794.47 $13,939.37
A2 Total benefits.   $0 $216,630.40 $225,442.48 $442,072.88
A3 Net Cash. A2 Total − A1 Total       $428,133.51
A4 ROI A3 Total ÷ A1 Total * 100       3.07%

Table 3

Total Cost

Cost Initial Year 1 Year 2 Total
Cost for license. $0 $4,500 $4644.90 $13,500
Cost to implement. $4,500 $0 $0 $4,500
Estimated incremental increase. $0 $144.90 $149.57 $289.80
Total Costs. $4,500 $4644.90 $4794.47 $13,939.37

 

Table 4

Estimated Cost for License

Metric Calculation Initial Year 1 Year 2 Total
Agents.   16-25 16-25 16-25  
Cost per year. 375 * 12 $4,500 $0 $0 $4,500
  387.075 * 12   $4644.90   $4644.90
  399.539 * 12     $4794.47 $4794.47

 

Table 5

Estimated Incremental Increase

Metric Calculation Initial Year 1 Year 2 Total
Inflation. 3.22%        
Cost. $4,500 * 0% $0     $0
  $4,500 * 3.22%   $144.90   $4644.90
  $4644.90 * 3.22%     $149.57 $4794.47

 

Table 6

Total Benefits

Benefit Initial Year 1 Year 2 Total
Increased productivity. $0 $190,928.40 $199,740.48 $390,668.88
Improved agent experience and retention. $0 $25,702 $25,702 $51,404

 

Table 7

Increased Productivity of Agents

  Metric Calculation Initial Year 1 Year 2 Total
A1 Phone.   30% 25% 20%  
A2 Email.   70% 75% 80%  
A3 Agents.   16-25 16-25 16-25  
A4 Phone improvement. assumption   5% 5%  
A5 Impact on productivity phone. A1 * A3 *A4   0.2 0.16  
A6 Email Performance. assumption   20% 20%  
A7 Impact on productivity email. A2 * A3 *A6   2.4 2.56  
A8 Total time saved. A5 + A7   2.6 2.72  
A9 Average salary.     $73,434 $73,434  
A10 Increased in productivity. A8 * A9   $190,928.40 $199,740.48 $390,668.88

Note: Improvements were calculated with 16 agents.

Table 8

Improved Agent Experience and Retention

  Metric Calculation Initial Year 1 Year 2 Total
B1 Agents.     16 16  
B2 Expected reduced level of turnover. C1*15% (rounded)   2 2  
B3 Impact on turnover attributed to using Jira. C2*40% (rounded)   1 1  
B4 Average cost to recruit and train. assumption   $25,702 $25,702  
  Improved agent experience and retention. C3*C4 $0 $25,702 $25,702 $51,404

 

With LTR being the sole entity responsible for Portal and online course maintenance, they have decided to purchase, modify, and implement the application software called Jira Service Desk. The process of rolling out this application is involved, thus requiring a project plan to be created by the project manager. Completing this project on time, within budget, and to meet the users’ requirements is essential for this project. The planning, scheduling, monitoring, and reporting of this project are four significant areas required of the project manager. These processes are outlined in the Work Breakdown Structure (WBS), Project Monitoring and Control Plan, and Timeline below.

Work Breakdown Structure

Implementing a new system involves a series of precise tasks for the project manager. The initial step consists of the project manager reviewing the project notes set by LTR and doing so will help them create a business case document. This document will enable the project manager to develop a timeline for the project with the goal of getting a signoff to commence. In the beginning steps of the business case document, the project manager, along with the system analyst, will be defining the system requirements. This phase involves the (who, what, where, when, and how) for the new and existing system. Here the project manager will use various fact-finding techniques, including interviews, document review, observation, and research to develop the required document (Tilley & Rosenblatt, 2017, p. 118). After gathering requirements, the system analyst will be working on system design, building a system that is effective, reliable, and maintainable (Tilley & Rosenblatt, 2017, p. 235). This design phase will encompass implantation of the systems, along with developing data flow diagrams, and the user processes.

After the designing phase is complete, software and system engineers will be responsible for implementing the software and for creating various web-based applications. They will need to demonstrate through prototypes not only the applications, but also how it will integrate into the ecosystem of the Portal. Next will be verification by the system analyst, where the solution architecture will be reviewed and the prototype will be validated. The project manager will then finalize the project by determining recommendation and creating a presentation for LTR. A more detail information about the project plan including the days and hours expected for each task to complete is shown in the Figure 1 below.

 

Figure 8. Gantt Chart showing the IT Service Desk & Customer Service Software plan.

Project Monitoring and Control Plan

It’s essential for the project manager, regardless of the project being planned with software or in another manner, to keep track of progress. The project manager must gauge the development of the team, compare actual progress with the plan, verify completion of milestones, and set standards and ensure that they are followed (Tilley & Rosenblatt, 2017, p. 83). To accomplish this, the project manager will conduct bi-weekly meetings to track and compare the project’s progress. Furthermore, the systems analysts, software engineers, and systems engineers will be responsible for performing a structured walk-through of their respective peers’ work. These reviews will be staggered throughout the Systems Development Life Cycle (SDLC) as the critical paths of the project, encompassing design reviews, code review, and testing reviews (Tilley & Rosenblatt, 2017, p. 83). To coordinate these tasks the use of project management software is vital for the project manager. Microsoft Project will help them plan, schedule, monitor, and report on the project, allowing them to be a more effective manager as most of the work will be automated. By using this software, the project manager will be aware of any issues that arise, allowing for regular updates to ensure the project remains within the allotted budget and without delay.

Timeline

The estimated amount of time for implementation of the project is 848 hours, and the total duration will be 74 days. The start date for the project is April 2, 2018, and it is expected to finish on August 12, 2018. The work breakdown structure with the amount of time for each task is shown in Figure 2. The total project cost of this project is $37,373.04. A breakdown of the project cost is provided in Figure 3.

 

Figure 9. Gantt Chart showing the timeline for the project.

 

Figure 10. Gantt Chart showing the total projected cost for the project

 

Summary

This system proposal document descriptively breaks down the Jira Service Desk application by combining graphs, charts, analysis, and methods for a possible implantation by LTR. This document provides several explanations as to why and how certain aspects of this application will be critical to the overall continual success of LTRs Portal. By creating this system proposal document, LTR will increase its chance of having a successful presentation to our Bureau Chief which in return will eventually help implement the proposed system

 

References

About POST. (2018). Retrieved February 20, 2018, from https://www.post.ca.gov/about-us.aspx

Atlassian. (n.d.). Atlassian JIRA. Retrieved February 20, 2018, from https://www.pcmag.com/business/directory/project-management/1039-atlassian-jira

Atlassian. (n.d.). Jira Service Desk Licensing. Retrieved April 05, 2018, from https://www.atlassian.com/licensing/jira-service-desk

Atlassian. (n.d.). Jira Sizing Guide. Retrieved April 5, 2018, from https://confluence.atlassian.com/enterprise/jira-sizing-guide-461504623.htm

Atlassian. (n.d.). Security at Atlassian. Retrieved April 05, 2018, from https://www.atlassian.com/trust/security

Martinez, J. (2017, December 18). Jira Service Desk. Retrieved February 20, 2018, from https://www.pcmag.com/article2/0,2817,2488242,00.asp

State of California Commission on POST. (n.d.). Mission, Values, Vision. Retrieved April 05, 2018, from https://post.ca.gov/mission-values-vision

System Requirements. (2015, June 29). Retrieved March 24, 2018, from http://www.sebokwiki.org/wiki/System_Requirements

Tilley, S. R., & Rosenblatt, H. J. (2017). Systems Analysis and Design [11]. Retrieved March 27, 2018, from https://vsaccess.vitalsource.com/#/books/9781305533936/cfi/0!/6/2@100:0.00

error: Content is protected !!