Over the years, I’ve been involved in a lot of IT projects for government. Inevitably, they involve long timelines and huge investments that are driven by a supposedly robust governance framework. Trouble is, significant numbers of these projects never get finished, or launch feature-incomplete, or simply fail.
I share a view of IT projects in the Australian government that reflects much the same opinion as Dominic Campbell has of the UK government. Too heavy. Too slow. Lacking innovation. And wedded to outmoded views of IT project management - James Governor of Redmonk’s comment is spot on. Dominic’s discussion of portals, bringing eGovernment into the 80s and 90s, wasted millions (and billions) and the need to invest in a dramatic and quantum cultural change resonate strongly with me.
Recently, I’ve been involved in a government IT project that is a small part of a significant body of work (nearly AU$500M). Significant parts of this body of work are to my mind taking too long, spending too much money, using too many resources (and often of the wrong type) and using traditional waterfall approaches to PM as the people on the projects are bound up in outdated thinking.
The project I was involved in, however, took a different tack. While still “fitting in” amongst the larger work, many of the activities in the project were done iteratively - small, manageable chunks of work where tangible outcomes with a significant chance of success were done, often in parallel. It’s one of the few projects in this larger program that I think has a decent chance of launch with everything working and everything having been done with a happy medium found between business need and the actual user requirements.
Government in Australia and apparently in the UK makes a lot of noise about providing value for its constituency and connecting, yet the approach to IT projects is usually so cumbersome it is near-impossible to implement anything in a timely way. As for the notions of open and online government - real Government 2.0 - it’s still a pipe dream, and mostly in the dreams of consultants and evangelists like me who are passionate about the ability of government to connect to the people and provide a real channel for service delivery and brokerage of information.
It’s high time for IT projects in government to adopt a more “just do it” approach. Lighter weight. More iterations. Quicker time to launch. Of course this needs to be balanced against good governance of the public purse, but when you have a 70 per cent failure rate, it wouldn’t be hard to find improvements.
When thinking about this type of rapid iteration, small chunk approach to projects, I think it is also hugely important to consider the affect on the user base. Although it can be fantastic for the project team, often the best approach for the user base is a huge, big changeover. We shouldn’t underestimate the amount of time needed for users to readjust every few weeks to their system changing (and the subsequent affect on confidence etc). This approach can mean you push costs from one part of the organisation to another - from IT to the users.
Now I don’t care if my time tracker adds features regularly or if my todo list app changes every few weeks. But if I were a staff member in a data processing centre or call centre, I would be completely thrown by incremental changes to my routine.
Donna, I’ll agree with you, mostly on the impact you raise. I think an approach akin to the more mature Web 2.0 apps would work well - small, considered, tested changes to interface and functionality, introduced over time and socialised with the user base through an appropriate mechanism.
I look at the way sites like Flickr, the Google apps, Salesforce, Slideshare and the like introduce incremental improvements in their apps and can’t see how this approach couldn’t be adopted in the public sector.
Dominic and James seem to agree, unless I’m tragically misreading them. And they certainly know what they’re talking about - James is highly respected and Dominic certainly knows his stuff.
Nice one - spot on. Think Google, very small teams - no management of the actual conception and POC. The best get up…Gmail etc
Sprint is the way to go.
Steven my dear, I don’t give a fig if Domenic or James agree or not. I have worked in many government organisations, as have you, and I *know* what is involved in making change. There are bucketloads of process-based jobs where ‘socialising with a user base through an appropriate mechanism’ will not work. The appropriate mechanism is to acknowledge that there are many jobs that, and many people who, do not suit rapid change. I can just hear them now: “we used to get big changes and training once a year - now the system changes every month and we don’t get any training. I don’t know what I’m meant to be doing.”
There are levels of comfort with change and most big government systems are used primarily by people who are less inclined to enjoy the change than the consultants who enjoy dropping it on them.
For every project there is an appropriate amount of change. Neither end of the spectrum is right, but somewhere along it, considered per project, is.
Hi Steve,
I think that Government 2.0 has less to do with development methodology than it does with radical transparency and ease of access - that is, it is a noun, not a verb.
Just on the discussion that Donna and yourself are having - I think that agile development can be done humanely, it just usually isn’t, and I have yet to see a truly humane web 2.0 output that fills a human need while being cognisant of human frailties (that is, it is for everyone and not just the cool kids). I want my government to be humane, not just to me, but to the Nannas and to the African refugees and to the bandwidth-poor.
That said, pbs.gov.au proved that highly iterative design has worth in government - again, if it is done humanely.
Best regards, Andrew
Andrew, yes I’m mixing notions here - not invalidly I think. I believe openness can apply as much internally as externally.
Agile (appropriately so) approaches to development can work in large projects as done in government, and your example of PBS should be held up (and documented, frankly) as a case study of how it can be done right - in the open and using frequent, easy to consume iterations. Exposing the end user to ongoing progress and change across the project lifecycle introduces a situation where the product target audience has familiarity before launch and already feels comfortable with the product by the time the encompassing, large project, goes live. You get the ability to do big, long projects with significant long term goals while achieving a great deal through open, internal iteration.
And Donna, yes, I’m idealistic and happy to wear that badge. But it’s only a matter of time before an audience exposed to rapid-iterated applications on the Internet become the mainstream users and managers of business applications and will expect them to be developed this way. This approach is already being adopted by some of the big vendors, but is yet to see significant light of day in government - which I think, suffers for the fact.
We can agree to disagree on the ability of a user base to cope with change and the extent at which that change becomes complex and a hurdle rather than something the users are comfortable with so long as the rate and volume of change is properly managed. In much the same way you talk of your comfort with change in your to do and time tracking apps, it’s only a matter of time before this approach becomes the norm and expected.
To Donna’s point service delivery is a spectrum and should be treated as such.
There are those that think its satisfactory to spend three years building a system spec’d out by business process consultants that never talked to the people who would actually use the app, and then give the people at the sharp end a day’s training on the new system by someone that didn’t write, and will never use, it.
That’s one approach to change management. absolutely. Those that are resistant to change know best, and we should do everything we can to support their needs.
But I am a tad surprised that an expert in usability testing is apparently keen to defend the status quo in public sector IT delivery. If you think its working Donna, good on you. But I would like to see my taxes better spent, with public sector employees happier and less shat on. Waterfall, and massive upgrades just don’t work. The proof is by experience.
Andrew- have you ever used Facebook? There are plenty of things not to like about it is “a truly humane web 2.0 output that fills a human need while being cognisant of human frailties”. If the public sector could begin to deliver a fraction of Facebook’s usability to employees and citizens we’d all be in much better shape.
Good applications do smart things well, using an iterative approach can deliver really good results when your team members are smart enough to think things out, but they need to be exposed to the business as well.
Just because your using an iterative approach, doesn’t mean you users are going to be combating constant change
Often on projects the developers are quite isolated from their users, communicating thought a PM ‘interface’ which limits their chance to develop an broad understanding and come up with smart solutions. The silo approach is so 1990’s.
Solving those niggling problems elegantly can make a big difference on a project. That doesn’t mean taking a cowboy approach, but often just fixing these kind of problems can saves a lot of time and raises team moral. Never underestimate team moral.
Striking the right balance is important. The tools we work with have improved dramatically in the last 10 years. A different project management approach is required than was used in the days of predominately C++ development.
James - I’m not saying the status quo is right. I’m saying that we need not to evangelise either end of the agile-waterfall spectrum, and remember there are real people with real human abilities and frailties to consider. I’ve worked on waterfall projects that were truly user-centred throughout and achieved remarkable results; and agile projects that dumped unusable rubbish on people regularly. It isn’t the methodology that makes it work.
PS - I’m a designer, not a usability tester ;)
The worst Australian govt. IT project award would definately have to go to the team that did ICS. It is so bad, it’s beyond process: the team was clearly and unbelievably incompetent. Perhaps it is the tendering process in the beginning that is borked?
Would you admit to being a part of that team, if you were?
One of the issues I see with gov’t websites is that there seems to be no room to clear out the cobwebs among the web team… I admit my exposure has only been very briefly in two departments at State level.
While gov’t personel just flop from dept to dept and no real incentive to push new ideas why rock the boat right?
Just my opinion in passing. Some people will do a “get and sit” in their jobs if there’s no incentive to try to improve. The first thing gov’t need are new blood coming in rather than just passing old hands around. Its simply about bringing in change agents and new blood.
Web 2.0 Gov’t sounds good but my point is the people mostly in positions to push that through are either “get and sit” or not IT in the first place.
@KatB - While I wasn’t a member of the ICS project, thankfully, I’d personally have no issue with identifying with failed or problem projects.
What I would be doing along with that is identifying what I had a hand in that was done right on the project, that I wasn’t listened to where I identified issues (if I did) and potential solutions to those issues and ultimately the lessons I took out of the project.
Every project, even the disasters, has the potential to be a valuable learning experience and people will respect you for being prepared to identify with that.
@STeven Clark - I agree that web (and IT generally) units in a number of government departments are staffed with demotivated people for whom the web is a job, rather than a passion. I think this needs to change.
That said, I also know a number of very motivated and very smart people in government agency web units who are stifled less by themselves and more by organisational inertia and management resistance to change and the introduction of new approaches and exploitation of new opportunities. Eventually this will change. Until then, things unfortunately need to be done under the radar and gradually to encourage change.
While I agree that major upgrades require change management, it’s incredibly frustrating when minor patches, fixes and corrections are subjected to the same degree of scrutiny and interminable timelines. Correcting typo’s in interfaces or information shouldn’t mean re-testing an entire application. Installing a point upgrade to something that is already accepted and will actually resolve a known problem shouldn’t require a new project. Some govt IT departments are so risk averse that it’s basically impossible to introduce change, and it is only periodically forced upon them when their technology is simply no longer supported.
As for Govt 2.0, frankly there’s a lot of govt work that you don’t want to see, in the sense that it’s utterly boring. I support govt web services but I don’t really want to be in a ‘community’ with the Tax Office (though I know some nice people who work there).
Depending on your politics, I’d argue there’s also a lot of govt work they don’t really want you to see, eg, lobbying and funding. But there’s way more of the plain boring stuff.
[…] Collins suggests that there should be a Just Do It Approach to IT Projects in […]
A big part of the problem with IT development in the government sector is the terrible decision to outsource some parts of each department’s IT. In my current department it was the infrastructure that was outsourced, so there is a third-party involved every step of the way - as if change control procedures aren’t sufficiently onerous anyway. In other departments the infrastructure is managed in-house and the applications are supported by external companies. Some departments have multiple outsourced agreements. This seriously increases the overhead on development projects.