Achieving predictability in technology delivery

Let’s return to the key risk I presented last time: when Technology becomes known within the Business for its problems, it ceases to be an enabler and becomes an impediment. In this situation, what can be done to return Technology to be a business enabler?

In this short term, the answer is to create predictability in technology delivery. Get in flight projects under control, have a clear view of what’s coming up, make sure new work intake gives new projects the best chance of success. Let’s take these three in turn.

It’s difficult to plan for the futures when you’re fighting fires today. It’s difficult for the business to believe you can plan credibly if you don’t have credibility today. That’s why I advocate not worrying about target operating models or optimal processes until in flight deliveries are well understood by all. This doesn’t mean calculating a new target date to hit, but understanding and communicating the key risks to hitting that date, and making sure all the stakeholders know and agree the compromises being made to hit it. Because this new plan will inevitably be wrong, but at least this time everyone will will be well-informed ahead of time to make the right new compromise.

Once today is figured out, it’s time to turn the attention to tomorrow. That doesn’t mean committing to an 18 month milestone plan to act as a contract between intersecting projects. I advocate the scaled agile tool of programme increment planning. Create a portfolio backlog of projects and get the business to explicitly prioritise. This will take the ability to plan with uncertainty, but it’s not worth spending too much effort because the objective is not to plan out in years ahead, but to work out the relative priority of all the things we could do.Then collaboratively, but explicitly prioritise to decide the things we will do.

Zoom in on the next quarter (PI). It’s only at this stage that it’s worth doing small design up front to be confident with T-shirt sizing of projects. Equally, the business should do small modelling up front to work out contributions to organisation-level metrics (normally ROI). This is just enough planning, and no more, to be able to describe a list of projects that we will be confident of delivering in the quarter (doable even with contingency), ones that we might do (doable if we ignore contingency), and ones that we won’t do - but might do next quarter if prioritised by the business. At the end of this process, all business functions will have the same view of what is planned to be delivered in the next quarter (PI) and the roadmap for beyond.

Now that everyone’s agreed on tomorrow looks like, the final part of creating short term predictability is to control the flow of work from the tomorrow list into today’s work: the work intake. The exact nature of work intake will vary to match the specific challenge of the organisation, but always is some combination of culture, collaboration and capability (which I prefer to the more well-known people, process and technology). Always start with culture, because culture sets the tone for everything else. The team should be trusted with an internal locus of control, trusted to make the right decisions for the project and the autonomy to follow-through without needing approval. Within the team there should be a culture of continuous improvement through measurement and reflection. And throughout the business there should be a culture of psychological safety so that the team can communicate bad news with the expectation of being given more options to mitigate beyond “just hit the date”.

However most tasks need another team to either start or bring to conclusion. This doesn’t mean weekly programme status meetings across all work streams, and management through never-ending action logs - this is a total waste of time. Instead I prefer tailoring the collaboration to the context. For example, at work intake, the work should be defined with just enough documentation to enable the work to start. Hypothesis-based business change design, solution architecture, UX design and desired timeline is a good start. With assigned accountability, transparently available, and maintained. When the project is in flow there should be plenty of opportunities to collaborate synchronously and asynchronously. This time is as important as coding time. Perhaps most importantly, once collaboration has yielded a decision, once disagreements are negotiated, decisions should be committed until significant new information is developed.

The team should fully capable, with all of the skills to deliver within the team members thereby shortening the decision-making cycle. Most difficult, the team members’ time should be exclusively allocated to the project (for the duration that their skills are needed). Most companies choose not to do this then suffer from the huge overhead of multiple people managing their efforts on multiple projects. It’s possible to do this, but not to do it well.

Even with all this, it’s likely that a project date predicted at the beginning of the financial year will be missed. But the knowledge that a date is at risk will be available earlier, more teams will have enough knowledge to collaborate on mitigations, and the business will have the right information to reprioritise based on impact upon business success metrics.

In summary, to achieve predictability in technology delivery I recommend starting with:

• Securing in-flight deliveries by identifying and communicating risks and their mitigations;

• Programme Increment planning to prioritise and reprioritise the roadmap of work;

• Setting teams with the right culture, collaboration and capability to be successful.

In a future blog I’ll be looking at what should be done in the medium term, which boils down to how to courageously implement a growth mindset.