How do you work with stakeholders to prioritize ongoing enhancements? [closed]

Question

I have several clients with sites and platforms that have fallen into disrepair over the months and years due to a lack of ongoing enhancements, improvements, and iteration generally.

I'm looking for methods or processes to better manage these clients' priorities to make sure that, after we clean things up and make some improvements, we don't end up right back here 9-12 months down the road.

I am considering a quarterly or bi-annual workshop to discuss the state of the platform, review user data, do some user interviews or observations etc. but this seems maybe a bit heavy.

What are some ways you have worked with clients or internal stakeholders to uncover and priorities ongoing enhancements to an existing platform?

Answer 1

...methods or processes to better manage these clients' priorities...

There's no silver bullet and part of that is the ephemeral nature of priorities. They change over time and what's relevant now may not be as important in 9 months or a year, or whatever the time scale is for your clients.

That said, it's good to at least document things as snapshots of unfinished "wish list" items. Essentially, a backlog of all the things:

Indeed, it contains all things. If an item is in there, it might get done. If it isn’t, there is no chance that it will get done. It’s a list of ‘want to do’ items, not a commitment. Items can be estimated (preferable) or not, but neither case implies a specific time commitment for completion.

(Source)

Just take everything you or anyone else wants to do and stick it in a backlog.

Any scope of specific considerations can be managed as a backlog, with someone acting as it's product owner. I have trouble thinking of examples it doesn't apply to.

Let's use "e-commerce UX" as an example. An e-commerce UX PO might be on the hook for delivery of value to the business units via all things impacted by e-commerce user experience, and they'd have a heap of these "wish list" items described as coherent user stories in their backlog ordered by some informed priority. This PO is responsible for managing that backlog of effort and rationalizing each item in terms of its potential to impact e-commerce UX.

The PO is responsible for balancing what everyone wants done next against what everyone has also agreed to as being important right now.

A framework like this might be an appropriate solution for you, since efforts and priorities are constantly confronted with fair questions about delivery of value all along the way.

Answer 2

It would depend on the size and complexities of those websites and platforms, because you might find that the effort involved in setting something up only adds to the list of things that the client have to invest resources on in order to maintain and keep running (which they don't want to spend money on).

Assuming that the software development team uses something like JIRA or other software process/support management system, you can easily keep track of things like the number of issues raised relating to different parts of the system. This gives you the quantitative information required to work out priorities in terms of frequency. Then you need to obtain either qualitative or quantitative information on the impact of these bugs/defects/user issues, and by applying appropriate weight to the frequency and impact of different categories of issues you will have a curated list to look at and make decisions with.

I think these types of methods and strategies form part of the risk/impact assessment in the bigger picture of continuous improvement as a strategy/process, and it seems like there may be a business practice change required in order for the software development process to align more with the 'agile' software development process that can cope better with constant changes and less certain requirements.

Some of these changes might be at the organisational level (e.g. having a UX manager or lead that drives these initiatives), at the department or project level (e.g. having a product owner as suggested already) or at the team or individual level (e.g. having a process to review and update issues). Again there is no easy answer but I think given the cost and time incurred by the client when the systems go too long without being reviewed, they might be open to a range of options at each of these levels.