The Digital Language of Systems

SUMMARY KEYWORDS

project, project manager, language, understand, meeting, system, dutch, talk, subjects, change, questions, organisation, zoomed, decision, agenda, stakeholders, episode, acronym, software, points

00:00

This is automation for the nation. My name is Richard Bown and this is episode four. When I came up with a name for this podcast, I already started writing a book of the same name. The book is going to be about levelling up for automation and software technology. I want everybody to automate and to make it accessible. over successive weeks, I've zoomed out from automation of tasks to business systems themselves, then zoomed out further to the organisational view of systems and touched on Conway's Law, and how our organisation imposes limits on how we work with systems. This week, I'm going to go slightly sideways and talk about how system change comes about and how none of our conversations matter, unless we can be understood. So this week is about digital language, the language we use to describe the technology and the words we use to describe how technology change occurs. Over the last few months, I've been working with clients, where the use of language has been really important. When we work in the digital domain with information systems and software systems, we can often hear language that we don't understand. Technology moves quickly. New Words are getting invented all the time. The domain is littered with jargon and shortcuts, acronyms, portmanteau words contractions, specialised vocabulary. If I'm a user of a potential new system, how can I learn about that system? If it is described in words that I don't understand? If I'm a project manager, can I take responsibility for delivering something which I don't fully technically understand? And if so, how? Even the name given to the process that delivers a new system might be confusing. It could be a project, a change, an implementation, a change process, a size that stands for software as a service, a database, a cloud migration? What are these things? Are there significant differences between them that I should worry about? By the end of this episode, I hope you'll have more confidence and be able to ask questions no matter what your role in a change projects also share some resources that can help with digital language. Speaking digital language can be as daunting as speaking a foreign language. Sometimes when I speak Dutch, I recognise the words and think they mean one thing but in reality, they mean another. However, because of my pride getting in the way, I don't stop to correct myself, I just go with it and hope no one notices. This could also have something to do with my Britishness, you know that the British aren't very good at making themselves understood. Sometimes we talk around subjects and over subjects rather than going to the heart of them. However, I've lived in the Netherlands for 15 years. And sometimes I've been told that I'm more direct than the Dutch, the Dutch are famous for being direct, the Dutch will get to the point very quickly in a meeting, they will want to know why they are there, and what it's about. And only then once everything is in order, will they then relax and commit to it. As an aside, it's important to say that change sometimes brings commitment. When we see something new, we want to understand it, we want to be a part of it to have our voices heard. It's exciting. Going back to race, the Dutch, like the British, like any nation will often not kick up a fuss once something is agreed in principle, once something is underway such as a project, then we tend to lose interest. And perhaps we don't listen as well as we could. This is human nature, we get very excited about the prospect of what to change and do for our organisation. But we don't want to get bogged down in the details. Imagine you're the project manager for a new CRM system, you can talk about all the business benefits that it might bring, or perhaps the technical benefits, then ask yourself as you look around the room or the zoom, does your audience really understand what this means? Or are they too polite or too proud to admit that they have no idea what you're talking about? Do you know what you're talking about? Are you just winging it? In a recent engagement, I had to make it extremely clear that I needed something to change, I needed a commitment or a decision. To enable this, I needed to change my language and change my rhythm. I will choose the time when I'm going to deliver difficult news. But I will also signal my intentions to make sure it doesn't come as a complete surprise. I will signal these intentions by bringing it up in person or indirect email and probably at least a day or two ahead of the time I need the decision by when we have the meeting, I will set out a clear agenda of what I hope we will gain from it, but also leave space for any other business. And for the other attendees to add anything into the agenda. Just because I needed a decision making doesn't mean they shouldn't be an opportunity on all sides for some feedback. Following the meeting, I'll send out an email summary of what was discussed so that we're all clear on the outcomes. If you need a decision to be made, or you need someone to do something, and you feel that you need to agree this as a group that always have a clear agenda and keep the meeting to the point. This works well for important conversations where a clear decision has to be made along the lines of do we continue with this project? Do we sack the vendor? Do we go ahead with a new phase or postpone? If you want a decision, make sure that you clearly state that

05:00

Sometimes you want to have more sociable conversations about project progress, but again, have a theme limits perhaps the scope of the discussion and moderate it. If people lose interest because they don't understand what's going on, then the meeting might have been counterproductive. Change projects can of course be technically complex, and the language that goes with them can be confusing. You can use a meeting like this as an opportunity to discuss some of the points of language, or some of the points of complexity which people are not clear on. To understand what's going on. Now, it's often important to understand what's come before the context gives us a common place of reference for all the project participants are commonly heard name for a participant in a project is a stakeholder. A stakeholder is someone who has an interest in the project being a success, be their user, a project manager, a developer, a sponsor, a CEO, all of these could be stakeholders, and they have different views on what makes the project successful. So what is your role in this project? Are you the project manager? Are you the business sponsor? Are you simply interested in the outcome? All of these viewpoints should be catered for by the process that the project undertakes. Don't ever assume that you should hide information from anyone who is interested in the project. Anyone who has an interest should be included. And the language you use is therefore important to gain the greatest reach. By keeping language simple and straightforward and buzzword and acronym free, you can be sure to engage with the most people. Okay, so you might ask, but what if I get awkward questions which I can't answer, then you can just say, Well, I don't know. But I can find out if you're the project manager. And your job is to be the spider in the web of the project, and to be able to connect people to each other. If you can do that, and learn something yourself at the same time. You make yourself smarter and you help the project out. You may not know the technical answer to everything, but you should be able to find someone who does. Another question. What if I get inundated with questions and I don't have the time to devote to my other duties? When should I stop asking for feedback? Having too many questions could be a sign that you've not prepared well enough, or you've not communicated those ideas clearly enough, review the materials you prepared as part of the project and see if you can add some more detail, tried to group the questions together in areas to give you clues as to where the knowledge gaps lie. Have a session with a project team to drive out more questions and to see if anyone else is confused. Use this as an opportunity to learn more about the requirements or expectations for the project. One more question. Why should I spend so much time working with stakeholders, all stakeholders are crucial to project success. The more time you spend with them, informing them getting them on your side and on the project side, the less effort you will have to do to convince them of the importance of the project. Remember that a project doesn't stop. The system that is delivered should keep your business running for years to come, you will all have to live with that system and the choices you make as a group. So spend the time now to ensure that everyone is as comfortable as possible with the project and therefore avoid surprises later. To help you out some more. I've written a short guide to digital language used in modern software implementation projects, which should give you a head start. I'll link the guide in the show notes. And I'll be sure to revisit the subject in a future episode as I feel we're only just scratching the surface. I've also made some notes about how to run more effective project meetings. I feel there's something to drill into there in the future as well. For the moment, I'll summarise a few points for you to take away. technical changes complex and the language can be confusing. Remember this in all of your communications. Keep the language used in the project documentation as simple and as buzzword and acronym free as possible. Communicate clearly and regularly. Ensure that meetings are regular but useful. Always publish an agenda and just cancel a meeting. If you have nothing to talk about. Those participants will appreciate having some time back in their schedule, and they will reach out to you if they need to hear anything in detail about the project. Build an atmosphere of trust, from users, to developers, to testers to administrators to project board members. escalate any issues immediately. But politely ask for clarification if you're not sure, it might be communication problems rather than an issue. But make sure you understand what the difference might be. As a project manager, you're responsible for the project. But that doesn't mean that you're on your own. Get everyone on the project team on your side. I hope you found today's episode helpful. I've really enjoyed putting it together. And I'm looking forward to discussing some of the topics raised in a webinar in the near future. If you'd like to stay informed about the podcast or any of the subjects raised, then feel free to jump onto my mailing list. I'll link that in the show notes as well. You can also reach out to me by email or get in touch via Twitter or LinkedIn. Thanks for joining me on automation for the nation. For now, this is Richard Bown saying Goodbye and good luck and until next time