Communication, Flexibility and Trust — Integrating with client development teams
Author — Liz Hnat — Senior Project Manager
When working with external clients, it’s common for agencies to provide services which integrate with a client’s existing development team.
My first full project after joining Hive in 2015 was exactly that format and it’s a model that we’ve continued to embrace and enjoy with clients such as Innovate UK, Home Office Digital and Split the Bills.
For that first project with Park Group, Hive IT were asked to provide User Experience testing, Consultancy and Development of templates that would be integrated by the client’s own development team.
I’d worked with all the Hive staff before at previous digital companies where we were bound by corporate rules and practices that had shaped our way of working. But rather than continue with the same dogma, the Hive IT team have created their own way of working, and this was an exciting chance for me as Project Manager (PM) to learn and support that.
With the previous restrictions removed, it was immediately evident just how different their approach to collaboration with external off-site development teams was. As we’ve grown and continued with that model, we’ve become better at complementing existing teams and providing real expertise to lead and handover maintenance of systems.
So, here are my top three bits of advice when working in a lean environment with external development teams.
- Avoid the classic “Bottleneck” — Don’t let there be a single contact point
In my experience prior to joining Hive IT, the PM would usually be the initial contact for client project relations and technical queries (established SCRUM projects aside), so in my case it meant I needed to have a good level of technical understanding of a project.
Whilst I still think it’s essential to strive for that understanding, Hive IT encourage the client to have direct contact with the technical team (via phone, Skype or another convenient method).
This allows us to slice through an unnecessary layer (me as PM) and get issues resolved much faster. By removing the requirement for the client to contact the project manager for technical enquiries, we were eliminating waste and reducing the “Chinese whispers” element of project communication.
Agile preaches this approach from the ground up. So why did we ever work in any other way? I guess being the first line of contact had been an effort to ‘maintain control’ (like the PRINCE2 methodology). But here’s the key: that should be at my cost as a PM, not at a cost to the product, timescales or the client.
Any challenges that arise through the Project Manager not being involved in every conversation are solved simply with a direct catch up with the team. If there’s an area where my involvement is needed, the team should feel comfortable asking me, and I can gather the technical details I need to help reach a resolution. That means I’m free to concentrate more on the project as a whole and as an enabler of the team.
2) Be Mobile! — Don’t hold back from getting on the Train/Car/Bus/Pavement/Bicycle
For the Hive IT team, there are days on projects that really needed to be spent side by side with the client’s technical team — be it to guide and advise them or help problem solve the implementation of the work we are providing. In fact, we’ve become adept at working onsite with clients because their offices are usually the place where the key stakeholders and experts really are, and for a successful project they’re the people you need access to.
In that first project for Park Group, where we worked mainly offsite, we didn’t have pre-scheduled onsite days: they naturally evolved and I was amazed at how willing the Hive team were to get out there. They don’t want to sit in the office all day every day: they want to be integrated for the good of the product. It paid dividends in morale, made implementation easier and, although unmeasured, I’m confident the overall quality of the product was improved.
At times, there really is no substitute for face-to-face interaction with a client and we’re certainly a team who are willing to travel — although we are thankful for our central location in Sheffield! While we’re lucky to have a solid base of local clients who we can jog on down the road to visit, we equally have clients from Scotland to Swindon.
Finally, I wonder if this willingness to travel is in part because of how invested the team feel in the company. Every member of Hive IT wants to be part of its growth, we want to be delivering high-quality projects that gain recognition. These aren’t faceless projects for clients that the team rarely meet; every one of us is working to build and maintain good relationships for a solid future.
3) Trust goes a long way — DO recognise the good work of your counterpart team
As technical specialists working with other developers and designers, there’s always the opportunity to see issues in someone else’s work. After all, that’s why pair programming is popular! But rather than concentrate on negatives, our team tends to recognise and verbalise the efforts of their counterpart teams and this is usually returned in kind.
This positive approach fosters a ‘no fear’ culture on projects, and the whole team (Hive and Client) feel confident in raising problems or issues that we may notice with the client’s deliverables and vice versa. The client know we respect the work they’re doing because we tell them! This recognition builds trust on both sides of the aisle.
In Summary…
When working with client developer teams, make sure that you get to know your entire team, meaning everyone involved in the project regardless of who they work for. Pick up the phone, jump on the train, go have a pint with them — whatever it takes to make you and them a cohesive team so that the responsibility for delivery of the overall project is shared.
Collaboration, talking, sharing both the good and the bad: these simple steps are easily forgotten, but make all the difference to a combined-resource project. At Hive, I think this is one of our core strengths, and it’s why we like to talk about our clients as our ‘partners’ or creating ‘partnerships’ because it’s something that we try hard to achieve.
— — — — — — — — — — — — -
