files.transtutors.com · Web viewMyki project. EXECUTIVE SUMMARY . This report provides the readers...

Myki project

EXECUTIVE SUMMARY This report provides the readers with an analysis of the various requirements concerning the identified stakeholders associated with Melbourne's public transport ticketing system. The M.I.N.T.S project focuses on redesigning an improved version of the existing Myki ticketing system by proposing solutions based on the collected requirements. Proposed solutions include an integrated business intelligence dashboard which would provide PTV a holistic view of all operations by all service providers against benchmarks set by the steering committee. In addition, the dashboard would also provide information on equipment metrics such as average tap-on, tap-off time, equipment failure frequency etc. This information would be used to forecast equipment maintenance checks well in advance further saving operational costs for all stakeholders. Other proposed functionalities include use of RFID wristbands as well as smart watch as virtual Myki smart cards, a personalization and online purchase feature for the RFID wristbands and optimizing operational costs through improved scanning time on scanning devices and generation of electronic receipts for registered customers, thereby reducing paper waste. The use of Amazon cloud services, specifically, Amazon Greengrass and analytical suite, has been proposed to solve the issue of unavailability of real-time update in Myki transport transactions. Another area of focus is to making the existing system more efficient and introducing the new technologies to ease the user experience. The public which is using the ticketing system is the one who is interacting with the system on daily basis and hence, they ought to be the most significant stakeholder in this project. The total duration of the project was calculated to be 854 days starting 26th March 2019 in the schedule baseline. A critical path was identified and its duration was 525 days in order to obtain a minimum viable product. The final cost estimate of the M.I.N.T.S project totaled at $9,834,264. 16% of this figure was allocated to reserves in order to combat cost overruns, 24% for software development and 29.17% for managerial & labor costs. Function point analysis along with bottom-up costing technique and expert judgement were applied to reach this figure. The risk management plan identified several potential risks associated with this project. These risks were scored on the basis of their likelihood and impact. The triggers linked to these risks were also identified several mitigation strategies were proposed along with the designation of the people responsible for implementing these strategies. Risks such as lack of top management support were triggered by lack of communication between higher level executive and mid to low level managers. 5 other risks were also identified.

LUPA DATE: 1ST JUNE, 2019 VERSION: 1.0

Table of Contents Executive Summary ............................................................................................................................1

Glossary................................................................................................... Error! Bookmark not defined.

1. Overview ...................................................................................................................................3

1.1. Introduction ......................................................................................................................3

1.2. Purpose of the project........................................................................................................3

1.3. Historical background ........................................................................................................3

2. Initiation & Planning ..................................................................................................................5

2.1. Project Charter ..................................................................................................................5

2.2. Stakeholder analysis ..........................................................................................................6 2.2.1. Stakeholder management ..................................................................................................................... 6

2.2.2. Stakeholder analysis .............................................................................................................................. 7

2.2.3. Communication Plan ............................................................................................................................ 10

2.2.4. Summary .............................................................................................................................................. 12

2.3. Scope management plan .................................................................................................. 12

2.4. Schedule baseline ............................................................................................................ 23

2.5. Network diagram ............................................................................................................. 26

2.6. Cost management plan .................................................................................................... 37

2.7. Risk Management plan ..................................................................................................... 41

3. Overall Summary ..................................................................................................................... 46

4. Works Cited ..................................................................................... Error! Bookmark not defined.

5. APPENDIX ................................................................................................................................4 8

1


1. OVERVIEW 1.1. Introduction

Melbourne’s public transport ticketing system also known as ‘Myki’ has been active for almost 10 years and neither the public nor the systems controlling bodies have been able to answer whether the system has delivered on its various promises. Pending a performance review for over 10 years, the current system is still plagued with various issues. Using this as motivation, the following report was composed to understand the various issues and functionalities associated with the old Myki project and uses them to establish new functionalities and solutions in new ticketing system for public transport in Melbourne.

1.2. Purpose of the project The purpose of this project is to design a new public transport ticketing system for the city of Melbourne in the state of Victoria. The new ticketing system MINTS has been proposed by keeping in mind the existing functionalities as well as by introducing new functionalities that had been missing in the previous system. A multitude of PMBOK project management tools and techniques were applied in this project as well as software development methodologies like Agile and waterfall were discussed and considered while implementing the project. Agile methodology has been encompassed and the sprints were adopted for the 15 proposed solution and one of the proposed solutions would require the use of the Waterfall software development methodology.

1.3. Historical background In 2002, the Victorian Government decided to develop a new smart-card ticketing system for use on Melbourne's trains, trams and buses, and the Transport Ticketing Authority (TTA) was established to manage the implementation of the new ticketing system which was later termed as Myki‟(Victoria & Davey, 2013). After many adjournments as shown in the figure 1, Myki became fully operational, replacing the previous ticketing system, in January 2013 – five years late and $550 million over budget. (Victoria & Davey, 2013). It was anticipated that Myki would deliver around $6.3–$10.8 million per year in economic benefits to the state and its objectives included:

• enhancing the society's image of public transport • providing the best value-for-money solution at the lowest possible cost • Being operative at, or soon after Met card’s (the previous ticketing system) expiry in 2007.

(Doyle, 2015) But none of the above expectation were met rather the project suffered high losses and all the stakeholders were highly disappointed with the outcome.

2


Figure1: Timeline of the original project as shown in Victorian Auditor-General's report.

3


2. INITIATION & PLANNING 2.1. Project Charter

PROJECT TITLE: Start Date: Version control: End Date: Description: Myki is a public transport ticketing system implemented in Melbourne 2007. The project involved researching the use of the various components of the myki system and some international public transport systems including the smartcard, vending and scanning devices as well as the backend systems. Following research, a plan is to be developed to devise a replacement system in order to improve the efficiency of the system and combat its deficiencies. Project Director: Jeroen Weimar Project Manager: Syed Zohair Ahmad Project objectives: Improve real time visibility of online top-ups and other transactions on website Ability to make transactions on mobile devices using application Provide a buy back feature for existing myki-cards Provide a multi-lingual interface for registering, transactions and notifications Provide card-less compatibility for public transport scanners used on stations and by revenue protection officers Major Deliverable Schedule: Communication Plan due 09/04/2019 Scope Management Plan due 25/04/2019 Cost Management Plan due 09/05/2019 Risk Management Plan due 22/05/2019 Myki Card functionalities due 15/10/2019 Smartwatch functionalities due 27/11/19 Web browser functionalities due 15/04/2020 Integrated business intelligence dashboard due 18/05/2020 Kiosk and other device functionalities due 12/08/2020 Backend integration due 21/12/2020 Product Roll out due 13/07/2021 Critical Success Factors Clearly defined requirements Realistic delivery time frames Cross-agency coordination Clear Governance hierarchy

4

26/03/2019

15/07/2021

Myki Improved: New Ticketing System

3.0


Assumptions Sponsor for this is a Public-private partnership (Infrastructure Australia, 2019) A Myki specific mobile and smartwatch application are being developed parallelly by other groups Constraints Time constraints apply due to limited downtime at stations. Trains only stop working between 12AM and 6AM on weekdays only. Risks High amount of cross-agency communication may lead to time lost in bureaucracy Difference requirements amongst different stakeholders Lack of Communication and cooperation amongst Stakeholders

Team Members:

Planning Team Development Team A: 5 developers employed NTT Development Team B: 5 developers employed by M.I.N.T.S project Database Team: 5 administrators Contractors (Installing Team): 4 teams of 5 contractors each

Approvals Approved by the Office of the Minister of Public Transport

2.2. Stakeholder analysis 2.2.1.Stakeholder management

The term Stakeholders can be defined as the people, groups, or organizations that could impact or be impacted by the project. .(PMBoK 2013) It becomes significant to analyse stakeholder expectations and their impact on the project, and to develop fitting management policies for effectively engaging stakeholders in project decisions and execution. For the MINTS project, six stakeholders have been identified. Which consists of: Operator as Metro, Yarra trams, V-line, Ventura and all other involved parties, NTT data, PTV, suppliers, steering committee and public/passengers. A communication plan was also laid out to determine the frequency of updates to the respective stakeholders.

2.2.2.Stakeholder analysis

Table 1. Stakeholder Analysis Table

Stakehold Contact person Im Influ What is How How could

5


er

pact

e nce important to the stakeholde r?

could the stakehold er contribute to the project?

the stakeholde r block the project?

Strategy for engagin g the stakehol ders

Public/Pass engers

5 3 1. Ease of Use of the public transport system 2. Hasslefree transits

The stakehold er can provide feedback on what needs to be improved in the current system

The stakeholde r can block the project by not accepting the project implementation

Social media and dedicat ed customer service line for enquirie s and feedback

Operators Metro Trains Melbourne: Ben Barrow Ph: +61 419 505 748 Yarra Trams- Rob Robson robrobson@yarratr ams.com.au CDC Victoria - Amrullah Tadjuddin- +61 435 368 728

5 5

1.Timely implementation of the new system in order train their own staff in getting acquainted with it 2. Little to no disruption during practical application by the passengers to maintain

This stakehold er can provide insights from previous change implemen tations to help us better plan for the execution

1.Lack of communication 2. Failure in providing appropriat e replaceme nt transport during implementation

Fortnightly report through Project Manager

6


travel benchmarks (if the system disrupts the flow of people, vehicles might have to wait longer times at stops which affect profitabilit y through accrual of fines)

NTT Data Rod Mahon rod.mahon@nttdat a.com.au

5 5 1.Communication 2. Frozen core requirements 3. Brand Awareness

Provide Expertise and informatio n on the old system to improve the new one.

1. Delay in delivery of product 2. Substandard quality of product 3. Lack of communication

1.Weekly progress meetings with develop ment team and project manager 2. Emails

PTV Ashish Khurana Ph(03) 90274192 ashish.khurana@pt v.vic.gov.au

5 5 1. Transparen cy during the planning and implement ation of the project

Provide help in Policy, governanc e and quality assurance documentation

1. Change in Top management

1. Fortnigh tly report through Project Manage r 2.

7


Confere

2. Complete documentation of the new systems infrastruct ure 3. Report on performan ce benchmark for the new system

nce Calls with develop ment team and project manager

Suppliers Wristband Supplier: D.O RFID TAG company- Andrea Wong [email protected] om

3 1 1.Communication 2. Frozen core requirements 3. Brand Awareness

The stakehold er can provide hardware implementation suggestion s in order to improve efficiency

1. Delay in delivery of product 2. Substandard quality of product 3. Lack of communication 4. Change in Management

Phone calls and emails

8


Steering Committee (Sponsors + Operator Board representa tives + consultants)

Victorian treasury and finance Ph:(03) 9651 5111

5 5 1.Commun ication 2. Transparen cy during the planning and implement ation of the project 2. Complete document

1. This stakehold er as a control body to help the project stay on track and acts as an intermediary between various

1. Lack of Managem ent support 2 lack of communication

Fortnigh tly report through Project Manager

ation of the new systems infrastruct ure 3. Report on performan ce benchmark for the new system.

government organizati on and the project team

Public/Passengers

Operators NTT Data

PTV Steering Committee

(Sponsors + Operator Board representatives + consultants)

Suppliers

Importance

High

9


Low Influence High

Figure2: Stakeholder matrix

2.2.3.Communication Plan A communication plan is a course of action or an approach to providing stakeholders with information. The plan formally defines who should be given specific information, when that information should be delivered and what communication channels should be used to deliver the information. A poorly initial planning resulted in myki original scope and contract being vaguely specified and overly ambitious. (Doyle, 2015) Figure 3 illustrates the communication plan table, listing out all the methods of communicating with the various stakeholders involved

WHAT WHO WHEN HOW

Steering Committee report

Manager/stakeholders Every Week on

Monday

By emails and attend meetings

Supplier/subcontractor relation

Planning team When

necessary calls, email

Software development progress

IT specialist (Team lead) Fortnightly

Meeting (face to face)

10


Website Development progress

IT specialist (webdevelopment team lead)

fortnightly Emails, conference calls every fortnight to discuss the development, Monthly meeting.

Mobile Application update

Stakeholders/ Project manager

fortnightly Emails, conference calls every fortnight to discuss the progress, Monthly meeting

Change in requirement Project manager (approvals for new resources)

As per requirement of the project

Meetings, conference calls

Budget Allocation Project Manager Monthly Monthly Meetings

Overall Project Update Project Manager(update

information to stakeholders) Monthly

Monthly meetings, emails

Table 2: Communication Table

2.2.4.Summary Stakeholder management plays a crucial role towards the project success. The stakeholder analysis identifies the major stakeholders in the project and their role and responsibilities toward the project moreover, with the help of the stakeholder matrix we were able to determine how crucial a particular stakeholder is for the current project and how they impact the project. Since, we have lot of stakeholders in our current project it’s vital to keep all of them on the same page and making sure that every project deliverables and changes are being communicated to all the stakeholders involved on time.

2.3. Scope management plan

2.3.1. Definition

11


As per Schwalbe (2013) the project scope management include the procedures to define what works and what doesn't not work for the success of the project. Some of the vital procedures used in managing the scope of a project are - collecting requirements, defining scope, creating a Work breakdown structure based on the collected requirements. This is followed by verification of scope to prevent scope creep. Following this a change control strategy is drafted in order to provide a template for the flow of activities in order to make any changes in regards to elements concerning the scope of the project. For this project specifically, the ticketing system consists of three main elements. These are:

• The RFID smart card / Wristband • the device interacting with the smart card (card readers, kiosk) • Backend (A database, servers on which the system runs)

The above three elements together constitute the project scope because a ticketing system based on IT infrastructure would not function without these three elements interacting with each other. The Product scope for our project is centred around the RFID smart card. Most of the functionalities will involve the use of an RFID devices in the form of a smart card or a wrist band

2.3.2. Requirement collection Collecting requirement is the process of determining, documenting, managing stakeholder needs and requirements to meet project objectives. The key benefit of this process is that it provides the basis for defining and managing the project scope including product scope. Various ways to approach the potential stakeholders were considered, emailing is one of them. Stakeholders like PTV and NTT data has been contacted and a thorough research was conducted, the QA forums of the websites of the companies were also referred in order to get the clearer idea about the requirements, and the key issues or queries that the customer usually face or complain about.

2.3.3. Requirements table

Stakeholder Requirements Nonfunctional (NF) Functional (F)

PUBLIC/PASSENGER Ease in Loading Myki cards using web browser

F01: Online Top-up

Balance Check capability F02: Check Balance

Service notification updates F03: Service Notifications

Travel/ Trip History logs F04: Trip History

Auto -top up when balance is low

F05: Direct Debiting (Auto top-up)

Capability to return the card whenever desired

F06: Buyback

Wristband for differently abled passengers

F07: RFID Wristband

12


Capacitive touch display on kiosk for quick response

F08: Intuitive touch display

Quick response for RFID scan F09: Faster card Scanning Time

Virtual travel card F10: Integration with other smart devices

Trip planning F11: Trip Planning

NF01: Data Security

NF02: Card-less Compatibility

NF03: Multi-Lingual accessibility

NF04: Reusability

NF05: Reliability

NF06: Flexibility

OPERATORS Fast card scanning F09: Faster card Scanning Time

NTT DATA Communication between developers and client

NF07: Communicability

PTV Efficient performance F12: Operational performance dashboard


Steering Committee Transparency and regular communication

NF: Accountability


SUPPLIER/ SUBCONTRACTORS


Table 3. illustrates the requirement table lists the key stakeholders and their requirements and classifies them into functional and non - functional columns

Following up on the above table, the table below illustrates the Nature of change and the existing and non - existing requirement/features of the current system

13


Functional (F)/Non-function

(NF)

Explanation Gap/Existing Nature of Change

F01: Online Topup Passengers require the ability to load their Myki cards with

convenience using a web browser available on any electronic device

with an internet connection

Existing

F02: Check Balance

Passengers need to be able to check the balance on their travel Card. This should be available at points of contacts like kiosks and scanners but also on the website

and mobile devices

Existing

F03: Service Notifications

Passengers require notifications of any disruptions happening in their

travel service or potentially affecting their travel

Existing

F04: Trip History Passengers need to be able to trace their travel footprint with their travel card across specific

dates

Existing

F05: Direct Debiting(Auto top-

up)

Passengers require an auto top-up functionality to make sure their

travel cards don't run out of funds. By choosing this option

they can set up a direct debit link once their cards dip below a

specified limit.

Existing

F06: BuyBack Passengers require a framework and mechanism for returning their

travel cards once they are done with them. The require a refund for the cards registered to them.

Gap The Myki card in current use does not have this

functionality. It costs 7$ to buy the card itself. In

essence, if a passenger loses their card, they lose an extra

7$.

14


F07: RFID Wristband

Disabled Passengers requirement a convenient form of ticketing.

Gap The wristband is changed form of Myki card more suited towards disabled people. It has the same

mechanism as the card but can also be used as

identification for disabled people.

F08: Intuitive touch display

Passengers require fast conducive touch screens to use functions provided by the Ticketing kiosk

Existing

F09: Faster card Scanning Time

Passenger require fasting card scanning times on the kiosks as

well as the tap-on/off points

Gap The current scanning devices are notorious for long

scanning times. A machine update with more sensitive scanners and new and NFC

capabilities

F10: Integration with other smart

devices

Passengers require the use of mobile device like their cell

phones and smartwatches as virtual travel cards

Gap Currently, there are no ways to use public transport

without a physical travel card. The development of a virtual card will definitely

increase convenience.

F11: Trip Planning Passengers require the ability to plan trip using their travel cards to

increase cost efficiency

Existing

NF01: Data Security

Existing

NF02: Card-less Compatibility

Existing

NF03: Multi-Lingual

accessibility

Existing

NF04: Reusability Existing

NF05: Reliability Existing

NF06: Flexibility Existing

15



The developers require a streamlined communication

channel with client in order to properly implement requirements and changes as necessary with the

least amount of time lost

Existing

F09: Faster card Scanning Time

To streamline with flow of passengers in and flow out

vehicles and stations, operators require a faster scanning time

Gap

F12: Operational performance

dashboard

PTV requires accurate performance dashboard and report generation capabilities

Gap Currently, the dashboard in existence in wildly

inaccurate, evidence by the Auditor-General. The new

dashboard will be coded and integrated with the back-end to compute data using cloud

business intelligence capabilities

NF8: Accountability

The steering committee requires complete document of the

happenings of the project in a timely manner

Gap As evidenced by the Auditor-General, Accountability was

major weakness of the previous project. With

proper documentation and timely reporting, the proposed project will

improve accountabilities

Table 4. illustrates the Nature of change and the existing and non - existing requirement/features of the current system Proposed functionalities On the basis of collected requirements, a few solutions have been proposed for the ticketing system as follows:

• RFID Wristbands : RFID stands for Radio frequency identification as it automatically identifies and track tags attached to objects. In order to mitigate the hassle of carrying the Physical card the RFID wristbands functionality can be considered as the valid option. It has a memory chip and coil radio antenna which can store information such as credit card details and cash credit remaining on the wristband. The wristbands are mainly marketed towards groups and disabled people. Using the personalization feature, specific disabled people can be provided with RFID wristbands of specific colours or logos. They will be able to top up their wristbands using the kiosks as the kiosks will also feature a braille keyboard to input money values. This feature works only with debit/credit card payment method.

16


Figure 3: Depiction of RFID Wristbands • Single token ticket: One of the major promises of the original Myki project, rescoped out of the

project due to cost overruns. This functionality focuses on the long going issues of spending money in order to buy a new myki card and then again paying for travelling to specific location. By considering the scenario when the passenger wants to travel to only a specific station and doesn’t want to carry a physical card all the time. The Single token ticket can prove beneficial here, the passengers could save the extra money that they were spending and the token can be dropped off once the passenger gets out of the station. The token itself can be used to promote various brand from sponsors who choose to advertise with Myki. This improves brand awareness. This very idea has been inspired from the Delhi metro token system.

Figure 4: Illustration of Single token

• Buyback: Buyback functionality refers to the ability of the consumers to exchange their old myki cards after they expire with new myki cards. Each Card has a validity of 2 years from purchase date. This functionality is necessary because under the current system, a new card has to purchase after expiry, which is an additional $7.00.

• Smartwatch as Myki: This functionality focuses on making personal smartwatches capable of acting as a virtual myki card. After the myki card has been registered to an individual, the card number can be input on a smartwatch Myki application which is being developed in

17


parallel (Assumption: Myki mobile and Smartwatch application is being developed simultaneously in another project or by another group).

• Business Intelligence Dashboard: The integrated business intelligence dashboard would the provide PTV a holistic view of all operations by all service providers against benchmarks set by the steering committee. In addition, the dashboard would also provide information on equipment metrics such as average tap-on, tap-off time, equipment failure frequency etc. This information would be used to forecast equipment maintenance checks well in advance further saving operational costs for all stakeholders

• Personalization and its purchase: The wristbands will be available for purchase online with a

design simulator to view different options for personalization. The wristband would then be available for purchase using debit/credit cards or PayPal.

• Various Top-ups: There are basically three top up options available - auto top up, mobile top up and website top up. we are assuming that another group is carrying out the task of developing the mobile application. Hence, top up option for mobile application has been provided as well. Auto top up feature works once the user registers and links their banks accounts with the Myki card account online.

18


Figure 5: Kiosk • Multilingual accessibility: Melbourne has the diversity of population and people from different

cultural background are all around. By introducing multilingual feature in the kiosk system and website the passengers get the option to select the language that they are comfortable using. some people refrain themselves from using latest technology because of language restriction, this feature can help in attracting more passengers for the new ticketing system.

• Customer register online : The passengers should get the option of registering online for the card that they are carrying which will help them in the worst-case scenarios like loss of card and by doing the registration the registered passenger can always get the new card without having to pay for it again.

• Real-time updates: One major issue plaguing the current system is its inability to provide PTV or its customers with real time updates on transactions carried out using the Myki card. On further research, the root cause of this problem was to originate due to the distribution of servers and their communications protocols. According to the Auditor-General's report (2014) and again in (2017), it was identified that the service providers for bus routes only communicated Myki transactions once each month. Train and trams transactions also would not display for customer travel history for 48 hours to 2 weeks at a time. This proposed solution to this problem is the use of Amazon Web Services, specifically their cloud services and their analytical suites, specifically Amazon Greengrass and Amazon Lambda to act as data warehouse collecting data on

19


demand from the servers of service providers as well as PTV, and provide business intelligence insights using Amazon Greengrass SaaS.

• Improve Scanning time: Through tests carried out by the reporting team, it was found that scanning times were very and the equipment was old and often malfunctioning during peak periods. New updated and more ergonomic devices were identified with suppliers and are proposed for ordering.

• Receipt generation: The current kiosks print receipts regardless of whether the customer chooses not to. This facilitates wastage of paper and time because the smart card or device does not finish coding the monetary value until the receipt is printed. This feature has to be completely redesigned. As a proposed solution, the bugs causing this issue will need to be fixed and and added option of E-receipts would be provided for registered customers. Registered customers are those who have registered their Myki cards online.

• NFC Enabled Devices: NFC stands for near field communication. It is a wireless technology that allows a device to collect and interpret data from another closely located NFC devices. In terms of this project NFC has been used in the wrist bands and smartwatches which could allow the instant payment and better user experience. Moreover, NFC enabled devices are more secure than any magnetic strip of regular credit card.

2.3.4. Work breakdown structure The Work breakdown structure (WBS) acts as a tool to distinguish between various levels of a project and the tasks associated with them. It provides a logical framework to monitor the flow of activities and order of implementation of all the tasks in a project (Tausworthe 1979).

20


Figure 6. Work Breakdown Structure

2.3.5. Control scope

Change control is something that cannot be prevented even among the most successful projects. Projects are prone to changes and strangely enough, lack of change control is one of the biggest hurdles for the project to be successful.

21


Change Control is a formal process. It is used by the project teams to modify the scope of the project using specified controls and policies. Project change can include anything that would impact the success of a project for example time, budget, scope and all other constraints which can impact the success of the project. Cathlynn Carman. (2013) Most of the time, it is the change request that impacts the other items. It is always beneficial to have a change request in hand in order to approve the changes that were

requested. Following are the steps that need to be followed in order to make sure that the changes are managed properly.

Define the change request: Actual Request: Statement of need, this should include the change requirements. This task will be

carried out by the project team. Reason for the Request: Whenever a requirement arises. For instance: Customer gets impacted

negatively if the changes are not made. Expected completion: The change request should provide an expected date for completion.

• Create a Response Document If the impact of the change has a positive impact on the project, request for change (RFC) is made as shown in figure 7 and send to all the

stakeholders. RFC contains all the details about the project drawbacks in the current one and how the new change will benefit the project. Team should include the

following details in the RFC: • Proposed Solution

22


• Expected Completion Date • How it impacts the project

• Approvals required • Submit and review the change request: Once the change for request has been put

forward it is the project manager who updates the information to the stakeholders. The changes can be approved or rejected for further review, which might delay the

project.

• Final decision and Approval

Stakeholders or the impacted parties should provide timely response if the RFC expires or needs to be re-evaluated. The final decision of approval or rejection should be officially provided by the manager, stakeholders or by the members of the top management.

2.3.6. Summary Scope management includes all the work required for the successful completion of the project. In this section, Requirements were gathered from the identified stakeholders using various means. These requirements were later classified further into functional and non-functional requirements. Following this, a primary Work breakdown structure was drafted using lucid chart, an online illustration tool. Simultaneously a change control process was also drafted to provide a template for making changes to any element affecting scope. Also included in this section were - the proposed functionality solutions in order to satisfy stakeholder requirements and their brief explanation. This was done to better communicate the thought process of the reporting team

2.4. Schedule baseline

2.4.1. Schedule baseline and Importance A schedule baseline is the original approved project schedule, which is agreed by project stakeholders before the project starts. It does not change. It is a fixed measure which is used as a planning yard mark against which the progress on the actual project schedule can be measured. This is done after the activities of scope management plan. After the Work breakdown structure is drafted, a schedule baseline is composed on the tasks and subtasks identified in the work breakdown structure. schedule baseline will include the expected time required for delivering the project. It is vital to have schedule baseline defined for the project in order to track down whether all the work is being done as per the laid-out schedule baseline. It is used to estimate what resources are required, at what time they are required and for how long they are required. In order to achieve project success, it is important for the project manager to make sure that necessary schedule management strategies have been followed. It also helps in identifying how long the project is going to take. While developing the schedule baseline tools such as excel and Gantt chart can prove beneficial as they help in planning the tasks properly and gives all the related information like critical paths and dependent and nondependent tasks.

“A study from Stanford University found out that people who work more hours (more than 55 hours per week) do not actually get more done than those who work less than that.”(Perceval, 2014) Here are some methods to manage time more efficiently:

• Avoiding interference • Prioritizing the tasks and completing them as per set priorities • Estimating and tracking time accurately • Creating a schedule

23

Figure 7: Change Control Process


24


2.4.2. Schedule Baseline As per the schedule baseline, the project started on 26th of March 2019 and has a duration of 854 days.

Figure 8. Schedule Baseline


24

Milestone Table

The Milestones of this project are identified in the table below Task Name Milestone

New Myki Ticketing System Project

1.Initiation

1.3 Project charter sign off Yes

2.Planning

2.2 Develop Communication Plan Yes

2.3 Scope management plan

2.4 Network Diagram Yes

2.5 Cost mangment plan Yes

2.6 Risk Mangment Plan Yes

3.Execution

3.1 Myki card

3.1.2 Sprint 1 (Auto Top Up ) Yes

3.1.3 Sprint 2 ( Mobile top-up) Yes

3.1.4 Sprint 3 (NFC capabililty) Yes

3.1.5 Sprint 4 (Real-time update) Yes

3.1.6 Sprint 5 (Buyback): Yes

3.1.7 Sprint 6 (Multi Lingual accessablility): Yes

3.2 Smart Watch Application

3.2.1 Sprint 7 (Working touch display): Yes

3.2.1.6 Sprint review Yes

3.2.2 Sprint 8 (NFC capability ): Yes

26



3.3 Specific features for online users using a web browser

Yes

3.3.2 Sprint 9 ( Online Top-up): Yes


3.3.3 Sprint 10 ( Real- Time updates ): Yes


3.3.4 Sprint 11 ( Customise wearables option): Yes


3.3.5 Sprint 12 ( Purchase Wearables feature) Yes


3.4 Dashboard Yes

3.5 Kiosk and other Devices

3.5.1 Sprint 13 : Improve Scaning Time: Yes

3.5.1.1 Feature design Yes

3.5.1.6 Report to Steering committee Yes

3.5.2 Sprint 14 : Reciept Generation Options: Yes

3.5.2.1 Feature design Yes

3.5.3 Sprint 15: Wrist band: Yes

3.5.3.4 Final Testing Yes

3.5.3.5 Report to Steering committee Yes

3.6 Backend Integration Yes

3.6.6 Final Backend integration with application Yes

3.7. Testing Yes

3.7.1 Requirement Testing Yes

3.7.2 Load Testing Yes

3.8 Training & Roll out

27


3.8.5 Product Installation Complete Yes

5 Closing

5.1 Create Closing Report Yes

Table 5. Milestone List Table

SDLC methodology and Approach

The project is using the Agile SDLC methodology there are lot of benefits of adopting this methodology. The Agile methodology is contemporary Software development approach and it’s flexible in terms of requirements as in Agile, the product owner puts scope into product backlog, the development team pulls the scope out of the product backlog and deliver them. “The Product Backlog is a list of things that are in scope for this project and must be delivered within the approved period and budget or else the project can fail.” (leontranter 2019) The current project is basically comprising of 15 sprints and each sprint is being delivered in 30 to 35 days. The Development of dashboard has also been proposed, since there is no interdependency between the development of dashboard as the other sprints therefore, the waterfall methodology has been considered for that very part.

2.4.3. Summary On the basis of the work breakdown structure designed in the section 2.3, A Schedule baseline was constructed on MS-Project. All the tasks were automatically scheduled with the project starting on 26th March 2019 and the project charter being signed off on 2nd April 2019. The Execution of the Project would begin on 3rd June 2019 and the Project would close 15th July 2021. The duration of the whole project is 854 days. A milestone table was also provided to view specific milestones for better understanding.

2.5. Network diagram

2.5.1. Definition and Importance

Network diagram is a schematic display of the project’s activities and the logical relationships among them. Network diagram in project management is useful for planning and tracking the project from beginning to finish. It represents a project’s critical path as well as the scope for the project.

Importance of network diagram:

• Network diagram helps justify the time estimate for the project • Network Diagrams aid in planning, organizing and controlling • Network diagrams show interdependencies of activities. • Network Diagrams show the workflow of the project activities.

28


• Network diagrams identify opportunities to compress the schedule. • Network diagrams show project progress.

2.5.2. Network Diagram

Figure 9. Critical Path Activity on Node diagram

2.5.3. Legend of Network Diagram

29


TASK CODE

Task Name

New Myki Ticketing System Project

A 1.Initiation

1.1 Develop Project Charter

1.2 Review Charter

1.3 Project charter sign off

B 2.Planning

2.1 Stakeholder analysis

2.2 Develop Communication Plan

C 2.3 Scope management plan

2.3.1 Define Scope

2.3.2 Collect Requirements

2.3.3 Categorize functional/non-functional requirements

Scope sign off

D 2.4 Network Diagram

E 2.5 Cost mangment plan

F 2.6 Risk Mangment Plan

G 3.Execution

H 3.1 Myki card

3.1.1 Requirments review

I 3.1.2 Sprint 1 (Auto Top Up )

30


3.1.2.1 Feature design

3.1.2.2 Feature development

3.1.2.3 Test& debugging

3.1.2.4 Modification

3.1.2.5 Sprint review

J 3.1.3 Sprint 2 ( Mobile top-up)






3.1.3.6 Report to Steering committee

K 3.1.4 Sprint 3 (NFC capabililty)






L 3.1.5 Sprint 4 (Real-time update)



31






M 3.1.6 Sprint 5 (Buyback):






N 3.1.7 Sprint 6 (Multi Lingual accessablility):







O 3.2 Smart Watch Application

P 3.2.1 Sprint 7 (Working touch display):



32






Q 3.2.2 Sprint 8 (NFC capability ):







R 3.3 Specific features for online users using a web browser

S 3.3.1 Requirements review

T 3.3.2 Sprint 9 ( Online Top-up):






U 3.3.3 Sprint 10 ( Real- Time updates ):


33







V 3.3.4 Sprint 11 ( Customise wearables option):







W 3.3.5 Sprint 12 ( Purchase Wearables feature)








X 3.4 Dashboard

34


3.4.1 Feature design

3.4.2 Feature development

3.4.3 Test& debugging

3.4.4 Modification

3.4.5 Sprint review

3.4.6 Report to Steering committee

Y 3.5 Kiosk and other Devices

Z 3.5.1 Sprint 13 : Improve Scaning Time:







AA 3.5.2 Sprint 14 : Reciept Generation Options:







35


AB 3.5.3 Sprint 15: Wrist band:

3.5.3.1 Requirement review

3.5.3.2 Order prototype batch


3.5.3.4 Final Testing


AC 3.6 Backend Integration

3.6.1 Database Design

3.6.2 Build Database and add constraints

AD 3.6.3 cloud servers

AE 3.6.3.1 Host Server

3.6.3.1.1 Rent Amazon Web Server (AWS)

AF 3.6.3.2 Infrastructure

3.6.3.2.1 Lease Software as a service(SaaS)

AG 3.6.4 On-premise Server

AH 3.6.4.1 Hardware Requirement

3.6.4.1.1 Memory

3.6.4.1.2 Processor

AI 3.6.4.2 Network Requirement

3.6.4.2.1 Application Object Service

3.6.4.2.2 Domain Requirement

36


3.6.4.2.3 Network Testing

3.6.5 Modifications

3.6.6 Final Backend integration with application


AJ 3.7. Testing

3.7.1 Requirement Testing

3.7.2 Load Testing


AK 3.8 Training & Roll out

3.8.1 Training


3.8.3 Product Roll Out

3.8.4 Product Installation Begins

3.8.5 Product Installation Complete



AL 4.Monitoring and Controlling

4.1 Scope Validation

4.2 Schedule Control

4.3 Integrated Change Control

4.4 Risk Monitoring & Control

37


AM 5 Closing

5.1 Create Closing Report

5.2 Project closing Meeting

Extra Reporting Schedule

Report to Steering committee





Table 6. Legend of Network Diagram

2.5.4. Critical Path Critical path is the shortest amount of time taken to complete the amount of work required to achieve a minimum viable product. Critical path is identified as the pink path in Figure 9. The MS-project version can be viewed in the Appendix.

2.5.5. Summary Using the Schedule baseline Gantt chart constructed in section 2.4, A critical path ‘activity on node’ diagram was designed to reflect this using an online Illustrator- Lucidchart. The critical path was identified and its duration is 525 days in order to obtain a minimum viable product. The MS-project version can be viewed in the Appendix.

38


2.6. Cost management plan

2.6.1. Significance of Cost management plan

Cost is one of the primary elements in the triple constraints associated with project management. It is concerned with the cost of the resources needed to complete the activities listed in the project. A cost management plan is essential for the successful execution of a project. With the help of a cost management plan, project managers can forecast costs for a variety of ways and identify cost intensive activities during different periods. A cost management plan is a very useful tool in analyzing different costs associated with various entities and plays a vital role in the monitoring and controlling processes.

2.6.2. Costing Calculations and Table

Table 7: Function Point Complexity Calculations Table 8: VAF Table Scale for Function point Analysis

Complexity Calculations

Category # of Low

Weight # of Average

Weight

User Inputs

4 3 8 4

User Outputs

2 4 10 5

User Inquiries

8 3 12 4

Files/ Structures

2 7 9 10

External Interfaces

1 5 2 7

Value Adjustment Factor Scale

No effect 0 Incidental 1 Moderate 2 Average 3 Significant 4 Essential 5

Table 9: Value adjustment Score for Function Point Analysis

# General System Characteristic

Brief Description VAF

1 Data communications

Are data communications required? 5

2 Distributed data processing

Are there distributed processing functions?

39


3

3 Performance Is performance critical? 4

4 Heavily used configuration

Will the system run in an existing, heavily utilized operational environment?

5

5 Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.?

5

6 On-Line data entry Does the system require on-line data entry? 3

7 End-user efficiency Was the application designed for end-user efficiency? 3

8 On-Line update Does the on-line data entry require the input transaction to be built over multiple screens or operations?

4

9 Complex processing Does the application have extensive logical or mathematical processing?

4

10 Reusability Was the application developed to meet one or many user’s needs? 4

11 Installation ease How difficult is conversion and installation? 4

12 Operational ease Does the system require reliable backup and recovery? 5

13 Multiple sites Is the system designed for multiple installations in different organizations?

3

14 Facilitate change Is the application designed to facilitate change and ease of use by the user?

5

VAF score 57

Table 10: Cost Estimate Table # Units/Hrs. Cost/Unit/Hr. Subtotals WBS Level 2 Totals % of Total

WBS Items

1. Project ManagementAUD 2,860,400.00 29.09%

Project Manager 2604 AUD 100.00

AUD 260,400.00

Planning Team 3028 AUD 150.00

AUD 454,200.00

Development Team A 2586 AUD 300.00

AUD 775,800.00

Development Team B 2384 AUD 300.00

AUD 715,200.00

Database Team 1270 AUD 240.00

AUD 304,800.00

Contractors (Installing Team) 500 AUD 700.00

AUD 350,000.00

2. Hardware

Devices # of Unit Cost/Unit AUD 2,672,238.00

27.17%

40


Ticket Vending Machine 250 AUD 5,000.00

AUD 1,250,000.00

RFID Cards 3500000 AUD 0.10

AUD 343,000.00

RFID Wristbands 1000000 AUD 0.18

AUD 180,000.00

Bus Terminals 3460 AUD 250.00

AUD 865,000.00

Servers AUD 34,238.00 AUD 34,238.00

3. SoftwareAUD 2,404,620.00 24.45%

Software development AUD 2,404,620.00

4. Testing AUD 240,462.00

2.45%

5. Training and Rollout # Units/Hrs. Cost/Unit/Hr.

Marketing Team 700 AUD 30.00

AUD 21,000.00

AUD 21,000.00

0.21%

6. Reserves AUD 1,635,544.00

AUD 1,635,544.00

16.63%

Total project cost estimateAUD 9,834,264.00

100%

Table 11: Cost Baseline Tables for the duration of the Project (Monthly) WBS Items 1 2 3 4 5 6 7 8 9 10 11 12

1. Project Management

Project Manager $ 4,989.18 $ 23,971.00 $ 2,571.00 $ 2,971.00 $ 2,371.00 $ 3,171.00 $ 3,171.00 $ 2,571.00 $ 5,371.00 $ 3,771.00 $ 2,571.00 $ 2,971.00

Planning Team $ 9,843.23 $ 17,371.00 $ 2,671.00 $ 2,371.00 $ 2,371.00 $ 2,371.00 $ 2,371.00 $ 2,371.00 $ 5,971.00 $ 2,371.00 $ 2,371.00 $ 2,371.00

Development Team A $ 22,200.00 $ 65,400.00 $ 57,600.00 $ 18,600.00 $ 76,200.00 $ 64,800.00 $ 11,400.00 $ 76,200.00 $ 57,600.00 $ 18,600.00

Development Team B $ 11,400.00 $ 76,200.00 $ 57,600.00 $ 18,600.00 $ 76,200.00 $ 64,800.00 $ 11,400.00 $ 65,400.00 $ 43,200.00 $ 76,200.00

Database Team

41


Contractors (Installing Team)

2. Hardware

Devices

Ticket Vending Machine

RFID Cards

RFID Wristbands

Bus Terminals

Servers

3. Software

Software development $160,308.00 $160,308.00 $160,308.00 $ 160,308.00 $ 160,308.00 $ 160,308.00 $160,308.00 $160,308.00 $160,308.00 $160,308.00 $160,308.00 $160,308.00

4. Testing $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25

5. Training and Rollout

Marketing Team

6. Reserves(20% of Total estimate)

$ 58,413.00 $ 58,413.00 $ 58,413.00 $ 58,413.00 $ 58,413.00 $ 58,413.00 $ 58,413.00 $ 58,413.00 $ 58,413.00 $ 58,413.00 $ 58,413.00 $ 58,413.00

WBS Items 1 2 3 4 5 6 7 8 9 10 11 12


Project Manager $ 3,171.00 $ 4,171.00 $ 3,371.00 $ 2,771.00 $ 2,371.00 $ 2,571.00 $ 3,771.00 $ 2,771.00 $ 2,571.00 $ 2,771.00 $ 2,371.00 $ 2,571.00

Planning Team $ 2,371.00 $ 3,571.00 $ 3,571.00 $ 2,371.00 $ 40,471.00 $ 2,371.00 $ 4,771.00 $ 2,371.00 $ 23,971.00 $ 2,371.00 $ 2,371.00 $ 2,371.00

Development Team A $ 65,400.00 $ 21,600.00 $ 56,400.00 $ 45,600.00 $ 36,000.00 $ 43,200.00

Development Team B $ 43,200.00 $ 53,400.00 $ 57,600.00 $ 12,000.00 $ 43,200.00

Database Team $ 30,480.00 $ 30,480.00 $ 31,680.00 $ 52,380.00 $ 34,560.00 $ 30,480.00 $ 60,960.00 $ 30,480.00


2. Hardware

Devices

Ticket Vending Machine $ 1,250,000.00

RFID Cards $ 343,000.00

RFID Wristbands $ 180,000.00

42


Bus Terminals $ 865,000.00

Servers $ 33,238.00 $ 1,000.00

3. Software

Software development $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00

4. Testing $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25

5. Training and Rollout

Marketing Team $ 43,200.00

6. Reserves(20% of Total estimate) $ 66,941.86 $ 66,941.86 $ 66,941.86 $ 66,941.86 $ 66,941.86 $ 66,941.86 $ 66,941.86 $ 66,941.86 $ 66,941.86 $ 66,941.86 $ 66,941.86 $ 66,941.86

43

WBS Items 1 2 3 4 Totals


Project Manager $ 2,571.00 $ 3,171.00 $ 2,371.00 $ 3,371.00 $ 107,206.18

Planning Team $ 2,371.00 $ 2,371.00 $ 2,371.00 $ 5,071.00 $ 159,960.23

Development Team A $ 45,000.00 $ 4,800.00 $ 786,600.00

Development Team B $ 4,800.00 $ 715,200.00

Database Team $ 3,840.00 $ 305,340.00


$ 87,500.00 $ 87,500.00 $ 87,500.00 $ 88,900.00 $ 351,400.00

2. Hardware $ -

Devices $ -

Ticket Vending Machine $ 1,250,000.00

RFID Cards $ 343,000.00

RFID Wristbands $ 180,000.00

Bus Terminals $ 865,000.00

Servers $ 34,238.00

3. Software $ -

Software development $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 40,077.00 $ 2,564,928.00

4. Testing $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 10,019.25 $ 250,481.25

5. Training and Rollout $ -

Marketing Team $ 75,000.00 $ 30,000.00 $ 30,000.00 $ 4,800.00 $ 183,000.00

$ -

6. Reserves(20% of Total estimate)

$ 58,413.01 $ 58,413.00 $ 58,413.00 $ 58,413.00 $ 1,737,910.34

Grand Total $ 9,834,264.00 $ 9,834,264.00


The Final Cost matches for both the cost estimate table and cost baseline table. The costs illustrated in these tables might not match the costs calculated in the schedule baseline. This is because the Schedule baseline does not account for reserves.

Table 12: Software Development Estimate Software Development Table

Labor Estimate Unit/Hours Cost/Unit/Hours Subtotals Calculations

Designation

Project Manager 1000 AUD 800.00

AUD 800,000.00

Developers 1000 AUD 600.00

AUD 600,000.00

2 teams of 5 developers each

Total Labor Cost AUD 1,400,000.00

Function Point Estimate

Total Function Points 1068.72 Calculated from section above

Source Line of Code Estimate (SLOC)

46428 See reference

Market standard cost/function point

AUD 150.00

No of Sprints 15

Total Software Cost AUD 2,404,620.00

(Total FP estimate * # of Sprints)

2.6.3. Costing Method Justification

To calculate the costs associated with this project, function point analysis, expert judgement and bottom-up techniques were applied. Bottom-up costing is a technique in which the individual costs associated with each task are estimated and then total of all the tasks in the project is calculated to achieve an overall project cost estimate. Function point analysis (FPA) is a tool used to estimate the development costs associated with software development. It calculates the number of function points in a single functionality. To measure the number of function points, complex calculations on the basis of qualitative and quantitative factors need to be carried out such as User Inputs, User Outputs, User Inquiries, Files/Structures and External Interfaces (See table. 6). Then, some adjustments need to calculated by scoring on 14 general characteristics to achieve a VAF score (See table 7 and table 8). Using the following equation, the total adjusted measure of function points for a single is functionality is calculated: -

Unadjusted Function point score*(VAF score*0.01+0.65)

44


Using Expert Judgement, information from an industry expert from Monash University was sourced for cost of developing one function point, which is AUD 150/function point. Using these 3 techniques, a thorough cost analysis was performed. These costing methods were preferred as opposed to others because of the following factors: - • There are too many tasks for top-down costing

• Industry knowledge is readily available • Function point analysis is a tried and tested method renowned since the 1970’s

2.6.4. Summary Using the function point analysis tables, adjusted number of function points was calculated. Using the VAF table, a VAF score was achieved. Using the specified the equation, the total number of function points was 1068.72 units. Multiplying this number with the industry standard ($150), total cost of developing one function point was calculated. Since there are 15 functionalities, The cost of functionality was multiplied with 15 to achieve a total software development cost which is $2,404,620. This occupies a little more than 24% of the total project cost estimate. The various managerial and labor costs account for 29.1% of the total estimate and Hardware costs account for 27.17% for the same. There is a reserve for the project in case of cost overruns which is allocated at 16.63% of the total estimate (approximately 1/6th of the total value).

2.7. Risk Management plan

2.7.1. Definition and Importance of Identifying Risk

Risk management is one of the most important knowledge areas in Project management. Software projects are high risk activities, generating variable performance outcomes (Charette, 2005). Industry surveys suggest that only about a quarter of software projects succeed outright and billions of dollars are lost annually through project failures or projects that do not deliver promised benefits. (Bannerman, 2008)

Risk management is more than a process or methodology, it is also a real-time threat management capability that is developed within an organization, through learning, practice, and other mechanisms, over a long period of time. (Bannerman, 2008). Risks can cause instability in the project and can even shatter the three constrains in a great way. Risk identification allows you to create a comprehensive understanding that can be leveraged to influence stakeholders and create better project decisions. {Brown, #28} Identifying the risks is the part of the identification process, if not identified on time, risks can create a great deal of chaos for project manager. Most importantly one can’t manage something one is not aware of, so it becomes a proactive approach for the project manager to identify the risks to help the project in running smoothly.

Risk register is the tool used by the project manager in order to identify the potential risks in a project. The project manager maintains a risk register listing out the high risks or the potential ones and use the same data to show it to the steering committee. It is vital tool as it helps the manager to keep the

45


track of the potential risk that may arise and helps the manager to prepare the way outs and the strategies to tackle the future potential risks.

IMPACT

LIKELIHOOD Insignificant (1) Minor (2) Moderate (3) Major (4) Extreme (5)

Rare (1) Low Low Low Low Low

Unlikely (2) Low Low Low Medium Medium

Possible (3) Low Low Medium Medium Medium

Likely (4) Low Medium Medium High High

Almost certain (5) Low Medium Medium High Extreme

Figure 10: Impact and Likelihood Matrix

2.7.2. Risk Register table

No

Risk

Name Description/Trigg

er Likelihood

Impact to the Proj

ect

Total Ris k Score

Risk class (see legen

d)

Risk control/mitigation Strategies

Risk monitoring

measures Impact to the triple constrai

nts

Risk owners

1 Lack of Top manage ment

support

Lack of top management is when the higher management stops providing support

2 3 6 Low 1.Selecting the experienced and mature candidate for managing the project 2.Making sure

1.Making sure that the top management team is actively participating in the meeting

Time: Increase d if the resourc es are not

Project

Manager

46


(financial/organiz ational). This could result into project failure; employee’s productivity may fall down since they will have to wait for the top management approval for making changes

there is full engagement of the top management in the project

2.Making sure that fully engaged throughout the project life cycle.

adequat ely provide

d for Quality: may not be support

ed

and proceeding with the project development Trigger: .lack of communication between higher management and mid-level and lower level

personnel.

2.

Inadequate requirem ent

gathering

Trigger: Not having the clear functional and nonfunctional requirements from the client end and

stakeholders

4 4 16 High 1.We have to make sure that we gather the requirements by conducting interviews with the potential stakeholders 2.Project charters need to be maintained and timely updated as per the requirements

1.Regularly analyze and go through the requirement gathering

techniques. 2.Following the project guidelines

Scope: The scope of the project may begin to

vary

Project

manager

3.

Improper Task Planning

Not been able to carry out the planning, testing, tracking and reporting of project Trigger: 1. Improper requirement

gathering 2.Poor time

management

3

3 9 Medi um

High

1.laying out the requirements properly 2.Assigning the roles to all individual and getting routine update on it.

1.Utilizing the entire workforce and assigning them the right amount of task. 2.Receiving regular updates and monitoring their task progress

Time and Cost can get impacted if the proper task planning is not carried

out

Project

manager

47


4.

Lack of control over suppliers, vendors and subcontr

actors

Myki project have lot of vendors and suppliers, needed for procuring hardware. Having lot of vendors in the project can sometimes leads to improper procurement management and tracking of the sellers trigger: 1.Lack of

communication

3 3 9 Medi um

High

1.Communicating with the vendors and contractors to avoid any misunderstanding 2.Proper timelines and requirements should be given to the vendors

1.Regular updates to the vendor and sub-contractors to make sure everyone is on the same page 2.Have a list of items/things the organization is procuring

Cost: there could be an impact on cost and budgeti ng of the project, cost estimati on can go

wrong

Project

manager

2.Constantly changing

requirements 3.Poor supply

chain processes

48


5.

Choosing the wrong SDLC methodol

ogy

Myki project is being carried out using agile SDLC methodology, if methodology like waterfall selected there will be lot of hindrance Trigger: 1.Manager lacking project management expertise 2. unclear product scope - if the project scope is not verified scope creep can occur which can cause the manager to choose the wrong SDLC. For example In our report the development of dashboard is under waterfall methodology because there is no interdependenci es between this task and the other Software development tasks that are

being carried out.

2 4 8 Medi um

High

1.Having a team of expert that decides the SDLC methodology 2.Being aware of the project scope and requirement of the stakeholder

1.making sure the sprints are being conducted on time 2.Regular communication with stakeholders for any change requirements

Time: wrong methodology selectio n could lead to project halt and can subsequently increase the time of deliveri ng the

project

IT

specialist

6.

Employe e

turnover There will be number of developers working on myki project, when they leave they take away critical information with him/her Trigger: 1.Hostile working environment: A working environment

2 3 6 Medi

um 1.Project privacy needs to be maintained 2.Proper authorization and IT security training needs to be provided to the employees working

in the project.

1.making the employees sign contract of nondisclosure 2.Rewarding the employees and providing benefit for their valuable contributions

Time: Employ ee quitting the job and leaving the project can increase the Burden on the

HR/ Manager

that is detrimental to the mental/physical health of its

employees

rest of the resources

49


2.Lack of motivation: Monotonous schedules,long tasks and lack of rewards/appreci ation can lead to low morale

amongst workers

Table 13: Risk Register

Risk (Ranking Factor)

Risk description Impacts to scope

Low (1) Little to zero impact on the project No impact on scope, time, cost and/or quality objectives

Medium (2) The risk needs to be monitored but no controls need to be put in place

Possible adjustments to time, or cost, or scope and/or quality

Medium high (3)

Depending on the risk, controls need to be put in place with some minor monitoring

Impact to the scope time cost and or quality objectives medium to high

High (4) Controls and monitoring put in place Impact to the scope time cost and or quality objectives high.

Extreme (5) Controls need to be put in place immediately and controls constantly monitored

Major impacts to the scope time cost and or quality objectives.

Figure 11. Probability and impact legend:

2.7.3. Summary After thoroughly going through all the risk management strategies, we were able to identify six risks that could impact the project in a great way. The likelihood and the impact matrix have been shown above for better understanding of the risk. It is majorly the duty of the manager to make sure that the risks are being handled on time.

50


3. OVERALL SUMMARY This report was composed to understand the various issues and functionalities associated with the old Myki project and uses them to establish new functionalities and solutions in new ticketing system for public transport in Melbourne. The project charter was signed off on _____ . Following charter sign off, a comprehensive stakeholder analysis was conducted and 6 high level stakeholders were identified. These were- Passenger, PTV, NTT Data, Service providers, Hardware suppliers and steering committee. These stakeholders were ranked using the stakeholder matrix. A communication plan was also created to establish a framework for communication with various stakeholders. Successively, a scope management plan was designed. Based on information gathered through research, interviews and emails, a requirement table was formed. These requirements were later classified further into functional and non-functional requirements. Following this, a primary Work breakdown structure was drafted using lucidchart, an online illustrative tool. Simultaneously a change control process was also drafted to provide a template for making changes to any element affecting scope. Afterwards, a schedule baseline and network diagram were generated using MS Project. This software was also used to depict the identified critical path primarily but an “activity on- node” version was also designed for better understanding of the readers. Lastly, Cost Management plan and risk management plan were drafted to better understand the cost associated with various activities and tasks in the project. The final cost estimate of the M.I.N.T.S project totaled at $9,834,264. 16% of this figure was allocated to reserves in order to combat cost overruns, 24% for software development and 29.17% for managerial & labor costs. Function point analysis along with bottom-up costing technique and expert judgement were applied to reach this figure. The risk management plan identified several potential risks associated with this project. These risks were scored on the basis of their likelihood and impact. The triggers linked to these risks were also identified several mitigation strategies were proposed along with the designation of the people responsible for implementing these strategies. Based on the requirements, 16 solutions were proposed, 15 of which would be developed under the Agile software development lifecycle methodologies. These included various functionalities such as credit the smart cards with monetary value using interfaces such as web browsers, kiosks and even handheld devices (Assumption: Myki App being developed as a parallel project). New functionalities include use of RFID wristbands as opposed to smartcard with a personalization feature, primarily marketed to groups as well as disabled people. The remaining functionality was proposed to be developed using the waterfall method. This functionality- integrated business intelligence dashboard would the provide PTV a holistic view of all operations by all service providers against benchmarks set by the steering committee. In addition, the dashboard would also provide information on equipment metrics such as average tap-on, tap-off time, equipment failure frequency etc. This information would be used to forecast equipment maintenance checks well in advance further saving operational costs for all stakeholders.

4. REFERENCES

51


Bannerman, P. L. (2008). Risk and risk management in software projects: A reassessment. Journal of Systems and Software. 81(12), 2118-2133. .

Carman., C. (2013, may 8). https://insights.dice.com/2013/05/08/why-change-control-isnt-for-sissies/. Retrieved from https://insights.dice.com/2013/05/08/why-change-control-isnt-for-sissies/: https://insights.dice.com/2013/05/08/why-change-control-isnt-for-sissies/

Charette, R. (1989). Software Engineering Risk Analysis and Management. McGraw-Hill, New York. . Software Engineering Risk Analysis and Management. McGraw-Hill, New York. .

Cule, P. S. (2000). Strategies for heading off project failure. Information Systems Management 17 (2), 65–73. 17 (2), 65–73.

Dingsøyr, T. e. (2012). A decade of agile methodologies: Towards explaining agile software development, Elsevier. A decade of agile methodologies: Towards explaining agile software development, Elsevier.

Doyle, J. (2015). Operational Effectiveness of the myki Ticketing System. . Operational Effectiveness of the myki Ticketing System. ., 82.

leontranter. (n.d.). https://www.extremeuncertainty.com/how-to-manage-scope-creep-bogeyman-agilescrum/. Retrieved from How to manage scope creep in Agile / Scrum. Retrieved from : https://www.extremeuncertainty.com/how-to-manage-scope-creep-bogeyman-agile-scrum/

Pencavel, J. (2014). The productivity of working hours. The Economic Journal,. The productivity of working hours. The Economic Journal,, 125(589), 2052-2076.

PMBOK. (2001). Guide, A.Project management body of knowledge (pmbok® guide). Paper presented at the Project Management Institute.

Tausworthe, R. C. (1979). "The work breakdown structure in software project management." Journal of Systems and Software . "The work breakdown structure in software project management." Journal of Systems and Software , 181-186.

Victoria, A. T. (2013). Major eGovernment projects in health, education and transport in Victoria'. 26th Bled eConference. Major eGovernment projects in health, education and transport in Victoria'. 26th Bled eConference.

website, S. (n.d.). https://www.seek.com.au/job/38907330?searchrequesttoken=23a815c8-d189-4062b385-0e12236777b2&type=promoted. Retrieved from https://www.seek.com.au/job/38907330?searchrequesttoken=23a815c8-d189-4062-b3850e12236777b2&type=promoted: https://www.seek.com.au/job/38907330?searchrequesttoken=23a815c8-d189-4062-b3850e12236777b2&type=promoted

website, S. (n.d.). https://www.seek.com.au/job/39002742?searchrequesttoken=3b3e510d-6c1d-47f0bb58-19abc0a4efe1&type=standard. Retrieved from https://www.seek.com.au/job/39002742?searchrequesttoken=3b3e510d-6c1d-47f0-bb5819abc0a4efe1&type=standard: https://www.seek.com.au/job/39002742?searchrequesttoken=3b3e510d-6c1d-47f0-bb5819abc0a4efe1&type=standard

52


5. APPENDIX

53


54

files.transtutors.com · Web viewMyki project. EXECUTIVE SUMMARY . This report provides the readers...

Documents

Transcript of files.transtutors.com · Web viewMyki project. EXECUTIVE SUMMARY . This report provides the readers...