When I say IT prioritisation, I mean the process by which we choose how to spend our limited resources within an IT organisation in order to deliver value. It doesn’t matter if the value for you is internal efficiency,...

Photo by Vladislav Babienko on Unsplash

When I say IT prioritisation, I mean the process by which we choose how to spend our limited resources within an IT organisation in order to deliver value. It doesn’t matter if the value for you is internal efficiency, external revenue, or anything in between. We simply can’t do everything, so we need to make choices.

These choices are often hard enough to make, requiring us to make decisions using imperfect knowledge in a complex environment, but we seem hell-bent on making it 10 times harder.

Choose a consistent IT prioritisation technique

One of the main reasons that prioritisation is hard for IT is that we don’t use a common structure to prioritise work. Almost everything is guessed at, or driven by which customer or director shouts the loudest. This is chaos. One of the first actions that I would recommend is to establish a common pattern for prioritising work. It’s impossible to compare ‘Feature A‘ with ‘Bug B‘ if you don’t have a process to do so.

There are numerous methods for doing this and they range from the more nebulous ‘value points’, that are effectively educated guesses, to researched-backed economic IT prioritisation using something like CD3. There are pros and cons for both sides of the spectrum. Going with an educated guess is less expensive, but often less accurate. CD3 is expensive but can be more accurate. On top of that, CD3 is actually just an unnecessary layer of abstraction if you have relatively homogenous pieces of work.

Comparing apples with asteroids

The other aspect to consider is the challenge in equating clear and calculable value from new features that a market is demanding to process efficiency bug fixes. Again, there’s a whole range of things outside these two examples but they serve to demonstrate the point. It is much easier to compare two features with ‘known’ expected revenues, but what about the rest of the work? Generally, you’ll be in a better place if you can begin to articulate the value of those less direct items, otherwise, why are you doing it? Being able to at least have a rough guess at what value you’re unlocking by doing bug fixes or intangibles will help you weed out gold plating or ill-conceived ideas early on. This doesn’t need to be perfect, is it…

improving labour efficiency by reducing the time each member of your call centre team spends on something?reducing time spent on quality problems by fixing a difficult area of code?improving uptime by patching some server software?

Identify IT prioritisation categories

Failing this, you can build a profile of work types and prioritise within each category. This isn’t ideal, but not much is. It’s a good start. Define some categories of work and then prioritise within each of them according to a consistent model.

An example for a software team could be:

BugsNew FeaturesTechnical Debt

Maybe a service team would have something different according to their needs:

Service improvementsTechnology updatesSelf-service functionality

When you have identified your categories, plan your capacity by allocating a percentage of the whole to each of them. For instance, you could choose to reserve 60% of capacity for new features, 20% for bugs, and 20% for technical debt.

The point is, pick a scope that works for you and define a consistent method. Then make sure everybody knows about it. To make this work, you’ll need a few other things in place.

Find someone to apply the process

In Agile, this is often called a Product Owner, but the name doesn’t really matter. What’s important is that you have someone capable of making decisions around the priority. There are certain things that must be true in order for this person to be successful.

It must be a single person

Not a committee, not someone from “THE BUSINESS” and a BA and someone else. A single person, otherwise you have no clarity, serious tension, and major decision latency.

They must be empowered

If this person can be overridden by a superior every minute, you’ll create a trust-less, hostile environment, devoid of passion. Truly empower people, protect them, and help them become more effective through high-quality coaching. Aside from the human factor, disregarding a decision by someone closest to the problem isn’t usually a great idea anyway. Speaking of which…

They must be close to the problem

If they aren’t, then you’re expecting someone with limited domain expertise and a poor connection to the customer to be prioritising work. Without being deeply connected to, and passionate about, the problem being faced, then once again you’re operating from a distance too great to be effective. Get on the ground.

They must be close to the team solving the problem

Product Owners who filter their whims to the delivery teams through a BA or Project Manager need not apply. You’re part of the team delivering value, not an isolated pseudo-manager. (Although, if you read and agree with my other post on line management in Agile, then you might actually be their line manager.) The further away from the team that you are, the longer it takes for decisions to be made and the more likely you’ll encounter expensive rework.

Make the IT prioritisation process work for you

I’ve been in a number of different product roles and I know the last thing you want is to spend all of your time fielding requests all day. PostIts on your desk, people impatiently waiting for you finish your call, emails, Slack requests, feedback forms. Choose a sensible and well-defined method for work to get into the system and then police it.

Make it super clear and very easy for people to make requests in a consistent format so that it’s easier for you to appropriately prioritise. Create a standardised request system and then back it up with a scheduled refinement session where people can come and help you explore their needs. The turning up part is more often for internal customers to be honest, but if you can on-site with your external customers then do it.

Conclusion

There are plenty more aspects to consider when improving IT prioritisation, but the key take away is to not make it even harder for yourself than it already is. You can get most of the way by following the steps above:

Determine a consistent method to weigh up work against other work.Pick a single person to make those decisions.Make sure that person is empowered and protected to make those decisions.Get them close to the problem being solved.Ensure they are part of the team solving the problem.

I’d be very interested in how you prioritise and what your challenges are, share your thoughts in a comment.

The post IT prioritisation struggles appeared first on Sean Robinson Consulting.

---

View Entire Post