7 Mistakes Most Public Sector Organisations make with IT Projects

Having worked with public sector organisations for over 10 years, we have noticed many trends (good and bad) when delivering IT projects. Here are 7 key points to be mindful of:

 

1. Baselining – tangible improvements

An essential part of any project is understanding what the state of play is, in enough detail to be able to quantify any improvements / benefits throughout the life cycle of the project, particularly prior to commencing and post project completion.

One of the best ways we have found to achieve this is to identify (where possible) an aspect of the new solution that can be measured and directly compared to the existing solution. For example, when deploying a virtualised desktop environment, we ensure that a sufficient amount of time is allocated in the project plan to capture OS and Application login and load times.

 

2. Cost / Benefit – finding a problem for a solution

How does the cost of implementation stack up against the associated benefits – the lack of this analysis is one of the most prominent trends that we have experienced in the public sector. Many organisations seem to complete initial high level analysis (usually just enough to get approval to initiate the project), however the opportunity to complete an in-depth ROI exercise is usually missed.

Quite often solutions are purchased without fully understanding the problem. We call this “finding a problem for a solution”. Ensure the requirements and existing issues are fully understood and reflected in any specification documents published for tender will help when analysing cost vs benefits.

 

3. Exec Level tracking and accountability

It is important that the Project board and the Organisations exec board have clear visibility of project progress and tracking against the agreed schedule and budget, this should include any changes to risk classifications.

The reporting structure is often unnecessarily convoluted, with multiple updates required in a multitude of organisation mandated templates. To counter this we often establish an agreed single reporting process at the very start of the project, which is deliberately concise and easy to read. Another important factor that is often overlooked is the appointment of a suitable SRO who has a vested interest in the project and can drive the project forward at an exec level.

 

4. Benefit Tracking

As part of initiating any project, organisations generally expect a benefits realisation plan, this usually details (at varying levels) the expected quantifiable and qualitative benefits throughout the project and proceeding years following project completion.

In theory this is great, however in practise the benefits are often put to one side once the project has completed. The focus switches to go-live issues, solution updates and general maintenance of the solution, this means that the benefits (the reason why the projects was started in the first place) are often not realised as the tracking of them has ceased. It is important to ensure that you keep the organisation focused on the benefits.

 

5. Ratified Decision Making

If key decisions are made in silos or without formal approval (i.e. at Board / Exec level), you leave yourself and the project open to repercussions at a later date.

We always ensure any significant issues / changes in scope of the project are documented in an SBAR which clearly describes the following; Current Situation, Background, Appraisal of options, and Recommended option. This is then presented to the Project Board and Exec Boards for approval.

 

6. Resource commitment

An organisations internal resource availability (or lack of) can be a major dependency for project success. Middle management often commit resources to projects where they would normally be fully subscribed to BAU tasks, this would mean resources do not have capacity for project work.

To counter this, we have successfully used a number of approaches, including an agreed lead time for project work requests, which is approved at Exec level. Ensuring that the directive is understood by middle management. We also create a resource matrix with the resources and their management leads which outlines an agreed allocation to BAU and project tasks.

 

7. The line between BAU and Projects

One of the greatest misconceptions is the difference between a piece of BAU work, and a project. This ambiguity is also a method used to fill a resource gap in a BAU team i.e. packaging a BAU piece of work as a project. Although in theory there is nothing wrong with this approach, it does skew the management / governance boundaries between BAU and Projects. This is almost always a very temporary fix, rather than a long term sustainable resource solution adding skillset to the existing teams.

One way we differentiate the two is by simply checking whether the resource acquired for the project are still required once the project is complete. If this is the case, the initiative is more likely to be a BAU piece of work (however this is not a hard and fast rule). It is recommended that this assessment is completed as part of the project mandate.

 

Useful Links:

Our Service Brochure Is Available On Our Website

 

Share This: