Has IT project management got anything in common with International Development?
In November I had the opportunity to participate in a review of a large and complex government IT project. Over 5 days we met a wide range of stakeholders, reviewed reams of documents and had a series of meetings with the project’s delivery team. Despite the hugely different context, there were a number of themes that were uncannily familiar to my experiences of international development. Here are a few headlines.
1. Clarity on the purpose.
The IT project purpose sounded straight forward from the start: to build new IT infrastructure. But the closer we looked, the more it became clear that the project was actually trying to change behaviour and the way public servants from multiple departments worked and shared information. The IT infrastructure was actually the ‘easy’ bit, the enabler of a wider set of changes (the UK National Audit Office has an interesting report on this kind of ‘IT-enabled business change.’)
In international development we have probably all seen projects that focus on the ‘easy’ structural aspects of development (the numbers of schools built, people trained, ministries reorganised etc), losing sight of the long-term changes that will ultimately determine sustainable poverty reduction (changing attitudes or behaviours, empowered communities, accountable institutions etc).
2. Flexibility to adapt to changing contexts
The IT project had changed significantly since it was first approved, shifting as the team realised the importance of ‘business change’ and as the context changed with a new government and subsequent policy shifts. Yet the Project Management Office (PMO) has continued to spend a disproportionate amount of time writing and re-writing business cases and ‘benefits plans’, trying to fix the project down, only to find that they are redundant before they finished. All – by their own admission – pretty nugatory, but perceived to be required by their Board.
In international development we have probably all seen contexts that are even more complex with shifting community needs, national politics and changing priorities in home/funding countries. And yet, project proposals often appear to attempt to fix things down at very early stages, leaving very little room for manoeuvre, testing or experimentation.
3. Optimism or ‘strategic misrepresentation’.
We concluded that the IT project team (and its sponsors) repetitively displayed a real lack of realism in planning how long it would take to implement this project (and how difficult it would be). In depth discussions illustrated that this wasn’t because they really believed it was possible in the time-frame. The problem was that they knew it was politically and operationally unpalatable to be honest about how complex the project was. Bent Flvjberg has done some great work on these forms cognitive bias in major projects.
In international development, we have probably all seen projects that propose hugely ambitious changes in short amounts of time to meet donor expectations and funding cycles. Whether this is simple optimism or intentional over-promising to secure approval is hard to determine. [I often wonder how credible some international development organisations’ proposals would be if they were trying to achieve the same goals at home in the US or Europe?]
4. A focus on the project without considering the wider operating environment.
Each successive year the IT project had under-performed and three previous review teams had made a number of improvement recommendations. Each time, these focused on ‘technical’ actions that would get the project ‘back on track’, for instance: faster contracting, more staff, better user testing, more training etc. All important issues, but the project never really considered recommendations relating the wider environment, where they had limited control but where the real changes might come from, i.e. the legislative environment, the politics, inter-departmental collaboration etc.
In international development we have probably all seen projects ‘plough-on’ despite a weak or unsupportive enabling environment because organisations need ‘to act’, be ‘seen to act’, continue given the ‘sunk costs’ or – worst of all – hit spending/ execution targets.
5. A lack of time to listen to real people, reflect, learn and iterate
The PMO had developed hugely detailed Gannt charts and plans for the roll-out of the new IT package and associated training. While there was plenty of ‘user acceptance testing’ there was no way for users to actually shape how the project, IT software and training evolved over time.
In international development we have probably all seen projects with useful monitoring mechanisms to consider ‘beneficiary feedback’ but that don’t have the time or the genuine commitment to elicit views or ideas from communities to shape current and future interventions. So, although people hopefully get to tell development organisations what they think, it is usually too late for them to actively shape interventions.
The role of scrutiny
It was interesting to observe how the various stakeholders we met had differing views of the purpose of an external review:
- Many saw it as a compliance task that had the be got through (and survived);
- Some saw it as a way of validating what they were doing and extending their permission;
- Others saw it as a way to lobby us to influence other stakeholders;
- A few saw it as a genuine chance to receive critique and challenge, to gain an outside view.
What struck me was how quickly an external review team was able to become sufficiently fluent in the project to provide a credible external perspective. It was fascinating to observe the value people (and the project) got depending on their stance towards the review; those who genuinely wanted and valued scrutiny seemed to gain the most.
So what can the international development world learn from this?
The IT community has tried to address a number of these challenges through ‘agile’ methods, explained in ‘agile delivery’ and the agile manifesto. There are some important principles in these approaches which are a good start and warrent further consideration in internatioal developent programming. There are interesting links to what we have been calling ‘flexible and adaptive’ programming, the ‘doing development differently’ manifesto and ideas on ‘thinking and working politically’. Theses are all good examples of attempts to get better at learning, adapting and addressing these kinds of issues.
It struck me that in international development we often ignore ‘domestic’ project management experience (and vice-versa) as our project contexts seem to be so different. But thinking about the kind of challenges this IT team face, I wonder if we have more in common than we might think?