responding post

Firstly question was:

 Why is change management a necessary component of project management? Consider the given case study, critically analyse and identify key issues that could lead to any necessary changes in the project. What processes or strategies do you think would work best to perform the identified change requests from the case study?  

Instructions for response post:

Take notes and prepare one response of no more than 250- words (to fit into 1-2 minutes recording) addressing some of the following (but not limited to) [apa 6th style referencing]:  

✓ Do you agree or not with the post? 

✓ Why? 

✓ Is there a gap that you can fill? 

✓ Add relevant information that contributes to the post!  

1

JORDON SCOTT’s Answer

During the execution of a project unexpected events will eventually always occur, these events can cause changes to the project and its approved project management plan (Dartmouth, 2014). Change can arise due to but not limited to project constraints, stakeholder requirements, team recommendations or vendor issues (Videos P. M., 2013). It’s critical to incorporate change management within project management for numerous reasons. Kim Heldman stated, “If you were to allow changes to occur to the project whenever requested, you would probably never complete the project” (Heldman, 2013).

A critical issue that needs addressing within the Link project is the incompetence of the Business Project Manager, as mentioned in the 2006 business case 70 – 80% of IT related projects fail due to inadequate project management. The Project Manager is responsible for leading the team who’s goal is delivering the project objectives, a competent Project Manager requires knowledge in the profession and the ability to implement that knowledge (PMI, 2013). With insufficient attention given to risk management, project teams without process and documentation understanding and not to mention the lack of leadership, a change in project manager will be needed.

For the issue to be rectified a change control process and plan will be implemented and utilised throughout the project for all changes including the changeover of the project manager. A change management process defines who, what, when, where and how we are going to manage the change, including tools and techniques used throughout the process, helping the project manager to review and analyse the proposed change (Videos P. M., 2013). Tools and Techniques become a vital part of the change management process, expert judgement allows professionals with a high level of knowledge to have input into the requested change while change control meetings let numerous stakeholders discuss the proposed change and make decisions accordingly (PMI, 2013). Gantt charts, spreadsheets or differing project management software’s will also help to identify, document, review and track the change.

· An event will occur prompting a change request, which will identify the change, and evaluate what the impact will be and what impact it will have on the project constraints.

·

 

Recommendations of that change will be incorporated and documented in the change log. The change log documents all the changes made or submitted throughout a project, this includes all the different changes, descriptions, dates and the impact.

· A change control board will have meetings to review the change requests. They will either approve or decline the request, once the change is approved its updated into the project management plan and relevant documentation (Videos P. M., 2013).

· Significant changes need to be documented and communicated to the project team to maintain alignment in all the efforts and work being completed (Dartmouth, 2014).

The Direct and Manage Project execution process will start once the change is approved, the process involves performing the works defined in the project management plan to achieve the projects objectives. Expert judgement and project management information systems should be utilized throughout the process, for example, project Libre will help plan and control not only the change but also the whole project. Once the process is successfully completed, project deliverables become the output (PMStudyChannel, 2014).

“The conclusion is that changes are manageable by applying integrated change management,” (Wanner, 2013). Without change management it’s easy for the project to lose control of the scope, time, cost and quality requirements, with the projects success being measured against such constraints it highlights the importance of change management throughout a project.

 
 

References

Dartmouth, T. S. (Director). (2014). Change Management Process [Motion Picture].

Heldman, K. (2013). Project Management Professional Exam Review Guide. John Wiley & Sons, Incorporated.

PMI. (2013). Project Management Body of Knowledge (PMBOK Guide) Fith Edition. Newtown Square, Pennsylvania: Project Management Institute .

PMStudyChannel. (2014, may 29). PMBOK C2 M4 Direct And Manage Project Execution. Retrieved from https://www.youtube.com/watch?v=Ziub-onbkjY&feature=youtu.be

Videos, P. (2012, January 24). How To Manage Project Scope Change. Retrieved from https://www.youtube.com/watch?v=tMR7jVefRIQ

Videos, P. M. (Director). (2013). How to Control Change Requests on a Project [Motion Picture].

Videos, P. M. (2013, may 27). What Is Change Management In Project Management Terms? Retrieved from youtube: 2013

Wanner, M. F. (2013). Integrated change management. Istanbul, Turkey: PMI.

PROJ6003 Project Execution & Control

Assessment Case Study

September 2020

1

* The contents of this Case Study were adapted from the references to suit the requirements of the PROJ6003 subject’s assessments and are the
property of Torrens University Australia.

Link Project Case Study

The management of information and communication technology enabled (ICT-enabled) projects

at the state, national and international level, in both the private and public sectors, has been the

subject of considerable research and debate over recent years. The consensus is that these

projects are often poorly managed and failures are common.

ICT systems store and communicate information about government business and in many cases

are used to administer front line services to the public. Despite this, many government ICT systems

are dated and lack the required functionality.

Crime statistics are one measure the community uses to judge our relative safety and security.

They show the rate of recorded crime across local government areas or regions, and can highlight

trends such as increases or decreases in types of crimes and how and where they are committed.

The government uses crime statistics as an indicator of the effectiveness of criminal justice

policies, and Victoria Police uses crime statistics to help determine its resourcing needs.

Victoria Police collects, reviews and records information on crimes—and the victims and alleged

offenders involved—in its Law Enforcement Assistance Program (LEAP) database. It is essentially

an online database fully relational that stores information about all crimes brought to the notice

of police as well as family incidents and missing persons. It also includes details on locations and

persons involved. LEAP is a dynamic case management and data storage database designed

primarily for operational policing purposes. Victoria Police update existing records with new

information as it becomes available, and revise records when investigation identifies additional

information. The Central Data Entry Bureau of Victoria Police also amends records when quality

control checks identify inaccurate or incomplete information. The only problem is that LEAP is an

outdated and inefficient ‘green-screen’ system developed in 1992.

Background of the project

Over 350,000 data records were retrieved from LEAP every day by operational members. Since its

conception, numerous interfaces have been developed to support the exchange of data between

LEAP and other Victoria Police systems and other organisations such as Australian Federal Police,

VicRoads and the Department of Justice, making this a very complex system to be replaced.

LEAP operated on obsolete mainframe technology and was driven by a ‘green screen’

presentation requiring keyed entries rather than a graphic presentation. LEAP is out-dated in style,

functionality and operability. Its data was ‘captured’ by electronic data recording (for some crimes)

and the use of voluminous forms completed by police and faxed to a central data entry bureau

(approximately 1200 per day) where full time data entry staff (75) work around the clock keying

PROJ6003 Project Execution & Control
Assessment Case Study

September 2020

2

* The contents of this Case Study were adapted from the references to suit the requirements of the PROJ6003 subject’s assessments and are the
property of Torrens University Australia.

information into the LEAP system. The backlog was such that it may take days for important crime

information to become visible to other police. The system was burdensome and inefficient.

Maintenance of the LEAP system was also time consuming and costly.

In 2005, after embarrassing leaks from LEAP created public concern as to the system’s efficacy, the

Office of Police Integrity recommended the replacement of LEAP with a force wide computer-

based information system. In an attempt to fully replace the LEAP database, the Link project was

then initiated by the Victoria Police.

In August 2005, the then Premier announced $50 million funding for the replacement of LEAP, to

be rolled out over three years. At the time of the announcement of the funding for the LEAP

replacement no business case had been prepared. It was appreciated by the then Chief

Commissioner that $50 million was insufficient for the project but her view was that the funding

should be viewed as “… a bird in the hand versus two in the bush”. The Executive Director,

Infrastructure and Information Technology of the Victoria Police, Mr Michael Vanderheide

observed on his arrival at Victoria Police that it was thought acceptable for an IT project to run

over budget with no accountability. Later in 2005 the funding for the replacement of LEAP was

increased to $60.5 million.

The Business Case

The Business Information and Technology and Services department (BITS) – later restructured to

the Infrastructure and Information Technology (I&IT) department of Victoria Police – was

established in 2005 to centralise major IT account management, business management and

project implementation across Victoria Police. The Chief Information Officer (CIO), responsible for

BITS for much of this time, held a position at equivalent level to a Deputy Commissioner and was

one of the 26 direct reports to Chief Commissioner Nixon, which advised the Minister of Police.

Victoria Police engaged consultants to prepare, in a very short time, a business case (BC) to

completely replace the LEAP system. This BC was prepared and delivered in February 2006, which

indicated the project would cost $59.48 million over four years, as opposed to the government’s

commitment of $60.5 million. As part of the BC, the project objectives indicated that the

replacement would:

▪ reduce crime and improve community trust;

▪ upgrade police skills in ethical management and data sensitivity;

▪ gather better information and data;

▪ streamline data entry; and

▪ improve security of police data and access.

PROJ6003 Project Execution & Control
Assessment Case Study
September 2020

3

* The contents of this Case Study were adapted from the references to suit the requirements of the PROJ6003 subject’s assessments and are the
property of Torrens University Australia.

The business case was the subject of a meeting for ‘clarification’ between the consultants and

representatives of Victoria Police on 4 September 2006. The notes of the meeting revealed that

the business case was written to fit the budget and for the writing of suitable messages to confirm

that support. It was noted at this meeting that the business case was not a like-for-like

replacement, that the business case didn’t address key existing issues with LEAP and that the

benefits as outlined in the business case were extremely broad, largely unachievable and

unmeasurable. A major risk to the project that escaped proper scrutiny in the business case was

the difficulty and cost of incorporating into the new system the many IT interfaces developed to

work in conjunction with LEAP.

On 30 May 2007, the steering committee accepted the February 2006 business case subject to a

number of caveats including:

▪ that the adequacy of funding would not be ascertained until more information became

available as to whether the replacement system would be custom built or commercial off

the shelf.

▪ the scope of the LEAP replacement had not been specified in detail within the business

case and the exact scope of the project could not be confirmed.

The caveats demonstrated the inadequacy of the initial business case. Not even the scope of the

replacement project was known. The business case was not updated at all during the project. The

absence of a business case updated with key aspects of project change (i.e. budget, schedule,

scope, risks and contingencies) meant the steering committee remained ignorant of the true net

present value of the project for approximately four years.

The business case also failed to identify measurable benefits to be achieved by the project.

Victoria Police notes from a meeting with the consultant in September 2006 indicated ‘many of

the benefits are not measurable but were written to confirm government support’. For example,

the business case stated that the project would lead to a reduction in crime of five per cent.

However, the consultant later stated this was a ‘big statement’, ‘pretty rough’ and ‘never

measurable’.

Procurement & Like-for-like
1
implementation strategy

After a procurement process, Victoria Police entered into a contract with Canadian vendor Niche

Technologies in February 2009 to provide a commercial off-the-shelf
2
records management

system, the Niche Records Management System product, which had been successfully

1 In terms of the information stored and the collection method there would be very little change between LEAP as it currently operates and LINK. It was
determined that a ‘like-for-like’ approach would create the smallest scope and make specification more straight-forward.
2 A product that already exists and can be readily procured. Such products are generally cheaper and less risky than developing a new, untested system.

PROJ6003 Project Execution & Control
Assessment Case Study
September 2020

4

* The contents of this Case Study were adapted from the references to suit the requirements of the PROJ6003 subject’s assessments and are the
property of Torrens University Australia.

implemented by police in many other jurisdictions both in Australia and overseas. Victoria Police

also purchased an Enterprise Service Bus (ESB), which would provide a mechanism for the new

system and other applications that interface with LEAP (such as the VicRoads database) to

exchange information.

However, agencies appear reluctant to acquire and make the most of commercial off-the-shelf

(COTS) systems. This was no different for the Link project. A COTS system was purchased but over

100 changes were made to the base package, which was customised to make it look and feel like

the existing LEAP system. By following this approach, Victoria Police would have its own version

of the COTS system, which could create difficulties in maintaining the system through standard

upgrades.

The business case accepted in May 2007 did not contemplate a like-for-like replacement of LEAP

as it stated that “replace LEAP on a like-for-like basis using modern technologies and architecture

would ignore the major changes in police roles and practices that have occurred and are likely to

occur in the future”. At some point, however, during the procurement process a decision was

taken that required the replacement of LEAP “… in all its current functionality”. The effect of the

decision was to seek a custom built like-for-like solution, which reproduced the functionality of

LEAP. The decision was at odds with the original business case and was at no stage properly

costed, despite the caveat to the business case mentioned in the steering committee minutes of

30 May 2007.

The ‘like-for-like’ strategy resulted in the commercial off-the-shelf product being excessively

customised, eroding the inherent benefits offered by the LEAP replacement product and

increasing costs. More so, this type of system had not been implemented as a ‘like-for-like’

replacement before and the vendor indicated to Victoria Police that the volume and complexity

of implementing a ‘like-for-like’ replacement would be the largest development effort it had

undertaken. The then Executive Director, Information Technology, Victoria Police stated that the

‘like-for-like’ approach did not cause the project’s problems, but the approach ‘turned into a

mistake’ and resulted in a ‘huge opportunity loss’.

The executive sponsor and chair of the steering committee stated that one of the learnings from

the project was that Victoria Police should have re-engineered its business processes to fit the

new system, rather than trying to make the system fit Victoria Police’s processes. The reluctance

to change business processes appears to be driven by a desire not to inconvenience users, even

in the short term, by a change in approach or the look and feel of the product. The approach is

also seen to reduce training and change management costs.

PROJ6003 Project Execution & Control
Assessment Case Study
September 2020

5

* The contents of this Case Study were adapted from the references to suit the requirements of the PROJ6003 subject’s assessments and are the
property of Torrens University Australia.

Yet, the like-for-like approach can lead to increased project costs and failure to capitalise on the

advancements in technology since the old system was developed. An over-emphasis on

replication of existing processes can result in lost opportunities in terms of making changes to

improve processes, making the most of what the system itself – particularly the benefits offered

by COTS systems – has to offer and minimising immediate and optimising ongoing development

costs. Of course, it is inevitable when developing and implementing new ICT-enabled systems that

changes to proven products will be necessary to meet the requirements of the agency.

Nevertheless, it is essential when considering and implementing these changes that the risks are

clearly identified and articulated and strategies are put in place to mitigate or at least minimise

those risks.

Timeline

Costs & Funding

The Link business case was developed to fit within the funding already announced by the

Government – $60.5 million. The steering committee observed this budget was a simplification of

the true budget cash flow and that the budget would need to be revised when post procurement

planning was complete and revised again after the development of a detailed work plan in

conjunction with the successful vendor. In March 2009, despite having entered a contract with

Niche just a month before, the scope of the work required for implementation remained to be

settled, without any apparent basis the steering committee was advised “… the total project

budget is not expected to change”.

Years later it was identified that the funding was insufficient. There were numerous budget

issues relating to the LINK project not allowed for in costing the project, including:

▪ interface development (including amount for contingency) to cost $30 million (in

addition to the $15.7 million spent for the Enterprise Service Bus (ESB), software that

PROJ6003 Project Execution & Control
Assessment Case Study
September 2020

6

* The contents of this Case Study were adapted from the references to suit the requirements of the PROJ6003 subject’s assessments and are the
property of Torrens University Australia.

provided the platform for interface processing) against the original business case

estimate of $2.4 million for interface costs;

▪ data conversion from LEAP to LINK over $10 million;

▪ training costs were underestimated by as much as $25 million; and

▪ extra costs due to the need to extend the timeframe for deployment.

It was not until late 2009 that the project team realised the business case cost estimates were

significantly deficient and in March 2010, the team identified the project was $80 million under-

funded. By this time, the project had been running for almost four years. While some costs may

not have been identifiable until after a vendor was selected, the requirement for additional

funding should have been identified much earlier by the project team. There were several early

warning signs which should have caused the project team to review the business case:

▪ The consultant had advised that the scope of the business case was written to fit the

budget, rather than a bottom-up requirements analysis of the system, and it was written

over a short period of time (September 2006)

▪ Concerns were raised about the adequacy of funding for the project (December 2006

and March 2008). Gateway Reviews
3
recommended the steering committee ‘finalise

scope and budget adequacy’. As part of these reviews, suggestions were made that the

project budget could ‘be validated on receipt of tender responses’.

▪ The steering committee did not endorse the business case until May 2007. Even then, its

endorsement was qualified by stating that the adequacy of funding could not be

ascertained until more information was available on the cost of a replacement system;

and that the scope of LEAP replacement had not been specified in detail within the

business case.

▪ 2008 media reports (prior to Victoria Police signing a contract with the vendor) indicated

the Queensland police force spent twice as much as the Link budget implementing the

same system.

There appears to have been a lack of leadership in that once the project started, there was no

stopping it – despite clearly inadequate funding.

Project Management

Victoria Police did not appoint a single project manager to lead the project, instead appointing a

Business Project Manager (a sworn officer) and a Technical Project Manager with joint

responsibility.

3 The Gateway Review process is an initiative of the Department of Treasury and Finance to provide an independent review of procurement at a key decision
point.

PROJ6003 Project Execution & Control
Assessment Case Study
September 2020

7

* The contents of this Case Study were adapted from the references to suit the requirements of the PROJ6003 subject’s assessments and are the
property of Torrens University Australia.

One sworn officer fulfilled the role of Business Project Manager from the beginning of 2008 until

project closure. While he had policing experience and knowledge of the business, he had not

managed a large, complex ICT-enabled project before. He said he ‘attended the basic ‘Prince2’

Project management course in either 2006 or 2007’ and believed he was selected for the position

as he had ‘successfully implemented’ a multi-agency project involving Victoria Police.

Victoria Police’s appointment of the officer to such a significant role suggests a failure to

understand the need for the project manager to have project management experience and

preferably, experience with projects of the size and complexity of the project. In fact, project

management was identified as a project risk in the 2006 business case, which stated, ‘Inadequate

project management is a … major contributor to the fact that 60-70% of IT related projects fail to

deliver’.

The Business Project Manager was also the senior responsible officer (SRO) for the project. The

SRO is the project owner, sponsor and champion—with personal accountability and overall

responsibility for the delivery of benefits. The SRO also receives the Gateway Review reports.

Combining the roles of Project Manager and SRO may have diminished the level of scrutiny on

the project.

Additionally, there seems to have a lack of understanding of business processes and old systems

by the project team. There was often a lack of documentation or understanding among staff about

the old systems, including business rules, the meaning of the data collected and any interfaces

with other applications. In the Link project, insufficient planning resulted in a failure by Victoria

Police to identify the number and complexity of the existing LEAP interfaces with other

applications. The costs associated with interfaces were significantly underestimated. Deputy

Commissioner, Kieran Walshe, said that “The integration of old and new technologies is an

extremely complex and time-consuming task – there are close to 200 interfaces with 25 existing

applications that need to be dealt with as part of the change” and that “unfortunately, the scale

and cost of this work was underestimated in the original business case.”

‘Tick-the-box’approach to risk management

While the Link project had a risk register and risk was generally a standing agenda item for

steering committee meetings, insufficient attention was actually given to managing or mitigating

risks. Rather, Victoria Police appear to have approached risk management with a ‘tick-the-box’

mentality – that is, the risk register is in place, risk is on the agenda and this is sufficient. This is

particularly concerning given the high-risk nature of ICT-enabled projects.

PROJ6003 Project Execution & Control
Assessment Case Study
September 2020

8

* The contents of this Case Study were adapted from the references to suit the requirements of the PROJ6003 subject’s assessments and are the
property of Torrens University Australia.

The risk register, like the business case, must be a living document, which is regularly reviewed

throughout the project to ensure risks – new and existing – are managed.

In the Link Project detailed specific risks in its risk register, but failed to manage them throughout

the project. In this regard, In December 2007, a risk chart was developed for the ‘LINK’ (LEAP

replacement) project. The risk chart was subject of numerous iterations up until 2010 but some

‘high’ risks were not addressed. The March 2008 Link risk register included a high risk that the level

of effort required for systems integration (ensuring that Link and other applications could

communicate) could be greater than expected. However, it was not until late 2009 that the project

team examined in detail the level of integration needed.

The Link business case also identified project management as a project risk and a major

contributor to the failure of 60-70 per cent of ICT-enabled projects. Despite this, Victoria Police

failed to appoint a single, qualified project manager to run the project.

There was no proper analysis of risks which underscores the lack of project management

experience on the steering committee. The risk management plan in reality was not used to

manage risk, and it quickly became out of date. For example, it was not updated to reflect the

risk of cost overrun posed by the lack of any proper costing of the like-for-like decision.

Assumptions and Reflection

The project is not yet suspended and you have been given the responsibility of an external Project

Management consultant to come in and propose options to recover the project.

→ What could be fixed from what has been done before?

→ What are the uncertainties that still surround the project moving forward?

PROJ6003 Project Execution & Control
Assessment Case Study
September 2020

9

* The contents of this Case Study were adapted from the references to suit the requirements of the PROJ6003 subject’s assessments and are the
property of Torrens University Australia.

References:

Australian Bureau of Statistics (2013). LAW ENFORCEMENT ASSISTANCE PROGRAM (LEAP)

VICTORIA POLICE. Retrieved from:

https://www.abs.gov.au/ausstats/abs@.nsf/Lookup/4533.0main+features100062013

Brouwer, G. E. (November, 2011). Own motion investigation into ICT-enabled projects – In

consultation with the Victorian Auditor-General. OMBUDSMAN.

Herrick, C. (April, 2011). Vic Police database project faces $100 million blowout . ComputerWorld.

Retrieved from: https://www.computerworld.com/article/3485553/vic-police-database-project-

faces-100-million-blowout.html

State Services Authority (November, 2011) Inquiry into the command, management and functions

of the senior structure of Victoria Police. State Government of Victoria State Services Authority.

VAGO (September, 2018). Crime Data. Victorian Auditor-General’s Office. Retrieved from:

https://www.audit.vic.gov.au/report/crime-data?section=

* How to cite this: Torrens University Australia (2020). Link Project Case Study. PROJ6003 Project

Execution & Control: Assessment Case Study.

https://www.abs.gov.au/ausstats/abs@.nsf/Lookup/4533.0main+features100062013

https://www.computerworld.com/article/3485553/vic-police-database-project-faces-100-million-blowout.html

https://www.computerworld.com/article/3485553/vic-police-database-project-faces-100-million-blowout.html

https://www.audit.vic.gov.au/report/crime-data?section