Heute 52

Gestern 1472

Insgesamt 39726648

Freitag, 27.12.2024
Transforming Government since 2001
By Neil Goodall, the European managing director of Tescom, and former banking programme director for the Post Office, where he headed up arguably one of the most successful IT projects of 2003.

The Public Sector is often considered inefficient and ineffective when it comes to technology deployment. Here he outlines his suggestions on best practice for handling IT projects in the Public Sector. "A large scale IT implementation project is a huge undertaking for any organisation. Within the Public Sector, when public funds are being used and the smooth running of public services is dependent on a successful outcome, implementation becomes a matter of national concern.

Rather than just keeping the internal corporate stakeholders appraised of project progress, the external world also needs additional guarantees that projects will be delivered on time, on budget and to the required quality. If not, questions on misspending, poor decision-making and bad management cloud the picture, diverting attention from the real issue of what went wrong, and how to avoid repeating the same mistakes.

Managing a major IT project is not a part time job. The sheer time and effort required to oversee activity, manage suppliers and stakeholders and the numerous ad-hoc issues that arise requires a dedicated team, with a project leader who has the will and the commitment to see it through. However, too often, and regardless of project scale, the seeds of failure are sown in the early stages.

Too many projects fail because those responsible for the project are expected to consider the work as additional to their normal roles and duties. Particularly in the public sector, where spending is tightly controlled and regulated, it can often be tricky to allocate appropriate resources outside the core IT team to ensure that delivery is a priority.

The right approach and procedures must be in place from the start if a project is to be a success, and this begins with the project proposition. Problems typically arise because of a ‘requirements mismatch’ – what the organisation thinks it has asked for differs from what the potential suppliers think they are being asked to bid for and supply.

This can actually be due to a lack of internal communication - the business needs of the organisation are not clearly communicated to the IT department, or vice versa, and there is no ‘combined approach’ in terms of the overall bid to ensure that all elements are communicated to the supplier effectively. However, it can also come from the supplier side.

Of course, if not resolved upfront, this mismatch will be magnified several times over from the procurement stage onwards! To prevent this, the organisation needs to introduce the potential vendors at the proposition stage to determine whether or not the project and its aims are viable because ultimately, IT project viability can only be determined by technical experts. It’s important to establish this upfront dialogue between all project stakeholders, the business users, IT department and suppliers, to get everyone ‘on the same page’ from the word go.

It’s also vital to involve the procurement department at an early stage. If the project specifications are to fit policy, those involved need to fully understand its purpose and requirements from the outset. Leaving procurement involvement to the contract negotiation phase or later runs the risk of highlighting potential issues late in the day, which will be time consuming and costly to fix.

A further point here - as executives are rarely involved with the actual contract negotiations, it is also vital to check on progress during negotiations literally on a daily basis to guard against deviation from requirements and avoid mismatch.

As suppliers are generally required to develop solutions to integrate with current systems architecture, they need to be fully aware of what existing infrastructure their solution needs to work with and any performance issues. This may seem obvious, but unless a full and frank discussion is held, the new solution, designed to run on a high performance infrastructure, will end up working incorrectly.

Only if all existing infrastructure glitches and issues are flagged up front can they be taken into account and the solution designed to accommodate and compensate for these.

Perhaps most importantly, don’t assume that once the project starts, the suppliers will simply deliver against the requirements and timelines. Regular, ongoing progress reviews are integral to managing development and implementation and these have to include honesty on both sides.

This is where one major aspect of project management that has been severely under-utilised over the years comes into play - testing.

The traditional approach to this aspect of project management has either been to rely upon the suppliers to test their own solutions or else bring in testing specialists towards the end of the project. However, using testing experts and a testing strategy throughout the project lifecycle is a proven way of achieving better results.

Bringing in independent testers to work as part of the project team from the moment contracts are signed means that systems development can be accurately tracked from the outset. This allows project managers to really optimise their IT implementation plans – using crucial expert knowledge to help with managing suppliers and bringing a new level of accuracy to the regular project progress checks. And of course, if critical defects are identified as soon as they occur, they are far easier, and considerably less costly to rectify.

Overall, project teams, whether public or private sector, must take on board a very simple principle that despite pressures to act otherwise, it is upfront investment in time, money and effort that will ensure the success of the endeavour.

Public Sector IT implementation will always be high profile – but following these simple steps will ensure that both the Public and Private Sector are able to deliver against internal and external expectations on a much more frequent basis."

Quelle: PublicTechnology, 20.04.2004

Zum Seitenanfang