A leading Telecommunication company had traditional has a culture and organisation structure that is matrixed. While being hard to work in an agile way. Communication across the business can be slow and it can take weeks if not months to get an agreement on any action. As a result of the deadline of the end of December to lunch a new proposition into the market that works off Microsoft Teams to provide organisations with unique user numbers for employees to connect with calls off line.
As our prototypes were validated and refined, we turned to the task of implementing our solutions. At this point, the stakeholders that had been involved since the beginning were ready to take action!
Working with the design and development team across the business helped ensure that Operator Connect was delivered on time. By prioritising the most important features while designing with customer evidence in mind.
We were able to work with the design team and understand how to create value around an already existing team. While influencing other parts of the business. We were able to introduce a more holistic design centred approach to this part of the business need templates to create a clear framework for future projects.
How I felt
I was involved in this service design project when the client ahead had a solution in mind. This was very dangerous as they wanted to stop and validate any existing problems with their existing clients. Finding ways to prove that clients would use the service and better understand their existing processes to solve their challenges. Having too much consensus was a blocker as people across the business did not want to action anything and rather have meetings with no clear outcomes.
What this inspired me
Finding people in the business that was willing to break the rules and do things differently to understand what the clients really wanted. Rapidly testing ideas and features from the service. When presenting this evidence to stakeholders that did not believe in speaking to users before building an idea
9 comments
Daniele Catalanotto
Jan 22, 2022
Hey Daniel :) Thanks for sharing this story ❤️!
I see a few different ideas I'd love to explore with you. So here are a few questions to start this co-creation round 🚀:
How did you break the cycle of "too much consensus that leads to more meetings with no clear outcomes"?
How did you find the people who were willing to "break the rules and do things differently"?
What did you present that convinced the stakeholders that "Wow indeed it makes sense to speak with customers before building the idea"?
I'm sure that behind these answers we can find some very practical and down to earth tips that could help other people who slowly discover what service design can bring :)
In the next weeks, I'll explore each one of these ideas in more detail. Below is already a draft about one of those inspired by your experience mixed with some of mine. Let me know Daniel what you think, I'm curious to read your take 🤗
A Service Design principle about the danger of words when you are new in an organisation
Be careful of the history of words.
I'm presenting a project to a board of directors. I show a new slide, and there is the word "agile" shown next to a diagram that shows how we'll try to work on this project. One of the members answers we a smile something like that:
Oh, agile... we've been there already...
Hmmm... Okay, so I continue. It's only after the presentation and when I'm back with my colleagues that a colleague contextualises this reaction for me:
The last project that used an agile way of working was really difficult for everyone...
In that organisation, because of past experiences, the word "agile" has a bad reputation. Even if most people would agree with the content of the word, its internal history generates strong negative emotions. Now my project has the bad smell of the history of another project I didn't even know existed...
A good friend often uses a trick we can steal to avoid such situations. At the start of a collaboration with a business with many shops, he might ask, for example:
How do you call these shops internally? Branches? Shops? Independent locations?
He makes sure that he uses the insider lingo and does not break any feelings.
Another thing I can do next time is to run important presentations with internal members first and then ask them:
Any word in here that has a bad reputation within the organisation?
If yes, I can either use a synonym or contextualise what I mean when I use this term to avoid my presentations getting "stinky" because of how others used that word in the past.
So remember that every term has a history in a company. Before you start to communicate internally, ask what words have a good press and which don't.
A big thank you to Daniel Tuitt, who inspired this principle by sharing a similar experience he has gone through in his own practice in the UK.
Daniele Catalanotto
Mar 16, 2022
Here is the second condensed draft of the Service Design Principle about how to use corporate lingo to show respect
Be careful of the history of words
I show a slide with the word "agile" next to a diagram of our process during a presentation. One of the viewers answers with a smile something like that:
“Oh, agile... we've been there already...”
After the presentation, a colleague contextualises this reaction for me:
“The last project that used an agile way of working was really difficult for everyone...”
Because of past experiences, the word “agile” has a bad reputation in this organisation. Most people would agree with the idea behind the term. But, its internal history creates strong negative emotions. Now the project I'm working on has the bad smell of the history of another project.
A good friend uses a trick we can steal to avoid such situations.
At the start of a collaboration with a business, he asks what the internal lingo is.
He might ask, for example:
"How do you call your shops internally? Branches? Shops? Independent locations?"
Following the same idea, before I do an important presentation, I can ask insiders:
“Any word in here that has a bad reputation within the organisation?”
If yes, I can use a synonym or contextualise what I mean when I use this term.
Remember that every term has a history in a company. So stop before you communicate internally. Verify the history of critical words. And use insider language to show respect.
A big thank you to Daniel Tuitt, who inspired this principle by sharing a similar experience he has gone through in his own practice in the UK.
Little side notes
This second draft has been reduced by 15% compared to the first version
What parts of it do you think could I remove to make the idea even stickier?
Thanks Deirdre for the feedback. The original story of Daniel won’t be available in the final book only the many times edited principle I wrote based on it 😉
But I’ll add links for each principle to see the full community conversations with every draft so that people can see the original Inspiration and how the text revolved
Daniele Catalanotto
Oct 21, 2022
The third draft of this Service Design Principle
I show a slide with our process. You can read the word “agile” next to it. One of the viewers comments with a smile:
“Oh, agile... we’ve been there already...”
After the presentation, a colleague contextualises this reaction for me:
“The last agile project was a big fail.”
Because of past experiences, the word “agile” has a bad reputation in this organisation. Most people agree with the ideas behind the term. But, its internal history creates strong negative emotions. Now the project I’m working on has the bad smell of another project.
How can we avoid that? As a friend does, ask at the start of a collaboration what the internal lingo is. For example:
“How do you call your shops internally? Branches? Shops? Independent locations?”
Or before you do a presentation, ask insiders:
“Any word in here that would block people from reading?”
If yes, use a synonym or contextualise what you mean by using this term.
So let me ask you.
When and with whom does it make sense to verify the history of words in your communication?
Footnotes
A big thank you to Daniel Tuitt, who inspired this principle by sharing a similar experience he has gone through in his own practice in the UK.
Daniele’s notes
This is the third draft of this principle.
I’ve reduced the length of this principle by 11% compared to its previous draft.
I've added a question to the conclusion to help the reader turn this principle into action.
