Everyone who works at a consultancy or agency knows that with every new project comes a new set of challenges and obstacles. Part of that is the new relationships that you will need to build with the client and specifically those people who are invested in producing something excellent.
In order to put the following in context, a little bit about me. I joined Amido in 2015 as a Business Analyst and expanded my skillset over the following year in order to include UX Research and UI Design capabilities. With my current client, I also have the role of Scrum Master / Project Manager for a small team of 4 consultants.
Before I worked at Amido, my experience of working with agencies was that they often took a ‘throw it over the wall’ approach, wherein the development work was done and then ‘thrown over’ to the client in order to get sign off of a particular feature or requirement. This approach was usually problematic right from the start – it was a clear indicator of someone saying “I’ve done my part and I’m washing my hands of it now” – not great.
At Amido we have never worked that way and that was emphasised with my most recent client – a large media and entertainment brand in the UK. We have worked on a number of projects together, and if I said we had our ‘ways of working’ nailed from day one, I’d clearly be lying. For sure it has been a process of trial and adjustment to ensure that the way we work on each project is most appropriate for the team members involved and the stakeholders whom we delivered to.
Everyone has the freedom to challenge ideas. Regardless of their role.
Work as one project team. Never a divided agency and client.
I could go on for hours about how communication is the key to success (not just in software development projects, but in life). I have experienced countless situations where problems, issues and frustrations all stem from a piece of bad or non-existent communication. Generally, people respond badly to not being in the loop – understandably, because it immediately puts them on the back foot and hinders them in onward communications of their own.
It seems kind of obvious, but it’s also worth highlighting. Often as individuals we get ‘too close’ to something – as a UI designer I’m fully aware that I may spend so much time on a piece of detail that I miss some part of the overall user flow…. so, I always ask for peer reviews. In a similar vein I encourage other team members to do this with each other on the fly. Are you a Java developer with a question about a UI element? Ask away! The aim isn’t always to solve a problem, but to help everyone to think about their approaches by answering the questions.
So now we’re onto the main thrust of this piece, teamwork. Working as a mixed team of consultants and clients, it can be hard to work as a cohesive unit. This is especially the case when different people from different employers have differing priorities (and people to answer to) even when everyone is working towards the same project goal.
My approach has always been to primarily lean towards empathy. To understand the pressure that everyone is under means that I can assess and adjust how I work and what I can do in order to make the lives of those other people easier. The caveat of this is that I fully ‘get’ that this is easier with some roles than others. In my hybrid role, it is a little easier to switch context on the fly… not so much for other team members.
Regardless of this, we work together. We take on internal processes from the client but also advise on alternate approaches as we feel is appropriate. Between us we come up with project processes and methods that ultimately help us to deliver the project goal as a team. If an individual has an issue with the way we are working through the project and wants a change, the door is always open for that. As most teams do, we hold Sprint Retrospectives (if Agile software development is new to you, then Google it – it’s amazing!) where we can talk about the last 2 weeks work but I also make sure that the team has opportunities to talk about how we write user stories, how they move across the sprint board and when we consider something to be ‘done’ (seriously, Google ‘Agile Software Development’).
Another point to mention is that working as one cohesive team is just, well… nicer. With our current client, we are so well integrated that they treat all of the Amido consultants as ‘part of the family’. They invite us to social events, they celebrate our birthdays with us and have genuinely become friends as well as colleagues.
Understand the goals and pressures of everyone in the team – especially those of the client.
Ask opinion of everyone. How would they like to work? What will make their life easier? What can we do better?
Involve the whole team in key decisions.
Encourage clients to visit you in your office – introduce them to your colleagues who work for different clients.
Ensure you talk about ‘Project Success’ and not what was done just by the consultancy.
Celebrate birthdays together. Buy a cake!