an analysis of the various requirements | My Assignment Tutor

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. Table of Contents Executive Summary …………………………………………………………………………………………………………….1 Glossary……………………………………………………………………………………… Error! Bookmark not defined. Overview …………………………………………………………………………………………………………………..3Introduction ……………………………………………………………………………………………………….3Purpose of the project…………………………………………………………………………………………..3Historical background …………………………………………………………………………………………..3Initiation & Planning ……………………………………………………………………………………………………5Project Charter ……………………………………………………………………………………………………5Stakeholder analysis …………………………………………………………………………………………….6 2.2.1. Stakeholder management ……………………………………………………………………………………………………… 6Stakeholder analysis ……………………………………………………………………………………………………………… 7Communication Plan ……………………………………………………………………………………………………………. 10Summary ……………………………………………………………………………………………………………………………. 12Scope management plan …………………………………………………………………………………….. 12Schedule baseline ……………………………………………………………………………………………… 23Network diagram ………………………………………………………………………………………………. 26Cost management plan ………………………………………………………………………………………. 37Risk Management plan ……………………………………………………………………………………….. 41Overall Summary ……………………………………………………………………………………………………… 46Works Cited …………………………………………………………………………. Error! Bookmark not defined.APPENDIX ………………………………………………………………………………………………………………..4 8 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 transportproviding the best value-for-money solution at the lowest possible costBeing 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.  Figure1: Timeline of the original project as shown in Victorian Auditor-General’s report. 2.   INITIATION & PLANNING 2.1.  Project Charter 26/03/2019 15/07/2021 Myki Improved: New Ticketing System                                                          3.0                                                                   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 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 TeamDevelopment Team A: 5 developers employed NTT Development Team B: 5 developers employed by M.I.N.T.S projectDatabase Team: 5 administratorsContractors (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 Stakeholde rContact personImp actInflue nceWhat is important to the stakeholde r?How could the stakehold er contribute to the project?How could the stakeholde r block the project?Strategy for engagin g the stakehol dersPublic/Pass engers 53Ease of Use of the public transport system Hasslefree transits The stakehold er can provide feedback on what needs to be improved in the current systemThe stakeholde r can block the project by not accepting the project implement ationSocial media and dedicat ed custom er service line for enquirie s and feedbac kOperatorsMetro Trains Melbourne: Ben Barrow  Ph: +61 419 505 748 Yarra Trams- Rob Robson [email protected] ams.com.au  CDC Victoria – Amrullah Tadjuddin- +61 435 368 728551.Timely implement ation 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 maintainThis stakehold er can provide insights from previous change implemen tations to help us better plan for the execution1.Lack of communic ation 2. Failure in providing appropriat e replaceme nt transport during implement ation  Fortnigh tly report through Project Manage r     travel benchmark s (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 DataRod Mahon [email protected] a.com.au551.Commun ication 2. Frozen core requireme nts 3. Brand AwarenessProvide Expertise and informatio n on the old system to improve the new one.1. Delay in delivery of product 2. Substanda rd quality of product 3. Lack of communic ation1.Weekl y progres s meeting s with develop ment team and project manage r 2. EmailsPTVAshish Khurana Ph(03) 90274192 [email protected] v.vic.gov.au551. Transparen cy during the planning and implement ation of the projectProvide help in Policy, governanc e and quality assurance document ation1. Change in Top managem ent1. Fortnigh tly report through Project Manage r 2. Confere     2. Complete document ation of the new systems infrastruct ure 3. Report on performan ce benchmark for the new system  nce Calls with develop ment team and project manage rSuppliersWristband Supplier: D.O RFID TAG company- Andrea Wong [email protected] om 311.Commun ication 2. Frozen core requireme nts 3. Brand AwarenessThe stakehold er can provide hardware implemen tation suggestion s in order to improve efficiency1. Delay in delivery of product 2. Substanda rd quality of product Lack of communic ation Change in Managem entPhone calls and emailsSteering Committee (Sponsors + Operator Board representa tives + consultants )Victorian   treasury and finance Ph:(03) 9651 5111551.Commun ication 2. Transparen cy during the planning and implement ation of the project 2. Complete document1. This stakehold er as a control body to help the project stay on track and acts as an intermedi ary between various1. Lack of Managem ent support 2 lack of communic ation Fortnigh tly report through Project Manage r    ation of the new systems infrastruct ure 3. Report on performan ce benchmark for the new system.governme nt organizati on and the project team   Public/Passengers  Operators NTT Data PTV Steering Committee (Sponsors + Operator Board representatives + consultants)  Suppliers    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   WHATWHOWHENHOWSteering Committee reportManager/stakeholdersEvery Week on Monday  By emails and attend meetingsSupplier/subcontractor relationPlanning teamWhen necessarycalls, emailSoftware development progressIT specialist (Team lead)FortnightlyMeeting (face to face)Website Development progress IT specialist (webdevelopment team lead) fortnightlyEmails, conference calls every fortnight to discuss the development, Monthly meeting. Mobile Application update Stakeholders/ Project manager fortnightlyEmails, conference calls every fortnight to discuss the progress, Monthly meetingChange in requirement Project manager (approvals for new resources) As per requirement of the project Meetings, conference callsBudget Allocation Project Manager Monthly Monthly MeetingsOverall Project UpdateProject 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 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 / Wristbandthe 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               StakeholderRequirementsNonfunctional (NF)Functional (F)PUBLIC/PASSENGEREase 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 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 OPERATORSFast card scanning F09: Faster card Scanning TimeNTT DATACommunication between developers and client  NF07: Communicability PTVEfficient performance F12: Operational performance dashboard  NF07: Communicability Steering CommitteeTransparency and regular communicationNF: Accountability   NF07: Communicability SUPPLIER/ SUBCONTRACTORS NF07: Communicability  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 Functional (F)/Non-function (NF)ExplanationGap/ExistingNature of ChangeF01: Online TopupPassengers require the ability to load their Myki cards with convenience using a web browser available on any electronic device with an internet connectionExisting  F02: Check BalancePassengers 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 devicesExisting F03: Service NotificationsPassengers require notifications of any disruptions happening in their travel service or potentially affecting their travelExisting F04: Trip HistoryPassengers need to be able to trace their travel footprint with their travel card across specific datesExisting 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: BuyBackPassengers 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.GapThe 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$.F07: RFID WristbandDisabled Passengers requirement a convenient form of ticketing.GapThe 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 displayPassengers require fast conducive touch screens to use functions provided by the Ticketing kioskExisting  F09: Faster card Scanning TimePassenger require fasting card scanning times on the kiosks as well as the tap-on/off pointsGapThe current scanning devices are notorious for long scanning times. A machine update with more sensitive scanners and new and NFC capabilitiesF10: Integration with other smart devicesPassengers require the use of mobile device like their cell phones and smartwatches as virtual travel cardsGapCurrently, 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 PlanningPassengers require the ability to plan trip using their travel cards to increase cost efficiencyExisting NF01: Data Security Existing NF02: Card-less Compatibility Existing NF03: Multi- Lingual accessibility Existing NF04: Reusability Existing NF05: Reliability Existing NF06: Flexibility Existing NF07: CommunicabilityThe developers require a streamlined communication channel with client in order to properly implement requirements and changes as necessary with the least amount of time lostExisting F09: Faster card Scanning TimeTo streamline with flow of passengers in and flow out vehicles and stations, operators require a faster scanning timeGap F12: Operational performance dashboardPTV requires accurate performance dashboard and report generation capabilitiesGapCurrently, 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 capabilitiesNF8: AccountabilityThe steering committee requires complete document of the happenings of the project in a timely mannerGapAs 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.  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 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.  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 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). 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. 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 Figure 7: Change Control Process Expected Completion DateHow it impacts the projectApprovals requiredSubmit 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 interferencePrioritizing the tasks and completing them as per set prioritiesEstimating and tracking time accuratelyCreating a schedule 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 NameMilestone 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            3.1.2.5 Sprint review Yes      3.3 Specific features for online users using a web browser Yes         3.3.2 Sprint 9 ( Online Top-up): Yes            3.3.2.5 Sprint review Yes         3.3.3 Sprint 10 ( Real- Time updates ): Yes            3.3.3.5 Sprint review Yes         3.3.4 Sprint 11 ( Customise wearables option): Yes            3.3.4.5 Sprint review Yes         3.3.5 Sprint 12 ( Purchase Wearables feature) Yes            3.3.5.5 Sprint review 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           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 projectNetwork Diagrams aid in planning, organizing and controllingNetwork diagrams show interdependencies of activities.Network Diagrams show the workflow of the project activities.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 TASK CODETask Name New Myki Ticketing System ProjectA   1.Initiation        1.1 Develop Project Charter       1.2 Review Charter       1.3 Project charter sign offB   2.Planning       2.1 Stakeholder analysis       2.2 Develop Communication PlanC      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 offD      2.4 Network DiagramE      2.5 Cost mangment planF      2.6 Risk Mangment PlanG   3.ExecutionH      3.1 Myki card          3.1.1 Requirments reviewI         3.1.2 Sprint 1 (Auto Top Up )              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 reviewJ         3.1.3 Sprint 2 ( Mobile top-up)              3.1.3.1 Feature design             3.1.3.2 Feature development             3.1.3.3 Test& debugging             3.1.3.4 Modification             3.1.3.5 Sprint review             3.1.3.6 Report to Steering committeeK         3.1.4 Sprint 3 (NFC capabililty)              3.1.4.1 Feature design             3.1.4.2 Feature development             3.1.4.3 Test& debugging             3.1.4.4 Modification             3.1.4.5 Sprint reviewL         3.1.5 Sprint 4 (Real-time update)              3.1.5.1 Feature design             3.1.5.2 Feature development             3.1.5.3 Test& debugging             3.1.5.4 Modification             3.1.5.5 Sprint review              3.1.5.6 Report to Steering committeeM         3.1.6 Sprint 5 (Buyback):             3.1.6.1 Feature design             3.1.6.2 Feature development             3.1.6.3 Test& debugging             3.1.6.4 Modification             3.1.6.5 Sprint reviewN         3.1.7 Sprint 6 (Multi Lingual accessablility):              3.1.7.1 Feature design             3.1.7.2 Feature development             3.1.7.3 Test& debugging             3.1.7.4 Modification             3.1.7.5 Sprint review             3.1.7.6 Report to Steering committeeO      3.2 Smart Watch ApplicationP         3.2.1 Sprint 7 (Working touch display):              3.2.1.1 Feature design             3.2.1.3 Feature development             3.2.1.4 Test& debugging             3.2.1.5 Modification             3.2.1.6 Sprint review              3.2.1.7 Report to Steering committeeQ         3.2.2 Sprint 8 (NFC capability ):              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             3.2.2.6 Report to Steering committeeR      3.3 Specific features for online users using a web browserS         3.3.1 Requirements reviewT         3.3.2 Sprint 9 ( Online Top-up):              3.3.2.1 Feature design             3.3.2.2 Feature development             3.3.2.3 Test& debugging             3.3.2.4 Modification             3.3.2.5 Sprint reviewU         3.3.3 Sprint 10 ( Real- Time updates ):             3.3.3.1 Feature design             3.3.3.2 Feature development             3.3.3.3 Test& debugging             3.3.3.4 Modification              3.3.3.5 Sprint review             3.3.3.6 Report to Steering committeeV         3.3.4 Sprint 11 ( Customise wearables option):             3.3.4.1 Feature design             3.3.4.2 Feature development             3.3.4.3 Test& debugging             3.3.4.4 Modification             3.3.4.5 Sprint review             3.3.4.6 Report to Steering committeeW         3.3.5 Sprint 12 ( Purchase Wearables feature)             3.3.5.1 Feature design             3.3.5.2 Feature development             3.3.5.3 Test& debugging             3.3.5.4 Modification             3.3.5.5 Sprint review             3.3.5.6 Report to Steering committee             3.3.5.6 Report to Steering committeeX      3.4 Dashboard          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 committeeY      3.5 Kiosk and other DevicesZ         3.5.1 Sprint 13 : Improve Scaning Time:             3.5.1.1 Feature design             3.5.1.2 Feature development             3.5.1.3 Test& debugging             3.5.1.4 Modification             3.5.1.5 Sprint review             3.5.1.6 Report to Steering committeeAA         3.5.2 Sprint 14 : Reciept Generation Options:             3.5.2.1 Feature design             3.5.2.2 Feature development             3.5.2.3 Test& debugging             3.5.2.4 Modification             3.5.2.5 Sprint review             3.5.2.6 Report to Steering committeeAB         3.5.3 Sprint 15: Wrist band:             3.5.3.1 Requirement review             3.5.3.2 Order prototype batch              3.5.3.3 Test& debugging             3.5.3.4 Final Testing             3.5.3.5 Report to Steering committeeAC      3.6 Backend Integration          3.6.1 Database Design          3.6.2 Build Database and add constraintsAD         3.6.3 cloud serversAE            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 ServerAH            3.6.4.1 Hardware Requirement                3.6.4.1.1 Memory                3.6.4.1.2 ProcessorAI            3.6.4.2 Network Requirement                3.6.4.2.1 Application Object Service                3.6.4.2.2 Domain Requirement                3.6.4.2.3 Network Testing          3.6.5 Modifications          3.6.6 Final Backend integration with application           3.6.7 Report to Steering committeeAJ      3.7. Testing          3.7.1 Requirement Testing          3.7.2 Load Testing          3.7.3 Report to Steering committeeAK      3.8 Training & Roll out          3.8.1 Training          3.8.2 Report to Steering committee          3.8.3 Product Roll Out          3.8.4 Product Installation Begins          3.8.5 Product Installation Complete          3.8.6 Report to Steering committee          3.8.7 Report to Steering committeeAL   4.Monitoring and Controlling       4.1 Scope Validation       4.2 Schedule Control       4.3 Integrated Change Control       4.4 Risk Monitoring & Control AM   5 Closing       5.1 Create Closing Report       5.2 Project closing Meeting    Extra Reporting Schedule       Report to Steering committee        Report to Steering committee       Report to Steering committee       Report to Steering committee       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. 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 # of High  Weight Total User Inputs 4 3 8 4 26 6 200 User Outputs 2 4 10 5 13 7 149 User Inquiries 8 3 12 4 32 6 264 Files/ Structures 2 7 9 10 4 15 164 External Interfaces 1 5 2 7 8 10 99             Unadjusted Function point score 876  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 CharacteristicBrief DescriptionVAF1Data communicationsAre data communications required?52Distributed data processingAre there distributed processing functions? 33PerformanceIs performance critical? 44Heavily used configurationWill the system run in an existing, heavily utilized operational environment? 55Transaction rateHow frequently are transactions executed daily, weekly, monthly, etc.?56On-Line data entryDoes the system require on-line data entry? 37End-user efficiencyWas the application designed for end-user efficiency?38On-Line updateDoes the on-line data entry require the input transaction to be built over multiple screens or operations? 49Complex processingDoes the application have extensive logical or mathematical processing?410ReusabilityWas the application developed to meet one or many user’s needs?411Installation easeHow difficult is conversion and installation?412Operational easeDoes the system require reliable backup and recovery? 513Multiple sitesIs the system designed for multiple installations in different organizations? 314Facilitate changeIs the application designed to facilitate change and ease of use by the user? 5  VAF score57 Table 10: Cost Estimate Table  # Units/Hrs.Cost/Unit/Hr.SubtotalsWBS Level 2 Totals% of TotalWBS Items     1. Project Management   AUD     2,860,400.0029.09%Project Manager2604AUD          100.00AUD          260,400.00  Planning Team3028AUD          150.00AUD          454,200.00  Development Team A2586AUD          300.00AUD          775,800.00  Development Team B2384AUD          300.00AUD          715,200.00  Database Team1270AUD          240.00AUD          304,800.00  Contractors (Installing Team)500AUD          700.00AUD          350,000.00  2. Hardware     Devices# of UnitCost/Unit AUD     2,672,238.0027.17%Ticket Vending Machine250AUD       5,000.00AUD      1,250,000.00  RFID Cards3500000AUD               0.10AUD          343,000.00  RFID Wristbands1000000AUD               0.18AUD          180,000.00  Bus Terminals3460AUD          250.00AUD          865,000.00  Servers AUD    34,238.00AUD            34,238.00  3. Software   AUD     2,404,620.0024.45%Software development  AUD      2,404,620.00  4. Testing   AUD        240,462.002.45%5. Training and Rollout# Units/Hrs.Cost/Unit/Hr.   Marketing Team700AUD             30.00AUD            21,000.00AUD           21,000.000.21%      6. Reserves  AUD      1,635,544.00AUD     1,635,544.0016.63%Total project cost estimate   AUD     9,834,264.00100% Table 11: Cost Baseline Tables for the duration of the Project (Monthly) WBS Items1234567891011121. 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.00Planning 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.00Development 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.00Development 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.00Database Team            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.004. 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.255. 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 Items1234567891011121. Project Management            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.00Planning 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.00Development 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.00Contractors (Installing Team)            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      $  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.004. 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.255. 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 WBS Items1234Totals 1. Project Management      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 Contractors (Installing Team)$   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 TableLabor EstimateUnit/HoursCost/Unit/HoursSubtotalsCalculationsDesignation    Project Manager1000AUD             800.00AUD                                         800,000.00 Developers1000AUD             600.00AUD                                         600,000.002 teams of 5 developers eachTotal Labor Cost  AUD                         1,400,000.00      Function Point Estimate    Total Function Points  1068.72Calculated from section above     Source Line  of Code Estimate (SLOC)  46428See referenceMarket 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) 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 availableFunction 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 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  LIKELIHOODInsignificant (1)Minor (2)Moderate (3)Major (4)Extreme (5)Rare (1)LowLowLowLowLowUnlikely (2)LowLowLowMediumMediumPossible (3)LowLowMediumMediumMediumLikely (4)LowMediumMediumHighHighAlmost certain (5)LowMediumMediumHighExtreme Figure 10: Impact and Likelihood Matrix 2.7.2. Risk Register table  N oRisk NameDescription/Trigg erLikelih oodImp act to the Proj ectTot al Ris k Sco reRisk class (see legen d)Risk control/mitigation StrategiesRisk monitoring measuresImpact to the triple constrai ntsRisk owners1Lack of Top manage ment supportLack of top management is when the higher management stops providing support (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 changes236Low1.Selecting the experienced and mature candidate for managing the project 2.Making sure there is full engagement of the top management in the project1.Making sure that the top management team is actively participating in the meeting  2.Making sure that fully engaged throughout the project life cycle.  Time: Increase d if the resourc es are not adequat ely provide d for Quality: may not be support edProject Manager   and proceeding with the project development   Trigger: .lack of communication between higher management and mid-level and lower level personnel.          2 .Inadequa te requirem ent gatheringTrigger: Not having the clear functional and nonfunctional requirements from the client end and stakeholders4416High1.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 requirements1.Regularly analyze and go through the requirement gathering techniques. 2.Following the project guidelinesScope: The scope of the project may begin to varyProject manager3 .Improper Task PlanningNot been able to carry out the planning, testing, tracking and reporting of project   Trigger:  1. Improper requirement gathering  2.Poor time management3                  39Medi um High1.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 progressTime and Cost can get impacte d if the proper task plannin g is not carried outProject manager4 .Lack of control over suppliers, vendors and subcontr actorsMyki 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 communication339Medi um High1.Communicating with the vendors and contractors to avoid any misunderstanding 2.Proper timelines and requirements should be given to the vendors1.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 procuringCost: there could be an impact on cost and budgeti ng of the project, cost estimati on can go wrongProject manager   2.Constantly changing requirements 3.Poor supply chain processes        5 .Choosing the wrong SDLC methodol ogyMyki 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.248Medi um High1.Having a team of expert that decides the SDLC methodology 2.Being aware of the project scope and requirement of the stakeholder1.making sure the sprints are being conducted on time 2.Regular communication with stakeholders for any change requirementsTime: wrong method ology selectio n could lead to project halt and can subsequ ently increase the time of deliveri ng the projectIT specialist6 .Employe e turnoverThere 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 environment236Medi um1.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 theHR/ Manager  that is detrimental to the mental/physical health of its employees  2.Lack of motivation: Monotonous schedules,long tasks and lack of rewards/appreci ation can lead to low morale amongst workers      rest of the resourc es    Table 13: Risk Register Risk (Ranking Factor)Risk descriptionImpacts to scopeLow (1)Little to zero impact on the project No impact on scope, time, cost and/or quality objectivesMedium (2)The risk needs to be monitored but no controls need to be put in placePossible adjustments to time, or cost, or scope and/or qualityMedium high (3)Depending on the risk, controls need to be put in place with some minor monitoringImpact to the scope time cost and or quality objectives medium to highHigh (4)Controls and monitoring put in placeImpact to the scope time cost and or quality objectives high.  Extreme (5)Controls need to be put in place immediately and controls constantly monitoredMajor 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. 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 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/: 4 Steps to Effective Change Control 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 : How to manage scope creep in 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 5. APPENDIX   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. Table of Contents Executive Summary …………………………………………………………………………………………………………….1 Glossary……………………………………………………………………………………… Error! Bookmark not defined. Overview …………………………………………………………………………………………………………………..3Introduction ……………………………………………………………………………………………………….3Purpose of the project…………………………………………………………………………………………..3Historical background …………………………………………………………………………………………..3Initiation & Planning ……………………………………………………………………………………………………5Project Charter ……………………………………………………………………………………………………5Stakeholder analysis …………………………………………………………………………………………….6 2.2.1. Stakeholder management ……………………………………………………………………………………………………… 6Stakeholder analysis ……………………………………………………………………………………………………………… 7Communication Plan ……………………………………………………………………………………………………………. 10Summary ……………………………………………………………………………………………………………………………. 12Scope management plan …………………………………………………………………………………….. 12Schedule baseline ……………………………………………………………………………………………… 23Network diagram ………………………………………………………………………………………………. 26Cost management plan ………………………………………………………………………………………. 37Risk Management plan ……………………………………………………………………………………….. 41Overall Summary ……………………………………………………………………………………………………… 46Works Cited …………………………………………………………………………. Error! Bookmark not defined.APPENDIX ………………………………………………………………………………………………………………..4 8 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 transportproviding the best value-for-money solution at the lowest possible costBeing 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.  Figure1: Timeline of the original project as shown in Victorian Auditor-General’s report. 2.   INITIATION & PLANNING 2.1.  Project Charter 26/03/2019 15/07/2021 Myki Improved: New Ticketing System                                                          3.0                                                                   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 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 TeamDevelopment Team A: 5 developers employed NTT Development Team B: 5 developers employed by M.I.N.T.S projectDatabase Team: 5 administratorsContractors (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 Stakeholde rContact personImp actInflue nceWhat is important to the stakeholde r?How could the stakehold er contribute to the project?How could the stakeholde r block the project?Strategy for engagin g the stakehol dersPublic/Pass engers 53Ease of Use of the public transport system Hasslefree transits The stakehold er can provide feedback on what needs to be improved in the current systemThe stakeholde r can block the project by not accepting the project implement ationSocial media and dedicat ed custom er service line for enquirie s and feedbac kOperatorsMetro Trains Melbourne: Ben Barrow  Ph: +61 419 505 748 Yarra Trams- Rob Robson [email protected] ams.com.au  CDC Victoria – Amrullah Tadjuddin- +61 435 368 728551.Timely implement ation 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 maintainThis stakehold er can provide insights from previous change implemen tations to help us better plan for the execution1.Lack of communic ation 2. Failure in providing appropriat e replaceme nt transport during implement ation  Fortnigh tly report through Project Manage r     travel benchmark s (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 DataRod Mahon [email protected] a.com.au551.Commun ication 2. Frozen core requireme nts 3. Brand AwarenessProvide Expertise and informatio n on the old system to improve the new one.1. Delay in delivery of product 2. Substanda rd quality of product 3. Lack of communic ation1.Weekl y progres s meeting s with develop ment team and project manage r 2. EmailsPTVAshish Khurana Ph(03) 90274192 [email protected] v.vic.gov.au551. Transparen cy during the planning and implement ation of the projectProvide help in Policy, governanc e and quality assurance document ation1. Change in Top managem ent1. Fortnigh tly report through Project Manage r 2. Confere     2. Complete document ation of the new systems infrastruct ure 3. Report on performan ce benchmark for the new system  nce Calls with develop ment team and project manage rSuppliersWristband Supplier: D.O RFID TAG company- Andrea Wong [email protected] om 311.Commun ication 2. Frozen core requireme nts 3. Brand AwarenessThe stakehold er can provide hardware implemen tation suggestion s in order to improve efficiency1. Delay in delivery of product 2. Substanda rd quality of product Lack of communic ation Change in Managem entPhone calls and emailsSteering Committee (Sponsors + Operator Board representa tives + consultants )Victorian   treasury and finance Ph:(03) 9651 5111551.Commun ication 2. Transparen cy during the planning and implement ation of the project 2. Complete document1. This stakehold er as a control body to help the project stay on track and acts as an intermedi ary between various1. Lack of Managem ent support 2 lack of communic ation Fortnigh tly report through Project Manage r    ation of the new systems infrastruct ure 3. Report on performan ce benchmark for the new system.governme nt organizati on and the project team   Public/Passengers  Operators NTT Data PTV Steering Committee (Sponsors + Operator Board representatives + consultants)  Suppliers    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   WHATWHOWHENHOWSteering Committee reportManager/stakeholdersEvery Week on Monday  By emails and attend meetingsSupplier/subcontractor relationPlanning teamWhen necessarycalls, emailSoftware development progressIT specialist (Team lead)FortnightlyMeeting (face to face)Website Development progress IT specialist (webdevelopment team lead) fortnightlyEmails, conference calls every fortnight to discuss the development, Monthly meeting. Mobile Application update Stakeholders/ Project manager fortnightlyEmails, conference calls every fortnight to discuss the progress, Monthly meetingChange in requirement Project manager (approvals for new resources) As per requirement of the project Meetings, conference callsBudget Allocation Project Manager Monthly Monthly MeetingsOverall Project UpdateProject 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 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 / Wristbandthe 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               StakeholderRequirementsNonfunctional (NF)Functional (F)PUBLIC/PASSENGEREase 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 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 OPERATORSFast card scanning F09: Faster card Scanning TimeNTT DATACommunication between developers and client  NF07: Communicability PTVEfficient performance F12: Operational performance dashboard  NF07: Communicability Steering CommitteeTransparency and regular communicationNF: Accountability   NF07: Communicability SUPPLIER/ SUBCONTRACTORS NF07: Communicability  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 Functional (F)/Non-function (NF)ExplanationGap/ExistingNature of ChangeF01: Online TopupPassengers require the ability to load their Myki cards with convenience using a web browser available on any electronic device with an internet connectionExisting  F02: Check BalancePassengers 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 devicesExisting F03: Service NotificationsPassengers require notifications of any disruptions happening in their travel service or potentially affecting their travelExisting F04: Trip HistoryPassengers need to be able to trace their travel footprint with their travel card across specific datesExisting 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: BuyBackPassengers 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.GapThe 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$.F07: RFID WristbandDisabled Passengers requirement a convenient form of ticketing.GapThe 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 displayPassengers require fast conducive touch screens to use functions provided by the Ticketing kioskExisting  F09: Faster card Scanning TimePassenger require fasting card scanning times on the kiosks as well as the tap-on/off pointsGapThe current scanning devices are notorious for long scanning times. A machine update with more sensitive scanners and new and NFC capabilitiesF10: Integration with other smart devicesPassengers require the use of mobile device like their cell phones and smartwatches as virtual travel cardsGapCurrently, 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 PlanningPassengers require the ability to plan trip using their travel cards to increase cost efficiencyExisting NF01: Data Security Existing NF02: Card-less Compatibility Existing NF03: Multi- Lingual accessibility Existing NF04: Reusability Existing NF05: Reliability Existing NF06: Flexibility Existing NF07: CommunicabilityThe developers require a streamlined communication channel with client in order to properly implement requirements and changes as necessary with the least amount of time lostExisting F09: Faster card Scanning TimeTo streamline with flow of passengers in and flow out vehicles and stations, operators require a faster scanning timeGap F12: Operational performance dashboardPTV requires accurate performance dashboard and report generation capabilitiesGapCurrently, 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 capabilitiesNF8: AccountabilityThe steering committee requires complete document of the happenings of the project in a timely mannerGapAs 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.  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 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.  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 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). 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. 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 Figure 7: Change Control Process Expected Completion DateHow it impacts the projectApprovals requiredSubmit 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 interferencePrioritizing the tasks and completing them as per set prioritiesEstimating and tracking time accuratelyCreating a schedule 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 NameMilestone 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            3.1.2.5 Sprint review Yes      3.3 Specific features for online users using a web browser Yes         3.3.2 Sprint 9 ( Online Top-up): Yes            3.3.2.5 Sprint review Yes         3.3.3 Sprint 10 ( Real- Time updates ): Yes            3.3.3.5 Sprint review Yes         3.3.4 Sprint 11 ( Customise wearables option): Yes            3.3.4.5 Sprint review Yes         3.3.5 Sprint 12 ( Purchase Wearables feature) Yes            3.3.5.5 Sprint review 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           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 projectNetwork Diagrams aid in planning, organizing and controllingNetwork diagrams show interdependencies of activities.Network Diagrams show the workflow of the project activities.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 TASK CODETask Name New Myki Ticketing System ProjectA   1.Initiation        1.1 Develop Project Charter       1.2 Review Charter       1.3 Project charter sign offB   2.Planning       2.1 Stakeholder analysis       2.2 Develop Communication PlanC      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 offD      2.4 Network DiagramE      2.5 Cost mangment planF      2.6 Risk Mangment PlanG   3.ExecutionH      3.1 Myki card          3.1.1 Requirments reviewI         3.1.2 Sprint 1 (Auto Top Up )              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 reviewJ         3.1.3 Sprint 2 ( Mobile top-up)              3.1.3.1 Feature design             3.1.3.2 Feature development             3.1.3.3 Test& debugging             3.1.3.4 Modification             3.1.3.5 Sprint review             3.1.3.6 Report to Steering committeeK         3.1.4 Sprint 3 (NFC capabililty)              3.1.4.1 Feature design             3.1.4.2 Feature development             3.1.4.3 Test& debugging             3.1.4.4 Modification             3.1.4.5 Sprint reviewL         3.1.5 Sprint 4 (Real-time update)              3.1.5.1 Feature design             3.1.5.2 Feature development             3.1.5.3 Test& debugging             3.1.5.4 Modification             3.1.5.5 Sprint review              3.1.5.6 Report to Steering committeeM         3.1.6 Sprint 5 (Buyback):             3.1.6.1 Feature design             3.1.6.2 Feature development             3.1.6.3 Test& debugging             3.1.6.4 Modification             3.1.6.5 Sprint reviewN         3.1.7 Sprint 6 (Multi Lingual accessablility):              3.1.7.1 Feature design             3.1.7.2 Feature development             3.1.7.3 Test& debugging             3.1.7.4 Modification             3.1.7.5 Sprint review             3.1.7.6 Report to Steering committeeO      3.2 Smart Watch ApplicationP         3.2.1 Sprint 7 (Working touch display):              3.2.1.1 Feature design             3.2.1.3 Feature development             3.2.1.4 Test& debugging             3.2.1.5 Modification             3.2.1.6 Sprint review              3.2.1.7 Report to Steering committeeQ         3.2.2 Sprint 8 (NFC capability ):              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             3.2.2.6 Report to Steering committeeR      3.3 Specific features for online users using a web browserS         3.3.1 Requirements reviewT         3.3.2 Sprint 9 ( Online Top-up):              3.3.2.1 Feature design             3.3.2.2 Feature development             3.3.2.3 Test& debugging             3.3.2.4 Modification             3.3.2.5 Sprint reviewU         3.3.3 Sprint 10 ( Real- Time updates ):             3.3.3.1 Feature design             3.3.3.2 Feature development             3.3.3.3 Test& debugging             3.3.3.4 Modification              3.3.3.5 Sprint review             3.3.3.6 Report to Steering committeeV         3.3.4 Sprint 11 ( Customise wearables option):             3.3.4.1 Feature design             3.3.4.2 Feature development             3.3.4.3 Test& debugging             3.3.4.4 Modification             3.3.4.5 Sprint review             3.3.4.6 Report to Steering committeeW         3.3.5 Sprint 12 ( Purchase Wearables feature)             3.3.5.1 Feature design             3.3.5.2 Feature development             3.3.5.3 Test& debugging             3.3.5.4 Modification             3.3.5.5 Sprint review             3.3.5.6 Report to Steering committee             3.3.5.6 Report to Steering committeeX      3.4 Dashboard          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 committeeY      3.5 Kiosk and other DevicesZ         3.5.1 Sprint 13 : Improve Scaning Time:             3.5.1.1 Feature design             3.5.1.2 Feature development             3.5.1.3 Test& debugging             3.5.1.4 Modification             3.5.1.5 Sprint review             3.5.1.6 Report to Steering committeeAA         3.5.2 Sprint 14 : Reciept Generation Options:             3.5.2.1 Feature design             3.5.2.2 Feature development             3.5.2.3 Test& debugging             3.5.2.4 Modification             3.5.2.5 Sprint review             3.5.2.6 Report to Steering committeeAB         3.5.3 Sprint 15: Wrist band:             3.5.3.1 Requirement review             3.5.3.2 Order prototype batch              3.5.3.3 Test& debugging             3.5.3.4 Final Testing             3.5.3.5 Report to Steering committeeAC      3.6 Backend Integration          3.6.1 Database Design          3.6.2 Build Database and add constraintsAD         3.6.3 cloud serversAE            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 ServerAH            3.6.4.1 Hardware Requirement                3.6.4.1.1 Memory                3.6.4.1.2 ProcessorAI            3.6.4.2 Network Requirement                3.6.4.2.1 Application Object Service                3.6.4.2.2 Domain Requirement                3.6.4.2.3 Network Testing          3.6.5 Modifications          3.6.6 Final Backend integration with application           3.6.7 Report to Steering committeeAJ      3.7. Testing          3.7.1 Requirement Testing          3.7.2 Load Testing          3.7.3 Report to Steering committeeAK      3.8 Training & Roll out          3.8.1 Training          3.8.2 Report to Steering committee          3.8.3 Product Roll Out          3.8.4 Product Installation Begins          3.8.5 Product Installation Complete          3.8.6 Report to Steering committee          3.8.7 Report to Steering committeeAL   4.Monitoring and Controlling       4.1 Scope Validation       4.2 Schedule Control       4.3 Integrated Change Control       4.4 Risk Monitoring & Control AM   5 Closing       5.1 Create Closing Report       5.2 Project closing Meeting    Extra Reporting Schedule       Report to Steering committee        Report to Steering committee       Report to Steering committee       Report to Steering committee       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. 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 # of High  Weight Total User Inputs 4 3 8 4 26 6 200 User Outputs 2 4 10 5 13 7 149 User Inquiries 8 3 12 4 32 6 264 Files/ Structures 2 7 9 10 4 15 164 External Interfaces 1 5 2 7 8 10 99             Unadjusted Function point score 876  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 CharacteristicBrief DescriptionVAF1Data communicationsAre data communications required?52Distributed data processingAre there distributed processing functions? 33PerformanceIs performance critical? 44Heavily used configurationWill the system run in an existing, heavily utilized operational environment? 55Transaction rateHow frequently are transactions executed daily, weekly, monthly, etc.?56On-Line data entryDoes the system require on-line data entry? 37End-user efficiencyWas the application designed for end-user efficiency?38On-Line updateDoes the on-line data entry require the input transaction to be built over multiple screens or operations? 49Complex processingDoes the application have extensive logical or mathematical processing?410ReusabilityWas the application developed to meet one or many user’s needs?411Installation easeHow difficult is conversion and installation?412Operational easeDoes the system require reliable backup and recovery? 513Multiple sitesIs the system designed for multiple installations in different organizations? 314Facilitate changeIs the application designed to facilitate change and ease of use by the user? 5  VAF score57 Table 10: Cost Estimate Table  # Units/Hrs.Cost/Unit/Hr.SubtotalsWBS Level 2 Totals% of TotalWBS Items     1. Project Management   AUD     2,860,400.0029.09%Project Manager2604AUD          100.00AUD          260,400.00  Planning Team3028AUD          150.00AUD          454,200.00  Development Team A2586AUD          300.00AUD          775,800.00  Development Team B2384AUD          300.00AUD          715,200.00  Database Team1270AUD          240.00AUD          304,800.00  Contractors (Installing Team)500AUD          700.00AUD          350,000.00  2. Hardware     Devices# of UnitCost/Unit AUD     2,672,238.0027.17%Ticket Vending Machine250AUD       5,000.00AUD      1,250,000.00  RFID Cards3500000AUD               0.10AUD          343,000.00  RFID Wristbands1000000AUD               0.18AUD          180,000.00  Bus Terminals3460AUD          250.00AUD          865,000.00  Servers AUD    34,238.00AUD            34,238.00  3. Software   AUD     2,404,620.0024.45%Software development  AUD      2,404,620.00  4. Testing   AUD        240,462.002.45%5. Training and Rollout# Units/Hrs.Cost/Unit/Hr.   Marketing Team700AUD             30.00AUD            21,000.00AUD           21,000.000.21%      6. Reserves  AUD      1,635,544.00AUD     1,635,544.0016.63%Total project cost estimate   AUD     9,834,264.00100% Table 11: Cost Baseline Tables for the duration of the Project (Monthly) WBS Items1234567891011121. 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.00Planning 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.00Development 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.00Development 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.00Database Team            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.004. 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.255. 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 Items1234567891011121. Project Management            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.00Planning 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.00Development 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.00Contractors (Installing Team)            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      $  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.004. 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.255. 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 WBS Items1234Totals 1. Project Management      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 Contractors (Installing Team)$   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 TableLabor EstimateUnit/HoursCost/Unit/HoursSubtotalsCalculationsDesignation    Project Manager1000AUD             800.00AUD                                         800,000.00 Developers1000AUD             600.00AUD                                         600,000.002 teams of 5 developers eachTotal Labor Cost  AUD                         1,400,000.00      Function Point Estimate    Total Function Points  1068.72Calculated from section above     Source Line  of Code Estimate (SLOC)  46428See referenceMarket 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) 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 availableFunction 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 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  LIKELIHOODInsignificant (1)Minor (2)Moderate (3)Major (4)Extreme (5)Rare (1)LowLowLowLowLowUnlikely (2)LowLowLowMediumMediumPossible (3)LowLowMediumMediumMediumLikely (4)LowMediumMediumHighHighAlmost certain (5)LowMediumMediumHighExtreme Figure 10: Impact and Likelihood Matrix 2.7.2. Risk Register table  N oRisk NameDescription/Trigg erLikelih oodImp act to the Proj ectTot al Ris k Sco reRisk class (see legen d)Risk control/mitigation StrategiesRisk monitoring measuresImpact to the triple constrai ntsRisk owners1Lack of Top manage ment supportLack of top management is when the higher management stops providing support (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 changes236Low1.Selecting the experienced and mature candidate for managing the project 2.Making sure there is full engagement of the top management in the project1.Making sure that the top management team is actively participating in the meeting  2.Making sure that fully engaged throughout the project life cycle.  Time: Increase d if the resourc es are not adequat ely provide d for Quality: may not be support edProject Manager   and proceeding with the project development   Trigger: .lack of communication between higher management and mid-level and lower level personnel.          2 .Inadequa te requirem ent gatheringTrigger: Not having the clear functional and nonfunctional requirements from the client end and stakeholders4416High1.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 requirements1.Regularly analyze and go through the requirement gathering techniques. 2.Following the project guidelinesScope: The scope of the project may begin to varyProject manager3 .Improper Task PlanningNot been able to carry out the planning, testing, tracking and reporting of project   Trigger:  1. Improper requirement gathering  2.Poor time management3                  39Medi um High1.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 progressTime and Cost can get impacte d if the proper task plannin g is not carried outProject manager4 .Lack of control over suppliers, vendors and subcontr actorsMyki 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 communication339Medi um High1.Communicating with the vendors and contractors to avoid any misunderstanding 2.Proper timelines and requirements should be given to the vendors1.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 procuringCost: there could be an impact on cost and budgeti ng of the project, cost estimati on can go wrongProject manager   2.Constantly changing requirements 3.Poor supply chain processes        5 .Choosing the wrong SDLC methodol ogyMyki 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.248Medi um High1.Having a team of expert that decides the SDLC methodology 2.Being aware of the project scope and requirement of the stakeholder1.making sure the sprints are being conducted on time 2.Regular communication with stakeholders for any change requirementsTime: wrong method ology selectio n could lead to project halt and can subsequ ently increase the time of deliveri ng the projectIT specialist6 .Employe e turnoverThere 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 environment236Medi um1.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 theHR/ Manager  that is detrimental to the mental/physical health of its employees  2.Lack of motivation: Monotonous schedules,long tasks and lack of rewards/appreci ation can lead to low morale amongst workers      rest of the resourc es    Table 13: Risk Register Risk (Ranking Factor)Risk descriptionImpacts to scopeLow (1)Little to zero impact on the project No impact on scope, time, cost and/or quality objectivesMedium (2)The risk needs to be monitored but no controls need to be put in placePossible adjustments to time, or cost, or scope and/or qualityMedium high (3)Depending on the risk, controls need to be put in place with some minor monitoringImpact to the scope time cost and or quality objectives medium to highHigh (4)Controls and monitoring put in placeImpact to the scope time cost and or quality objectives high.  Extreme (5)Controls need to be put in place immediately and controls constantly monitoredMajor 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. 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 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/: 4 Steps to Effective Change Control 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 : How to manage scope creep in 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 5. APPENDIX  

• Assignment status: Already Solved By Our Experts
• (USA, AUS, UK & CA PhD. Writers)
• CLICK HERE TO GET A PROFESSIONAL WRITER TO WORK ON THIS PAPER AND OTHER SIMILAR PAPERS, GET A NON PLAGIARIZED PAPER FROM OUR EXPERTS

QUALITY: 100% ORIGINAL PAPER – NO PLAGIARISM – CUSTOM PAPER