The recent “Is Government IT Getting Worse?” provided just enough of an overview of the state of digital government to get me fired up.  

I don’t understand why we keep reviewing these things called “IT Projects”. For as long as I can remember we have been saying “it’s not an IT project, it’s a business project”. I got sick of hearing it not because it wasn’t true but because it was trite.

But we are still assessing “IT projects” and trying to improve the IT parts of change efforts in isolation. 

The inevitable result of this is either over engineered “requirements” focused effort or the popular half-solution to half-the-problem that is “agile”. 

While it wasn’t always the case, over the last 10 years or so every IT department I have worked with has had a more ounerous and often self-imposed discipline around managing change projects than other “departments”.  

You read that right – IT departments are trying desperately to improve their project based discipline and have pushed ahead of most other departmental or cross department program management office (PMO) initiatives. 

I see it everywhere. But because IT departments are taking the time to package change as projects they are subsequently driven into a position where they have to justify spend more elaborately. Also, where they have to justify spend more elaborately this makes IT change more project based.  

On the demand side, PMO initiatives have been dumbed down so much that without the discipline imposed by IT they would have almost no impact.  

Perhaps the worst combination is “the business” trying to take control of IT with the IT department letting them (i.e. “Agile”).  

Of course, there are improvements and a backlash against this approach. Much of the “digital” discussion is trying to solve this too – in ways I don’t always agree with. But while I often don’t agree with Paul Shetler when he talks about fixing procurement as an enabler of better digital outcomes he is spot on.

But in terms of having to justify the activities, IT departments always get a raw deal. It’s very difficult to justify IT activities in the same way you justify activities that have more concrete outcomes. “IT Projects” when defined as such cannot claim or commit to many sorts of benefits because they are by definition just the “IT” parts of the initiative.  

So when you assess “IT Projects” you are assessing an increasingly arbitrary sub-set of the value chain towards outcomes.  

You have to assess value creative, and change initiatives as a whole – not just the IT bits. 

Whatever effort you assess as “IT projects”, you can guarantee there is double that being spent on “IT” in other budgets. Also, you can guarantee some of the service outcomes being attributed to IT spend are from initiatives that never had any IT spend allocated to them in the first place. Or that had insufficient IT spend allocated to them. 

Rather than yet again assessing the “IT Projects” why not assess change initiatives in general? Why not look at:

  • Change initiatives such as new policy deployment, data capture and form changes, new business-lead deployments of technology and see how they were managed
  • Where change initiatives didn’t have IT budget the ownous must be on the initiative to justify why. Surely, every change initiative has IT impacts – at the very least on capacity of standardised IT services
  • Where change initiatives did have IT budget how do they compare in performance to “IT Projects”? (Oops, now I’m doing it)
  • What was the contribution of these change initiatives and how did they impact service?

We live in a world that is capability-based. The functional organisation is completely dead. The idea of an “IT Project” is completely dead. 

By continuing to look at inherently disconnected initiatives like this we are causing more problems than we are solving. 

It also means we have to be careful about delivery approaches. When an “IT Project” is spending 60% of its budget on design thinking workshops to try to change the way service is delivered that is in some ways admirable. But it’s not “IT spend” in the sense that it is guaranteed to improve outcomes that would be attributed to IT. In fact, it might arbitrarily reduce the investment in certain types of quality. Less time coding is less quality – regardless of how much of an improvement there is in what is being coded against what would have been coded.