Priority Without Consequence in Projects

Posted on by Mark Myers Leave a comment

When you are running any form of migration, integration, upgrade, or indeed any project that touches a live business process, there will always be a battle between BAU 1 and the project. This battle can be over resources, vendor time, budget, or even something as core as system uptime. Inevitably, there will be a debate about who gets their stuff first.

The default position is usually that BAU takes precedence. A production issue always wins against everything else. However, if you are managing either BAU or the project, you must remember that every priority comes with a consequence. This is the part that often gets overlooked.

For example, a BAU team might say, “We’ve got a production issue, we need the developers to drop everything,” or “We need to cancel the weekend outage because we have to work through it.” It makes no difference what the specific request is. The key point is that even when one side’s priority is accepted, it is often assumed by that side that there will be no consequence or no cost for exercising that priority.

When this happens, you will often need to have the awkward but necessary conversation: “Yes, we’ll all pile into the BAU problem, but this will have the following knock-on effects.” I would strongly advise anyone running projects to be crystal clear on this at the time. People have very short memories about these things, and later you will hear questions such as “Why is your project late?” or “Why has BAU been impacted?” Without a proper paper trail, it becomes very hard to justify the outcome.

So when you have a situation where one side’s work must take priority, acknowledge it, accept it, and then record the consequence. Provide a bill, whether that is measured in lost time, extra budget, or a revised delivery date. It is the only way to maintain fairness and transparency between BAU and project work.

  1. Business as usual [↩]

Finding an Alternative to Play.ht for Your Text-to-Speech

Posted on by Mark Myers Leave a comment

Well, it turns out that Play.ht has gone bankrupt.

I hadn’t seen any news about it, so when I came to do my latest blog post, I found the site was down with no indication of support, no notice, and no email. A bit disappointing, but there you go. The internet gives, and the internet takes away.

That still left me with a problem. I need a decent text-to-speech converter. I use one both to ensure all my blog posts have an audio version and because, as someone who is badly dyslexic, I find it the best way of proofreading my work. Listening to my posts read aloud helps me spot those moments when I think, What on earth is that? and correct my gibbering.

So, I had a good trawl around with a specific set of requirements. What I wanted was something where I could paste my blog text, have it follow punctuation properly, let me listen and review easily, work quickly, and not cost a fortune.

After a fair bit of digging (and trying a few others I won’t name and shame), I ended up with Async.ai, which met all my needs. It has an easy login, a simple text-to-speech interface with a large input box, sensible formatting, and a solid range of voices and styles to choose from. It generates speech far faster than Play.ht ever did, and you can download the output as a WAV file. I then convert that to MP3 and upload it as a media file on my blog.

I have no interest in having the audio hosted elsewhere. That lesson has already been learnt with Play.ht: don’t trust anything other than your own website.

So far, I’ve found that Async.ai works well. The voices sound good and natural, and it feels very similar to what I was using before. I’ve subscribed, and it’s much much cheaper than Play.ht or many of the other options, with a simple pay-per-hour model that suits me perfectly.

My only minor irritation is that when you click Generate and Play, you can’t skip around easily. Every time you fix an error or tweak some grammar, you have to listen to the whole post again. But honestly, that’s a small price to pay for such a straightforward, reliable setup.

If you’re moving away from Play.ht, or just looking for something new to convert long-form text into speech, I’d recommend giving Async.ai a try.

Integration Support Challenges in Production

Posted on by Mark Myers Leave a comment

Now this is an incredibly dull subject, but one that many companies continue to struggle with when it comes to integrations.

All integrations, by their very nature, are quite brittle processes.

They often involve converting data from one format to another, and because they cross multiple systems and ownership boundaries, they can be difficult to pin down when things go wrong.

Many of the endpoint systems that are integrated into have very restrictive support models, and security rules often mean that each team can see only a limited part of the picture.

So, once the project work has been completed and everything is technically “working,” as it should, then the real challenge begins, which is how do you actually support it in the long term?

Of course there will be issues around monitoring, workflow, ownership, and escalation paths, but ultimately it comes down to one thing:

Responsibility.

People rarely want to follow a formal process that leads to them having to pay for it to be fixed. Instead, you’ll hear, “Oh, X is broken, call Y.”

It’s human nature, and integrations tend to encourage this kind of finger-pointing.

“It’s your bit that’s broken, not mine.”

The best tip I’ve found for handling this is to ask a very simple question…

Is this a new piece of code, a new application, or a new machine? If so, who are you paying to look after it?

That’s the crux of the matter. If there’s no budget, then most departments will quite rightly say, “That’s not our responsibility,” unless it’s a simple configuration change or something that clearly falls within their existing remit.

But integrations rarely work like that.

They almost always introduce new code, new objects, or new dependencies.

So, the next time you’re trying to work out who owns a piece of integration work, just follow the money.

Whoever is being paid to maintain it is responsible for it. If no one is, then you haven’t yet found an owner. And if someone is willing to take the funding or resources, then they are, by definition, the right people to make responsible.

It’s a simple question, but it saves a lot of pain.

Baseline Thinking: The real difference between corporations, massive organisations and the rest of us.

Posted on by Mark Myers Leave a comment

This is an insight that struck me recently, though it’s hardly new. In fact, anyone working in marketing or public relations will tell you the same: people, as individuals, are intelligent. People in groups, however, can behave in very odd ways.

So how does this play out in the corporate world? It often comes down to the gap between how small groups of experts expect people to react and how large organisations know people actually react.

Take something as simple as installing software. If you give a set of instructions to technical experts or developers, they’ll follow them making intuitive choices along the way. Rarely will anything need spelling out. The target audience will just handle it.

Now compare that with giving the same instructions to the general public. Suddenly you need to specify every click, every option, every screen. What feels like minutiae to an expert is essential detail to ensure success for the rest of humanity.

Now you have this understanding, you can explain it to your experts as they will often wonder why corporate infrastructure demands such exhaustive, step-by-step detail. To the expert, it feels pedantic, even pernickety and pointless. But for a corporate support team, responsible for thousands of people with widely varying levels of knowledge it is just dealing with a very broad baseline of humanity.

Because in that large, mixed pool of users, someone will get it wrong. Someone will click the wrong thing, misread the obvious, or inadvertently cause chaos. And if support hasn’t built in the safeguards, they’re the ones left cleaning up the mess.

So next time you find yourself rolling your eyes at “silly” questions from corporate support, remember: they’re not being awkward. They’re working to a broader baseline of understanding, one designed to prevent the inevitable finger-pointing blame game from happening

Actually Implementing AI into Existing Systems

Posted on by Mark Myers Leave a comment

Now that we have all got over the initial flurry of being astounded by AI chatbots and their very human way of handling conversations, a lot of clients and companies are moving on to the serious, practical side of implementation. Everyone seems to want to fit AI into everything, and once you reach this stage, the excitement quickly gives way to the realisation that most of the challenges you face in getting it to work are the same old ones we have always faced with integration and software adoption.

To be honest, I personally find chatbots, while amazing, don’t quite beat the real thing. If you have ever worked in a company with helpful colleagues, it is impressive that a computer can do that job, but the function itself is not new. What is amazing is doing it at scale. Instead of asking ‘Janice in Finance’, you ask an AI, and an AI can answer thousands of people at once.

And here is where we hit the same old problem; even ‘Janice in Finance’ isn’t a divine miracle, so how does she do what she does, and how can we get AI to do the same?

The first issue is data. Have we given the AI all the data it needs? Have we given it access to live sources, or are we expecting miracles from a one-time data load? Have we structured the data in a way that makes sense? Just dumping it into a database without context or rules will not work. AI needs to know how information connects in order to make useful deductions. and while there are incredible tools that can help with this, when it comes to making assumptions, particularly financial or legal ones, the wrong connections or lack of context can quickly become very dangerous. This has been a problem since long before AI.

The second issue is workflow. Once you have gone past the novelty of “oh, this is a chatbot”, if it does not fit into the user’s normal workflow, they will not use it. Make sure that any new AI features work within existing processes. This not only helps adoption and avoids unsettling users, but failing to do so actually takes away some of AI’s advantages. For example, if you are assessing whether an insurance claim is potentially fraudulent, that used to be done using a set of complex but static rules which produced a percentage likelihood. AI can now perform that calculation far more accurately, but you do not need to change the interface at all. It simply improves what the user already sees, which is exactly how good AI should feel: an invisible improvement that makes the job easier without disrupting needlessly.

The third issue is adoption. Forcing new features onto people drives them mad, even if those features are shiny and fashionable. It makes users nervous, and they start to see change as a threat. There are thousands of books and experts on adoption because it is a very old game. My least favourite part is when senior leaders believe the technology will replace staff and start talking directly to business teams about “efficiency gains”. This immediately puts people on edge. AI already carries an overtone of job replacement, so pushing it from the top without the right tone can do real harm. It needs to feel like an aid, not a threat.

Finally, there is the way we introduce AI. Making a big song and dance about any new technology might be great for publicity, but it rarely impresses the people that do the work day to day. Pitching AI as something that makes people’s lives easier and helps them do their jobs better works far more effectively. It should be seen as a tool that helps teams perform better and, ideally, be rewarded for it. Declaring “AI is here, the world will never be the same” is exactly how you generate resistance and backlash. Features will be viewed as threats rather than improvements, and that helps no one.

In short, make sure any AI you introduce actually adds value rather than simply being “the new hotness”. Even though AI is a fundamentally transformative technology, from your users’ and business teams’ point of view it is still just another software adoption process. Use all the lessons you have learned over the years to make it as seamless as possible.