Are you sure you are setting up your IT project teams for success?

Through time, most governments and organisations have approached information technology (IT) developments as a project. The thinking goes something like this:

• We have an outcome we're trying to reach
• We need some business change to reach it
• We need IT as part of this - so we need a big IT project.??

Faced with this common scenario, we, as organisations, tend to spin up big project teams to focus on technology requirements, change management, user acceptance testing, and other factors that go towards making a technology rollout a success. We invest huge costs, time, and energy into these projects, up to and including the cutover period.

Then we celebrate. There are streamers, balloons, finger food and we pat each other on the back. If it’s outsourced, or if a third party is involved, we promptly end their contract. Or if the project team is internal, we release those developers to work on other things. Maybe one or two folks stay around to look after minor aspects of the build, but we are generally looking to tick the “project completed” box.

The problem with project teams

?The problem is this model doesn't match the way IT works. Or the way business services work. Or even the way the world works!

Using the analogy of building a bridge: when it’s built, you’d assume it's built, right? But it’s not. Consider the Sydney Harbour Bridge. It’s being painted all the time. And when they finish painting it, they start again. Technically, the bridge is never “finished”. It’s maintained and updated by a project team in perpetuity.

The same applies to the systems and applications we build to support governments and citizens. They’re never really done. Even the things we thought were done, are not done.

Take the Registry of Births, Deaths, and Marriages for example. It functions via a computerised system designed to support citizens throughout their whole lives. You wouldn’t imagine a system like this would ever need to change. It has operated under the same scope since it was first created. That unwavering scope, of course, is to record births, deaths, and marriages.?

However, in the last 10 years or so, government rules have changed to reflect how people choose to identify themselves more accurately. This means that the simple assumptions we made 20 or more years ago (that there are two genders: male and female, for example) are no longer valid. Therefore, the system built to support two values with one character for each gender (M or F) now needs to support 20, 30, or 40 different values in the same field.

This is an oversimplified example. But the point I’m making is that we should build all things to evolve, and we can’t always predict how.

From systems to APIs

Today more than ever, systems must evolve in terms of how they are put together and architected. They must adapt to be supportable from a security standpoint because that’s another constantly changing facet of living in today’s digital world. All of this turns the project team and its funding model on its head. Suddenly it’s no longer set and forget. It can’t be.

APIs (application programming interfaces) allow modern developers to build evolving systems, capable of meeting users’ needs for the long term – or the very long term. By using APIs, these developers are saying to their organisations: “Instead of presenting you with a finalised version of the system you requested, I’m going to give you front door access to an implementation, which you can continue to interact with reliably on the understanding that the implementation details may change over time.”

Still, the thought of interacting with a system that is constantly changing is not comfortable for some, even if we are fine with driving over a bridge while it’s getting a fresh coat of paint. And that’s because there’s an element of personal fulfilment in being a member of a project team with a concrete delivery date. What’s more exciting? To work on and deliver a billion-dollar project? Or to be assigned a role in a continuous scope of work worth one hundred thousand per year, for the foreseeable future?

The way we think about projects must change

Old thinking about the way we structure projects needs to change because, simply put, billion-dollar projects can fail, and often do - SPECTACULARLY! Whereas having a mindset of building over time has safety mechanisms built in. It has what we at Amazon call two-way doors.

I’ve talked about two-way doors before [1] – they are decisions that can be made with confidence because they are easily recoverable or reversible. Two-way door decisions result from an “explore-and-learn” versus an “all-in from day one” approach. They allow you to build what’s needed today and incrementally add to your build to meet the future, instead of trying to predict what you might need ten years from now (and inevitably getting it wrong). Importantly, they are not going to bring your project crashing down.

The concept of agile development is user-led. It comes from consuming services from providers like Amazon, Google, and Facebook. If you put all your photos on Instagram, you expect them to be there for a long period. And the Instagram we know today is different to five years ago. As citizens become familiar with these kinds of evolving services, they expect the same from the Government.?

Adopting a new funding model?

Changing how we build also means changing the way we fund the building. It calls for a departure from the traditional method of defining total project costs and putting your hand out. Thought needs to go into what is required to sustain the build.? That sounds more expensive: you might say. But it's simply a redistribution of spending.?

Take for example a legacy system, built ten or 15 years ago - the original builder probably isn’t there anymore. Updating it is expensive because the project team tasked with that job first needs to deconstruct it to understand what it is! Then they might need to spend more time and money trying to virtualise it without breaking anything. This all amounts to a large upfront effort, with costs to match.

Compare that with the prospect of continually modifying and updating a system across 10 to fifteen years instead. In this scenario, everyone understands the system so changes cost less to implement. They become par for the course instead of a heavy lift. So what you spend on an always-on project team, you save in upfront costs.

Rightsizing the project team

The impact of reapportioning the budget in this way is that you start with a smaller project team. On the flip side, you leave a larger team behind. You are shifting away from the “last person turns the lights out” mentality because you have considered the longevity of your system in advance. So instead of leaving two developers to support your build, you might have 20 developers assigned to continually improving your build.

Changing the narrative around projects

What does this mean for IT in terms of communicating with the broader business? It means evolving the narrative, from: “You're going to have to spin up a project to make that change. Good luck securing the funding” to: “Great, let's prioritise it in the next round of updates.” Then, maybe it gets done in the next two-week sprint and changes are rolled into production two weeks after that. Who wouldn’t benefit from that kind of agility?