‘There are no IT projects’ – managing organisational change in IT projects

Many IT projects are not completed on time, on budget or fail to deliver much value to the end users. This is especially true for large IT projects, such as IT projects executed by national governments. One root cause of these problems is lack of management of the organisational non-IT aspects in these projects. We explain how to handle these aspects using a new perspective and the COPAFIJTH method.

This article is part of a series that accompanies the university course on software project management by Joost Schalken, Jeroen Arnoldus and Sieuwert van Otterloo. The series consists of  (1) creating a vision, (2) project scope, (3) managing non-fuctional requirements, (4) effort estimation, (5) risk management, (6) planning and scheduling, (7) organisational change,  and (8) recommended project management books and articles.

An example of challenged projects: C2000

The Dutch national government has noticed that many of its IT projects are not completed on time and budget, even when these projects are given massive budgets to begin with. One of these projects is the C2000 project that was started in 1996 and completed around 2006. The goal of the project was to build a national wireless communication network for all emergency services. A sizeable task, but very doable from a technical perspective: The Netherlands is small and flat without major geographical challenges. The original budget estimated in 1993 was 600 million euros (we recommend conversion to personyears to visualise such large numbers. This is enough to pay 800 people for five years). The actual cost was 166 million euros more and the project took two years extra (all numbers from the official C2000 project evaluation). Due to this significant overrun, this project was one of the 8 projects that were investigated by the Dutch Parliament, in their enquiry into IT failure.

The causes for the delay and cost overrun are organisational rather than technical. One crucial mistake in the management of the project is that it was seen as a technical project. There was no attention to governance. Stakeholders of the project (hundreds of local emergency services) were not involved from the beginning. The project could thus have been executed much faster with more attention to organisational aspects.

How to manage organisational aspects well

Managing organisational aspects is actually not difficult. There is no rocket science behind it. It is just a matter of involving the right people, and taking sufficient time for each aspect. It all starts with the right perspective, and the best way to summarize this perspective is: “There are no IT projects”. Almost any IT project (with a budget and a business case) are started with the goal that people to work together in a different way to achieve business results. Instead of focusing on the software components, the project management should be focusing on the people. How they work together, and what will motivate them to work together in a different way. Once you decide that this is important and that at least some of the effort and budget should be spent on these aspects, managing these aspects is not so difficult. We recommend to treat any IT-project as a change project with some IT-components. You should create any IT project plan from this perspective and make sure at least half the plan deals with non-IT aspects.

As the graphic shows, some development team members have of limited view on software development projects, as shown on the left. For project management, a more useful view is given at the right, with organisational change almost as large as the IT aspects.

COPAFIJTH: a project method for organisational change

COPAFIJTH is a simple structure for creating organisational change plans , that has been in use at Dutch organisations since at least 2006. We heard the term first at ING, but it was probably invented elsewhere and much earlier and has its own wikipedia page. The way to use COPAFIJTH for managing project is the following way:

• Create a basic project plan with 1-2 pages of ideas for each letter in COPAFIJTH.
• Share this document with all stakeholders, asking them for feedback and approval. Ideally you should find someone in the organisation responsible for each aspect, and get their approval and commitment to be involved in the project as a stakeholder.
• Plan and execute activities for each aspect from the start of the project until the end.
• Communicate progress for each aspect every month to all the main stakeholders.

The COPAFITH aspects are:

1. Communication
2. Organisational structure
3. Personnel
4. Administrative organisation
5. Finance
6. Information flow
7. (J – juridisch / juridical) legal aspects
8. Technology
9. Housing

In each case, the project manager should not try to do the work herself. For each topic try to get experts from the organisation involved, and let them specify and plan the activities. You will achieve more as a project leader by relying on and interacting with a stakeholder.

One drastic way to make sure non-IT aspects get enough attention, is to have two project managers: one focused on anything IT-related, one focused on everything else. Of course these two people should work closely together. Alternatively, one can decide to have no project manager on the software development, but only for the organisational aspects. In many agile methods such as scrum, the software development is managed by a scrum master, team and product owner, without project management.

Privacy and security

In the past two years, two organisational aspects have become much more important in IT projects: security and privacy aspects. Due to new privacy laws, addressing security and privacy has become mandatory in any organisation that handles personal data. See for instance the Meldplicht Datalekken. We recommend adding two chapters to any project plan: one for security and one for privacy. The original legal chapter is also still needed, but deals mostly with intellectual property and open source. The chart below shows what a comprehensive security approach would like like. Again, only one of the layers (IT applications) deals with software development. The others are just as important.