Best practices for managing large-scale IT projects (part 2)
In this second part of the interview with Johan Vorster we will examine the importance of having proper governance structures in IT projects, and some best practices in managing large-scale IT projects. Did you miss the first part? Read it here
How to establish governance structures that deal with the interest of various stakeholders?
I have seen many exciting projects fail merely because the governance structures were not in place. When you deliver a project to a customer, both supplier and customer should have proper governance structures in place. A sound governance structure provides adequate oversight, objectivity, responsiveness, openness, fairness and accountability. It should also be able to efficiently deal with conflict.
Many books have been written about governance, I like to keep things simple so generally speaking my idea of proper governance is that any person should know exactly what is expected of him/her (have a clear mandate), there should be proper oversight of any individual or group, there should be a clear separation of power at all levels (i.e. no one person should have authority to single-handedly take important decisions), there should be traceability and proper documentation. In a project environment, there should be oversight bodies with a written mandate to monitor progress, approve deviations (change management) and have oversight of all activities.
At the onset of the project, one of the first project deliverables should be the finalisation of the governance structure. It needs to be an action item to be completed before the project execution commences. The governance structure should be documented, and it should define some bodies, how they are staffed and what their role and mandate are. A central steering committee should be established as the highest decision-making authority of the project. Both supplier and customer should formally mandate individuals to sit on the steering committee and take binding decisions on the project. The steering committee should monitor progress and approve change requests.
The mandates of the supplier project manager and customer project manager should be documented. The mandate and role of the central project office should be recorded. RACI models should be drawn up for all major process detailing who should be Responsible, Accountable, who should be consulted and who should be informed at every step of the process. A body should be established that looks after the software development baseline and prioritising of user requirements. Staff from both the supplier and customer should sit on this body. This body should recommend new software functionality priorities to the steering committee for approval. Once the governance structure has been documented, both supplier and customer should approve the structure. The positions are defined in the governance document, and the execution of the project is then done under this governance structure.
- How to deal with a project failure?
Projects that have a formal governance structure with a central steering committee should have a much lower change of failure that projects without proper governance structures. Assuming a project has a central steering committee, this should deal with project failures. A project seldom fails abruptly. Normally, red lights start to flash somewhere along the project timeline, and the risk committee should pro-actively alert the steering committee of interventions required. Ultimately, the steering committee should take accountability for the success of a project. If it fails, it is their failure. When it does happen, and the project is halted, the steering committee should decide on a wind-down plan. Parties involved might want to look at their recourses as well.
First of all, the scope of the project should be clearly defined and documented, with a detailed change management process agreed by all stakeholders. A written governance structure needs to be approved by all stakeholders, roles and responsibilities should be established, and a decision-making structure that can avoid deadlocks from happening should be created. An excellent administration infrastructure should be implemented via a central project office, including project communication; work share between different suppliers or sub-contractors should be clearly defined and be based on a logical work breakdown structure, to avoid ambiguities. Finally, the project should have a formal risk register and a risk committee that sits regularly and deals pro-actively with project risks.
About Johan Vorster:
Johan Vorster was born in Pretoria and completed his degree in Industrial Engineering at the University of Pretoria during 1983. He started his career as Industrial Engineer at Iscor Vanderbijlpark.
In 1996 he establisheed the first driving licence card manufacturing and personalization facility in South Africa and the South African Development Community (SADC). He was also responsible for the supply and support of biometric capturing units for collection of driver information in 350 sites countrywide.
In 2001 Johan was appointed Chief Executive Officer of a consortium for the redevelopment and replacement of the National Traffic Information System (eNaTIS). He headed a team to develop a brand new National Traffic Information System, creating a national data centre, disaster recovery centre, a national help desk, nine provincial help desks and replaces hardware and networking infrastructure at some 1,300 sites countrywide for 3,000 users.
You can follow him on Twitter: @