The country of Westoria has a well-respected public health service funded primarily through general taxation. The Westoria Public Health Authority (WPHA) is responsible for delivering this health service through a network of hospitals in Westoria.
WPHA is under increasing pressure to demonstrate to taxpayers that it is using public finances wisely and so it wishes to accurately monitor and control health service expenditure. However, it is proving difficult to confidently track the budgeted and actual finances of individual hospitals, as each is operating its own form of budgeting and cash management. Consequently, WPHA has decided to introduce a single computer-based system which will allow all hospitals to enter and manage financial information in a standard way. This system will be part of an authority-wide enterprise resource planning system (ERPS) which will allow WPHA to monitor and control the finances of the entire authority. Currently, the input and consolidation of WPHA information is a time-consuming process, importing data from individual hospitals into a series of spreadsheets to provide total figures for the authority as a whole.
At a recent WPHA board meeting, the head of the authority suggested that the scope of the ERPS should be widened to incorporate other elements of operational and management information. She pointed out that some previous commercial off-the-shelf (COTS) software solutions which the authority selected and implemented had not worked well. She gave two specific examples:
– The payroll system does not support payment increments for non-standard working, such as overtime rates. To allow this, payroll staff currently have to change the employee’s standard hourly rate for the time period in question and then change it back again. This is time-consuming and payment errors have been made when payroll staff have forgotten to change the rate back again.
– The human resource management system does not support the temporary transfer of staff between hospital departments. To compensate for this, human resource staff have to action a permanent move for a short time period and then action a reverse move at the end of that period.
She therefore felt that the introduction of the ERPS would be an opportunity to address outstanding problems and to improve and standardise the systems in use.
The board agreed the ERPS should, as a minimum, also include payroll and human resource management modules within the overall product. However, given budget limitations, the board decided that a commercial off-the-shelf ERPS solution should be selected and implemented. They all agreed that this would be a cheaper solution than a bespoke system and would be well suited to their needs, as it should fulfil the standard requirements they envisaged. Furthermore, it had always been the policy of WPHA not to employ internal IT system developers. Currently, the IT support team consists of one operational member of staff at each hospital and a central team of ten staff who assist in addressing major IT problems encountered at any of the hospitals. The IT support team has also produced ways to bypass issues with previously implemented COTS package solutions.
This lack of internal IT resource, and the recognition that previous COTS implementations had been less successful than predicted, has prompted WPHA to seek the advice of an external software systems consultant.
The consultant has suggested that the evaluation and implementation of the ERPS package should follow a four-stage process:
– Evaluate whether a COTS solution is an appropriate approach
– Define the requirements for the new software
– Evaluate competing packages
– Implement the selected package
However, the head of the authority believes that the external consultant is being over-cautious in his advice and approach and that the first two stages are not needed. In her words: ‘We know that a COTS solution is the right approach for us as we have little alternative, so why spend time doing the first step? We also know that we’ve been pretty poor at defining what we want in the past; so why not recognise our deficiencies and go straight to stage three and look at competing packages to see which products provide the best features?’
and look at competing packages to see which products provide the best features?’ The HR director, who has experienced the problems of the human resource and payroll systems at first hand, disagrees. He feels that the consultant’s four-stage process is insufficient. He believes that, ‘it is important that we consider all four elements of the POPIT (four view) model, which provides four key areas to be considered when a process is to change. These four key areas are people, organisation, processes and information technology. Only the last of these will be considered in the consultant’s four-stage process. If we ignore the remaining three areas we are in danger of another failed software project, which is likely to further upset taxpayers and, perhaps, threaten the future of the authority itself.’
Required:
The external consultant suggested a four-stage process for the evaluation and implementation of the proposed commercial off-the-shelf ERPS package.
Discuss the four-stage process for the evaluation and implementation of a software package, and the significance of each stage in the context of the previous and proposed COTS solutions at WPHA.
The head of the authority has not fully learned from the prior mistakes of WHPA’s software projects. Had the four-stage process been followed, the authority might not have implemented systems which did not fulfil their needs, and caused operational difficulties.
The content of each of the stages, and their significance to this project and to WHPA, may be summarised as follows:
Stage one – Evaluate whether a COTS solution is an appropriate approach
The business case for the system should be assessed to determine whether a COTS solution is appropriate, or whether a bespoke system would be better suited to the needs of the organisation. The head of the authority seems fairly clear that a COTS would be most appropriate, although the decision appears to be mainly on cost grounds. It is likely that this would be important, given that the majority of funding is from taxation, but it should not be the only deciding factor. Complexity of a process often has an impact on whether a COTS package is appropriate, as does the availability of suitable packages. It does not seem in this scenario that the process to be automated is particularly complex and it also seems relatively routine in nature. This would need to be verified, but if it were true, then the COTS approach is probably the more appropriate.
If this stage were omitted, it is possible that the authority would make the wrong choices on the basis of cost alone. This could make the entire project a waste of time and funding as it may lead to another failure.
Stage two – Define the requirements for the new software
It is quite clear from the scenario that WHPA has suffered in the past from a failure to define requirements correctly. Hence, this is not a good reason for omitting this step entirely. The head of the authority suggests they ‘go straight to stage three and look at competing packages to see which provides the best features’, but it would be impossible to ascertain which was most suited if the requirements had not been defined. Indeed, if they omit this step, then it is likely that this system will also require workarounds as the previous systems have done.
Requirements defined within this step will encompass various functional and non-functional requirements. Functional requirements should include the operational processes which must be possible using this system, such as the ability to adjust payroll for one-off events. It is important to consider potential future requirements, such that the system will continue to be valuable into the future.
Non-functional requirements may include requirements from the supplier, such as support mechanisms. It would appear that WHPA is limited in its IT support provision, so this may be considered an important requirement.
There may also be technical requirements. It is likely that the authority will not wish to spend more than necessary and therefore it could be essential that the software is able to operate on the existing hardware.
Stage three – Evaluate competing packages
Given the responsibility towards the public in providing a value for money service, it is important that WHPA gets the best package in terms of meeting their needs within budgetary constraints. By evaluating competing packages, rather than simply considering one, the value for money should be greater as the best package will be selected.
The evaluation process could follow a ‘tender’ approach, whereby suppliers bid to supply the software required, giving feedback to them on which requirements are met (or not) and to what extent. The process should certainly be formalised, and this could help to provide accountability to the public that the best system has been selected. The tenders should be evaluated against the requirements given at stage two, in addition to any other criteria, such as implementation deadlines, overall budget, etc. The comparison may use a weighted ranking basis to ensure the decision is not based on a single factor, but gives the best option overall. Without this, a public organisation may be tempted to simply choose the cheapest option, given their budgetary limitations.
Stage four – Implement the selected package
There should be a planned implementation which includes testing, training, installation and data transfer. This is a key part of the process which connects strongly with the overall reliability of the system. A system which is not tested adequately by users (in addition to the software developers) may not meet the needs of the organisation, or may be found to be lacking user-friendliness. A failure to train staff could lead to resistance and problems in data transfer could invalidate the entire output of the software.
The HR director has suggested that all elements of the POPIT model should be considered.
Explain, in the context of WPHA, the need for considering the people, the organisation and the processes involved when carrying out a business change project.
The HR director is concerned that the focus is simply on the information technology rather than the people, processes and organisational structure. The POPIT model recognises the equal importance of each when enhancing a business process. This has been developed to take a more holistic view of process change, considering those elements which could affect the success of the project.
Processes seem to be a key area which should be considered. One process which is particularly important is the level of IT support available within the organisation. Organisations with poor IT support in place are likely to need to address this, as part of process improvement. WHPA has been subjected to system workarounds, having to ‘fiddle’ data to achieve the desired output in the payroll and HRM systems, for example. This is probably due to the very limited IT support available.
Manual processes should be identified to determine whether there is scope to eliminate these. It would appear that this has already been done to an extent by considering the need for an ERPS to assist in organisation-wide reporting, currently a labour-intensive process. WHPA should take the opportunity to see whether there are other such processes which could be eliminated. Given the few processes described, none of which seem to run efficiently, it is likely that there may be others.
The organisation aspect of the POPIT model considers elements of structure, management configuration and support and roles and responsibilities, for example. The board seems to support this change in the organisation, but it is likely to also impact upon the management in the individual hospitals. It needs to be considered whether the management in the separate areas of the organisation will support this change. If not, it could have an impact on the success of the change project. The board may need to convince them that the new system will make life easier for all, rather than be introduced to ‘spy’ on their budgeting and management control systems.
Roles and responsibilities should also be considered, specifically within the change process itself. Who will be involved in the change project and how will it affect their day-to-day roles? They will need to be given clear guidance of what is expected as well as the resources needed. For example, it seems that the head of the authority is keen to keep costs low; those involved would need to be assured that the project would be given sufficient resources to succeed.
People can be a key reason for failure of a project. If there is resistance, then it may impede the progress of the project, impact upon the end result, or even halt a project completely. Staff morale and motivation should be taken into consideration and the authority should ensure that any possible negative impact is mitigated. It may be that reward systems need to be introduced which align with the new process and ultimately the goals of the authority.
The skills also need to be considered. It would appear that the authority does not currently run a high level of information systems. Therefore, personnel may not be in possession of adequate skills for the new system. This is itself can be a cause for resistance. Training should be considered as part of the change process.
Although IT skills may not be fully present, the staff should be skilled in their individual area of work. For this reason, they should be encouraged to participate in the design of the new system. Had this happened in the past, the systems might have been designed to fully meet departmental needs, rather than finding workarounds.
Overall, therefore, the HR director is right to consider the other elements of the POPIT model, as to do so should positively affect the outcome of this project.