IT Programme and Lorenzo Patient Record Systems Report

Appropriate methodologies and concepts for a critical review of the organisation of the project case study

Regardless of the project type, there are some different forms of methodologies and concepts to assist project managers and teams at a given stage of a project from the project initiation, execution to the closure. A project management methodology offers appropriate methods and guidelines to ensure that projects are done in the effective, well-coordinated, and consistent ways that enhance the delivery of quality outcomes on time and within the budget.

This report focuses on the application of appropriate project methodologies and concepts for a critical review of the National IT Programme in the NHS.

National IT Programme in the NHS

Initiating the Project

Hoffer and other authors have identified several elements related to project initiation (Hoffer, George, & Valacich, 2002).

The project was initiated by the Department of Health, which was the key stakeholder of the Programme. In the fiscal year 2007-08, the Programme had a budget allocation of £1.4 billion with nearly 1,100 employees and consultants.

The Chief Executive of the NHS was the main stakeholder responsible for the entire Programme since 2007 (Meredith & Mantel, 2003). The Programme’s responsibility and accountability for implementation were shared with other local members of the NHS. Specifically, the other Chief Executives under the ten Strategic Health Authorities were responsible for the Programme implementation and realisation of benefits in their respective areas. The NHS is accountable to the National Assembly.

There were three Local Service Providers to ensure that systems and services delivered reached various regions of the country.

This Programme would ensure the development and implementation of “an electronic care record for patients, the NHS Care Records Service to cater to all patients” (National Audit Office, 2008).

Specifically, the decision to „go live‟ was left to the Trust while the Chief Executives agree on Programme implementation (National Audit Office, 2008).

Scope and aims of the Project

The Programme was delivered under extremely complex and constantly changing environment (National Audit Office, 2008). It required substantial “organisational and cultural change for its successful deployment” (National Audit Office, 2008). The Programme was to change how the NHS had used patient data (Hartman & Ashrafi, 2002).

The project was launched in 2002. The National Programme for IT in the NHS (the Programme) was planned to transform how the National Health Service in England used data to enhance services and the quality of patient care (National Audit Office, 2008).

The Programme went beyond information technology reform to include other several aspects of change within the NHS. It was to bring about “new NHS policy, operational changes and add new programmes” (National Audit Office, 2008). The Programme had substantial impacts on every aspect of the NHS. Therefore, policy and operational changes resulted in some requirements, which were difficult and costly to meet effectively. For instance, in 2004, the NHS Improvement Plan introduced a plan that no patient would wait for “more than 18 weeks between GP referral and hospital care provision” (National Audit Office, 2008).

As a result, several elements of the NHS required readjustment under this plan to meet the stipulated deadline. There was also the aim to meet the Mental Health Act 2007. This required good knowledge of complex provisions under the Programme. The Programme was to ensure that mental health systems offered would support administrators by ensuring correct inputs, adhering to the Act, supporting appeals, renewals and tribunals, among others. The NHS normally conducts periodic restructuring, and therefore it was noted that the Programme would support the new organisational structure, changes in information requirements and support new boundaries. It was dependent on the deployment of other systems.

The NHS was to become more devolved. There would be accurate care information available at any given moment for persons concerned with patient care. This was meant to reduce risks associated with medication errors or adverse outcomes. At the same time, it was mean to help the NHS employees to make a fully informed decision regarding any treatment. The Programme was not simple to deploy because of its devolved model. Other IT programmes are usually simple to deploy because of a simple organisational structure. In this case, there were different Chief Executives of the Trusts to make independent decisions on the pace of Programme deployment. Although 88 Trusts (now known as Foundation Trusts) are independent, they remain core part of the NHS, but the Secretary of State for Health has no control over them (National Audit Office, 2008).

Trusts continue to experience significant changes. Also, the future of the NHS review was conducted during the Programme development. The review focused on a 10-year vision to ensure patient control and reduce central control, promote choice and local accountability and services that meet the demands of the local populations (National Audit Office, 2008).

The Programme aimed to ensure that information involved in bookings and prescriptions was accurately transmitted, rapidly and efficiently to various departments of the NHS and pharmacies. This was a “broader health informatics project to enhance health outcomes” (National Audit Office, 2008). Timely information was to ensure that health care providers receive early warnings to known risks, save lives and improve health outcomes. Likewise, data would support treatments, justify interventions, and enhance the availability of treatment to more people. It is believed that the “ongoing research and available knowledge on health informatics would improve health outcomes” (National Audit Office, 2008). IT, clinical guidelines, medical terminologies and communication systems were among some of the components of the Programme. The Programme was not mandatory for developments in health informatics but was meant to support information management and usages (National Audit Office, 2008). Finally, the Programme aimed to ensure that the NHS was highly efficient by reducing the time that employees spend on collecting patient information.

Project Planning

It is imperative to note that this Programme was delivered in an extremely, constantly changing environment as new provisions and requirements emanated from policy and operational activities within the NHS (Kioppenborg & Opfer, 2002).

The Programme Stakeholders

• Chief Executives of Trusts.
• Patients.
• Three Local Service Providers.
• Health care providers.
• Parliament.

The Programme Areas of focus with the estimated population served

• London – approximately 7.2 million.
• North Midlands and East – approximately 29.9 million.
• South – approximately 13.0 million.

The Programme Elements

• Care Records Service.
• The N3 network (providing IT infrastructure, networking services, connectivity and the broadband capacity to meet the current and future needs of the NHS).
• The Spine (stores patient data, interfaces with other systems and provides security).
• Choose and Book (an electronic booking service).
• Lorenzo.
• Picture Archiving and Communications Systems (digital X-rays and other images).
• NHS e-mail system (NHSmail).
• Electronic Prescription Service.
• HealthSpace.
• Quality Management and Analysis System.
• GP to GP transfer.

Sean Maserang identified elements of project planning as project tasks, project benefits, resources, schedules, communication plan, risk assessment, budget, statement of work and project baseline (Maserang, 2002).

The Programme cost

In this Programme, the report noted that the estimated total cost remained largely unchanged. Increased costs were mainly associated with the expenses related to functionality. Hence, it was difficult to determine the exact cost of the Programme (Rad, 2001). Generally, the Programme expenses have remained less than estimated to date (Ward, 2007). For instance, as 31 March 2008, the Programme spending had reached £3,550 million (National Audit Office, 2008). The expense associated with the core contracts was £1,933 million, which was 44 per cent less than the initially allocated amount of £3,428 million. This showed that there was a slow deployment of the Programme components.

The Programme Schedule Progress

At the start of the Programme, the implementation goal was to ensure that all systems for the patients were to be completed under the electronic care record by the year 2010 (National Audit Office, 2008). The timetable provided since the year 2006 was classified as tentative. Some of the Programme elements were completed earlier (Lester, 2006).

However, it remained unclear when the original timescale for the Care Records Service (one major element of the Programme) would be achieved (National Audit Office, 2008).

The project progress report indicated that it was most likely to consume some four years more than the scheduled timescale. That is, the Programme was most likely to be completed by the year 2014 to 2015. This is before all the NHS Trusts have fully deployed the care records systems.

The major project under Lorenzo must be completed and deployed to ensure accurate scheduling for the North, Midlands and East. Nevertheless, there was an improvement with other projects.

Expected Benefits

The Programme was meant to deliver substantial benefits to stakeholders (Thayer & Yourdon, 2000). However, realising these benefits could not be a centralised process. Many benefits were expected to be realised over time from different NHS activities and could later be replicated to other locations. This implied that local stakeholders had critical roles to play to derive benefits from the Programme since a centralised process could not deliver them effectively (Fleming, 2005).

Programme Risks

The Programme was centrally specified but implemented under a more devolved environment, and therefore risks were expected. Devolution was escalated to the local levels with possible tensions and implications in key areas (National Audit Office, 2008).

• Contracting – it was believed that all NHS Trusts would adopt the Programme at some point, but Foundation Trusts could wish not to use the Programme, a situation that could lead to financial implication for the Programme and other Trusts.
• Deployment plans – the decision to “go live” had critical impacts on risks to patient care and operations of the Trusts (mainly in premature cases).
• Benefits realisation – benefits realisation was not a centralised process.
• The plurality of provision – bringing different organisations into the Programme added further complexity.
• It was noted that Accenture also withdrew from the Programme, a situation that led to immense pressure on other suppliers.

Project Execution

There were several indicators noted in delivering the Programme (Ireland, 2006).

The Programme was started in 2002. It was aimed to realise the full implementation of various projects by the year 2010. As at 31 March 2008, substantial percentages of the projects had been completed or were near completion (National Audit Office, 2008). Today, however, there are some elements in the Care Records Service, which were expected to be completed by the year 2015. It is also expected that the Programme would accommodate changes based on the increased functionality and integration to come in the future.

The Programme was executed, and progress was monitored based on time, care records, N3 Network, Spine, Choose and Book, Electronic Prescription Service, Picture Archiving and Communications Systems, HealthSpace, NHSmail, Quality Management and Analysis System, and GP to GP transfer (Phillips, 2003).

Some of these projects were realised earlier than expected based on the schedule (Pandey, 2013). The Gantt Chart below indicates project schedule, completion and days remaining.

During the Programme progress review, the following concerns were noted.

• At the present rate of development, “no significant clinical benefits were expected to be delivered at the end of the contract period” (National Audit Office, 2008). In some instances, the progress was generally smooth but slow. It was, therefore, imperative for stakeholders to focus on elements of functionality, which could deliver benefits at the local levels.
• It was difficult to ascertain expenditures because the department did not keep a detailed record of overall expenditure on the Programme and estimates of its total cost. They are however assumed to range from £6.2 billion up to £20 billion. On this note, the department needed to provide its annual fiscal statement with the costs and benefits of the Programme, which could have reflected both national and local level costs and benefits, savings and service improvements.
• It was also noted that the concerned department did not seek to show the Programme’s costs against benefits. Instead, the department sought to justify the Programme based on improved patient services. It only reflected the Programme’s financial value on a few occasions where it could. Also, the department failed to account for non-financial benefits. It is imperative to include non-financial rewards of the Programme even if they did not have specific values for effective decision-making and offer a baseline for other future project implementation (Nokes, 2007).

Closing Down the Project

Not all elements of the Programme have achieved completion statuses. Hence, there was no Programme closure report. Nevertheless, the review report provides several recommendations to manage identified challenges and ensure successful implementation of subsequent elements of the Programme (Project Management Institute, 2008).

• There was narrow concentration on the IT systems at the expense of other aspects of the Programme and its application to facilitate change. It was noted that frequent leadership changes at the Department also affected the Programme significantly. It was, therefore, imperative to limit leadership changes that affected the programme.
• Local ownership was also a major challenge. The Department could have clarified these issues at the local levels to facilitate the implementation of the Programme and realisation of functionality and subsequent benefits. The Chief Executives and other senior executives have clear roles to play in this Programme.At the same time, the department must engage all stakeholders, including patients and NHS staff. This could have facilitated information and opinion gathering.
• There was notable pressure on suppliers after the withdrawal of Accenture. It is imperative to note that suppliers lacked the adequate skilled capacity to meet systems needed for effective implementation of the Programme. It was necessary to review engagement with suppliers and evaluate their capacities to deliver (McNamara, 2013).
• Schedule and cost management were also critical for the effective implementation of the Programme. Although several elements of the Programme were completed ahead of schedule, there were some elements, which could not be completed before the Care Record Systems and project Lorenzo (National Audit Office, 2008).
• It was also noted that depending on two major software suppliers was a major challenge to the Programme implementation.

A Project Plan for Lorenzo and Lorenzo Bury

A scope statement

Lorenzo is the care record software being developed by iSOFT, which is to be deployed by CSC to Acute Trusts, Mental Health Trusts and Primary Care Trusts in the North, Midlands and East (Community Services Bury Board, 2010). Any project requires a well-defined scope to guide stakeholders (Lock, 2007).

The major elements of Lorenzo were categorised as:

• Summary care record.
• Detailed care Record.
• N3 Infrastructure.
• Choose & book.
• Electronic Prescription Service.
• Data Spine.
• Picture Archiving.
• NHS Mail (e-mail communication system).

The NHS Bury was among the “Early Adopter” to “implement Lorenzo Regional Care Release 1.9 (LRC1.9) as a process of the National Programme for IT (NPfIT) efforts to implement the new healthcare system” (Community Services Bury Board, 2010). LRC1.9 was implemented in NHS Bury on 3rd November 2009, and since then, the Trust has strived to work closely with the CSCA with support from other stakeholders such as NW SHA and CfH (Community Services Bury Board, 2010). They aimed to review and resolve challenges, improve operational conditions of the system, implement new functionality and support system users by ensuring that it meets their unique business requirements (Community Services Bury Board, 2010).

The business as usual (BAU) state was scheduled for 1st July 2010 (Community Services Bury Board, 2010). New functionality was planned for additional advantages to users.

It is also imperative to note that since the “go live” of Lorenzo LRC19, other several system upgrades have been initiated and implemented to address project known challenges, provide system stability and provide new functionality to system users. Generally, Lorenzo involved software development processes, which included six standard phases. However, there could have been additional development tasks based on the software and prevailing developmental situation.

Project Plan

Project planning mainly focuses on the objectives of the project. The aim is to look at possible results under prevailing circumstances. We can look at the planning of the project under time, costs, and quality. A favourable project budget should produce the highest quality standard within the shortest completion time. Parties must identify any compromise before the project begins and make a realistic evaluation of the project’s possible achievements. Planning phase provides an effective way of checking the feasibility of the project. Thus, the project manager can be sure that the team can complete the project.

The project would guide the project processes throughout different development phases (Kerzner, 2003). Specifically, the project plan would document “planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost and schedule baselines” (Project Management Institute, 2000).From Lorenzo Project, it was clear that the software development processes were based on the waterfall model (Lotz, 2013).

The waterfall methodology is simple and could be defined by definite sequences such as:

• Collecting and noting requirements.
• Designing.
• Coding and testing.
• Conducting system testing.
• Conducting user acceptance testing.
• Identifying and fixing any issues.
• Deploying the finished product.

In a normal waterfall model, there are distinct phases of software development, which must be completed before the next phase can commence (Scheid, 2012). Moreover, in some instances, the customer must “review and approve requirements before the design team can begin their work” (Scheid, 2012). For instance, Lorenzo, the following were noted during project development phases (Community Services Bury Board, 2010).

• The summary care record could not be constructed until the detailed care record infrastructure was built, but this also needed the smartcard system and the automated audit trail to be completed before this could take place.
• The N3 IT infrastructure needed to be debugged before the detailed care records could be migrated onto the system, but also the encryption and security procedures for N3 needed to be developed before the migration.
• In addition, the NHS mail system, Choose and book process also depended on the interface with users and the communication link to Trusts being built before trial deployment could take place.
• The picture archiving system needed an image sharing software programme to be built before even the build phase could start.
• Before each major element could start, consultation with stakeholders must have been concluded in three main stages – initial – which happened before any build, review that could take place anytime after trial deployment, but the timing could impact the effectiveness of the outcome, and check, which could take place during the feedback phase of each software development cycle.
• Stakeholders were defined within the NAO audit document, and they consisted of all bodies reporting, indirectly or directly to the Department of Health. Currently, stakeholder consultation has been taking place sequentially, starting with the NHS Trusts.
• The trial deployment also contained the following additional tasks; training, migration and ID checks, and especially ID checks had to happen before training could take place. Trial deployment took place across four NHS trusts for each major element.
• Finally, each rollout could only then take place across all NHS trusts in a methodology that could not be decided upon immediately.

The project developer gained the following advantages from relying on the waterfall model. First, stakeholders had to agree to the critical elements and functionality of the project. They identified elements that the project had to deliver in the early stages of development. The model provided a more straightforward approach to project design (Scheid, 2012). Second, the waterfall model allowed stakeholders to assess and measure their progress against the project schedule easily. It was simple to understand the full scope of software development phases. Third, different stakeholders involved in software development could handle similar projects or work on other different projects.

This flexibility, however, depended on the active phase of software development. For instance, designers and developers of summary care record and detailed care record could work together to learn requirements in the initial phase. Fourth, it was not strictly necessary for the NHS to be present after the requirement phase. Fifth, the project involved the development of multiple software elements and designs that could be handled in the early phase of the project, and therefore, integration was enhanced. Finally, Lorenzo was designed wholly and more carefully because several elements of the project had already been identified and deliverables noted. This provided an opportunity for good software design, development, testing and deployment without piecemeal integration. As a result, several aspects of the project moved smoothly but slower (Nathan & Everett, 2003).

On the other hand, the waterfall model could have also presented some significant difficulties to Lorenzo. It was extremely difficult to gather and design all system requirements. This was one challenge, which developers and customers found out to be the most difficult aspect of the project because of the complexity of the devolved nature of the Programme. In some instances, clients could have been intimated by many details, specific requirements, the need for flexibility and specific details required under the waterfall model. Second, many local users could not easily visualise outcomes before system deployment. Many end users normally have challenges understanding the final picture of waterfall model outcomes. Finally, it has been noted that clients or end users may be dissatisfied with the delivered software. As a result, many changes are usually “expensive and difficult to execute” (Scheid, 2012). For instance, it was noted that other additional software tasks usually took six months (+/50%), although anything that involved stakeholders consultations could drag on to 9 months.

At the same time, it was however noted that estimates could vary by +/20%. Suppliers had indicated that increasing expenses on programme elements could decrease build and debug phases by 30%, although this could cost up to 50% more for these elements. Some factors may occur during the life of a project, distort the planned budget and delay the project (Snyder & Parth, 2006). Most changes usually have negative repercussions on the project. In some cases, such changes may be unforeseen or unavoidable. However, in most cases, such disruptive changes are due to poor planning of the project. The main aim of cost management is to prevent wastage of money or unauthorised increase in costs.

Lorenzo project has been upgraded on several occasions to fix known issues, ensure system stability and to deliver new functionality (Community Services Bury Board, 2010). In addition to some major upgrades, Lorenzo has undergone several tests, including a “Disaster Recovery test, infrastructure hardware upgrades and a data migration purge activity to support the subsequent “go live” of Morecambe Bay University Hospitals” (Community Services Bury Board, 2010). Upgrades were associated with system downtime.

The most recent upgrades have taken place using “pseudo zero downtime” technology in preparation for the future use of full “zero downtime” technology, which will allow system upgrades to be performed without any downtime and therefore with no impact to end users” (Community Services Bury Board, 2010).

Risk Management Plan

Risk management remains the core area of focus in project management (Williams, 2008). From the Lorenzo update report, major challenges included the management of live issues and delivery of targeted support to users through the support for services initiative while ensuring a smooth transition of the project into a business as usual mode (Community Services Bury Board, 2010). More user benefits were expected through other elements of the project (Stevens, 2002). Deployment Verification activities were “in progress and generally aimed to provide operational reports to users” (Community Services Bury Board, 2010).

To manage potential risks in Lorenzo, service management, support for services, the transition to Business As Usual, future project priorities and deployment verification have become major areas of focus in the project (Hamilton, 2004). Since the introduction of the new software version in November 2009, service management has become a key issue in the project (Community Services Bury Board, 2010). It was noted that the Trust service management team worked with other accredited stakeholders such as “Ashton, Leigh and Wigan helpdesk and CSCA Service Management alongside support from NW SHA and CfH service management teams” (Community Services Bury Board, 2010). The Trust’s main agendas had included further integration and development of the current service management processes and to ensure that the system could enhance efficiency and user experience without further costs (Ktenas, 2013).

Also, there was an effort to lessen the challenges noted in the live phase (Community Services Bury Board, 2010). The update report identified several challenges that existed in service environments, which were managed through innovative approaches until solutions were developed. Also, the Trust had identified some risks (Chapman & Ward, 2003) through an activity to focus on all live challenges associated with works in progress. As a result, further work was in progress with CSCA to resolve these issues. The Trust also noted that the support required for resolving “live service issues represented one of the Deployment Verification Criteria” (Community Services Bury Board, 2010).

Support for Services also represented an aspect of risk management in Lorenzo. Risk management in projects changed based on the complexity of the project (Schimmoller, 2001). Support for users was provided through the Support for Services activities that drew together project stakeholders from the Trust and CSCA (Community Services Bury Board, 2010). The objective of the work was to deliver targeted support to users by considering the specific needs of users on a service-by-service basis concerning system issues, technical issues, training requirements and efficiency considerations among others (Community Services Bury Board, 2010).

A dedicated service line was established within the Support for Services team to manage their communication, develop action plans and resolve issues (Community Services Bury Board, 2010). The project generally focused on quick wins with significant advantages to stakeholders. There was also long-term management of the relation with the service and resolution of issues among stakeholders. The project communication plan was also noted (Devaux, 1999). For instance, the status and progress of this work were then reported via an agreed-upon reporting format produced fortnightly and shared with the “NHS Bury business representatives, CSB EMT, IM&T management, and the Lorenzo Project Board” (Community Services Bury Board, 2010).

The project was also planned to transit to Business As Usual. These plans allowed a decreased dependence on support from outside in subsequent activities. This includes recruitment to the role of “System Delivery Manager who will pick up responsibilities around day-to-day management of the system, including ongoing test assurance, issue management and support to users” (Community Services Bury Board, 2010). A Project Manager was also hired to manage Care Plans, which represented “a significant future objective for the continued project” (Community Services Bury Board, 2010). Also, the DVP focused specifically on resolving challenges associated with reporting.

Risk management also accounted for future project priorities (Dobson, 2001). For instance, future deployment units were planned as part of the “Bury Lorenzo project and had new functional elements that were expected to deliver additional benefits to users” (Community Services Bury Board, 2010). All these areas were in initial processes of project development (Community Services Bury Board, 2010). In addition to formal deployment units, several areas of discreet functionality were available within “the system that had not yet been implemented in Bury” (Community Services Bury Board, 2010). The project team and the CSCA were reviewing priorities for areas of significant in the project implementation (Community Services Bury Board, 2010).

The Deployment Verification Process (DVP) was also done to manage risks. The DVP was a formal 45-day activity that started at the “go live” date of any new service to manage risks (Community Services Bury Board, 2010). The objective of the process was to assure a set of agreed-upon Deployment Verification Criteria (DVC) that the new service was “fit for purpose and that any outstanding items or issues left over from the deployment phase were addressed” (Community Services Bury Board, 2010). The project objectives at Bury were not met immediately because of the outstanding challenges in Lorenzo (Community Services Bury Board, 2010).

Nevertheless, significant achievements were met in subsequent periods. The DVP for Bury’s LRC1.9 project status was provided for every DVC (Community Services Bury Board, 2010). While several aspects of the project status were positively rated, there was a challenge with the Accuracy of Reporting. It was noted that the “DVP for Bury’s LRC1.9 project had not yet been signed off by the Trust and further work was needed mainly around Accuracy of Reporting before sign-off could be achieved” (Community Services Bury Board, 2010). Moreover, there were decisions to concentrate on “the Solution Support for Business Processes and User Feedback that were in a pass/fail status” (Community Services Bury Board, 2010). The persistent challenges noted in ten operational front-end reports made it difficult to “set a new completion date for DVP sign- off” (Community Services Bury Board, 2010).

Organisational Structure

Lorenzo project was developed and delivered under much complex organisational setup. Also, the devolved nature of the project for local implementation enhanced its complexity.

A greater collaboration was required among stakeholders to execute the project effectively (Cleland & Gareis, 2006).

Reference List

Fleming, Q 2005, Earned Value Project Management, 3rd edn, Project Management Institute, Pennsylvania.

Hartman, F & Ashrafi, R 2002, ‘Project Management in the Information Systems and Information Technologies Industries’, Project Management Journal, vol. 33, no. 2, pp. 5- 15.

Hoffer, J, George, J & Valacich, J 2002, Modern Systems Analysis & Design, Pearson Education, Inc, Upper Saddle River, NJ.

Ireland, L 2006, Project Management, McGraw-Hill Professional, New York.

Kioppenborg, T & Opfer, W 2002, ‘The Current State of Project Management Research: Trends, Interpretations, and Predictions’, Project Management Journal, vol. 33, no. 2, pp. 5-18.

Lester, A 2006, Project Management, Planning and Control, 5th edn, Elsevier Science & Technology Books, Loughborough.

Maserang, S 2002, Project Management: Tools & Techniques,Web.

McNamara, B. (2013). The Basic Project Management Concepts. Web.

Meredith, J & Mantel, S 2003, Project Management: A Managerial Approach, 5th edn, Wiley & Sons, New York.

National Audit Office 2008, The National Programme for IT in the NHS: Progress since 2006, The Stationery Office, London.

Nokes, S 2007, The Definitive Guide to Project Management, Financial Times/Prentice Hall, London.

Pandey, P 2013, Sick of Microsoft Project? Manage Your Project in Excel. Web.

Phillips, J 2003, PMP Project Management Professional Study Guide, McGraw-Hill Professional, New York.

Project Management Institute 2008, A Guide to the Project Management Body of Knowledge: PMBOK Guide,4th edn, Project Management Institute Inc, Pennsylvania. Rad, P 2001, Project Estimating and Cost Management, Management Concepts, Vienna.

Thayer, R & Yourdon, E 2000, Software Engineering Project Management, 2nd edn, Wiley-IEEE Computer Society Press, New York.

Ward, G 2007, Project Manager’s Guide to Purchasing, Gower, Aldershot.

Chapman, C & Ward, S 2003, Project Risk Management: Processes, Techniques and Insights, 2nd edn, Wiley & Sons, Chichester.

Cleland, D & Gareis, R 2006, Global Project Management Handbook, McGraw-Hill Professional, New York.

Community Services Bury Board 2010, Lorenzo Regional Care Implementation – Update, Lorenzo Project Board, London.

Devaux, S 1999, Total Project Control: a Manager’s Guide to Integrated Planning, Measuring and Tracking, Wiley & Sons, New York.

Dobson, MS 2001, Project Management for the Technical Professional, Project Management Institute, Inc, Pennsylvania.

Hamilton, A 2004, Handbook of Project Management Procedures, TTL Publishing Ltd, India.

Kerzner, H 2003, Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 8th edn, Wiley, New York.

Ktenas, S 2013, Cost of Software. Web.

Lock, D 2007, Project Management, 9th edn, Gower Publishing Limited, Hampshire. Lotz, M 2013, Waterfall vs. Agile: Which is the Right Development Methodology for Your Project? Web.

Nathan, P & Everett, G 2003, PMP Certification For Dummies, O’Reilly Media, Sebastopol, CA.

Project Management Institute 2000, A Guide to the Project Management Body of Knowledge 2000 Edition, Project Management Institute, Pennsylvania.

Scheid, J 2012, Project Management Methodologies: How Do They Compare? Web.

Schimmoller, B 2001, ‘The Changing Face of Project Management’, Power Engineering, vol. 105. no. 5, pp. 28-30.

Snyder, C & Parth, F 2006, Introduction to IT Project Management, Management Concepts, New Jersey.

Stevens, M 2002, Project Management Pathways. Association for Project Management, APM Publishing Limited, London.

Williams, M 2008, The Principles of Project Management, SitePoint Pty Ltd, Collingwood, Australia.