Client/agency relationships at last week's Oxford Drupal User Group

Two days ago was June's Oxford Drupal User Group. In a similar manner to our March special event, we were very lucky to get two local speakers: this time round, our speakers were both the main points of contact at their respective organizations: leading Drupal projects themselves, but as part of that having to work with external suppliers, Drupal agencies brought in for their relevant expertise.

Carolyn Baker from Oxfam International spoke first, and discussed the expectation differences between client and agency. While not particularly technical, Carolyn is consistently nominated as the most Drupal-savvy in projects; as such, she has had to act as the conduit between internal stakeholders' requests and the advice and (occasionally) protestations from agencies.

She made it clear that agencies should remember that, all things being equal, clients don't care about how hard things are technically: they care about what the site visitor sees. However, she seemed to suggest there was scope for explanation and discussion: the point is, the discussion needs to lead by appreciating how everyone's understanding, experiences and goals differ. She suggested early, outside-of-Drupal prototyping as a way of a client rapidly coming up with clearer ideas of what was required, before technical steps were made. User testing was also useful for all parties, as early as possible to ensure the solutions made sense and were feasible. Explanation of Drupal concepts as part of training was also essential, if the client was likely to want to take the product away with them at the end: what's a node, again?

Neil Lawrence from Oxford City Council spoke next, and his team's recent relationship with an agency was radically different. They had previously run an intranet Drupal project in a semi-agile way, and wanted to run a new application build as close to agile as possible, with an opportunity to both be steered by, and learn from, a third party.

They brought a trusted agency in and it went remarkably well: Neil didn't have much bad to say about the relationship. Again, though, he did cite differences in expectations—of what was required, or by when, or in what form—as being the main difficulty: he saw it as a failing of his team, although I think any learning from something like that can always be on both sides. He cited "internal agile" as being useful for pivoting more flexibly than they used to do: being able to look critically at problems and their solutions rather than falliing prey to the temptation to over-cater for too many edge cases, and hence over-engineer the solutions.

Both speakers mentioned difficulties in getting any kind of agile process accepted; both work, of course, in large organizations which, while they might claim to embrace agile, are still a long way from permitting contracts and budgets to be flexible to an "agile extent" where external agencies are concerned. As a solution, both advocated splitting projects up: Carolyn suggested a separate(-ly costed) discovery phase, including that non-Drupal prototyping (but also advice and documentation provided in a Drupal context); Neil's project's success was in fact a Proof of Concept with a good explanation of limitations, caveats etc, so essentially a discovery phase for a potentially bigger project.

[Note: personally, I'm not convinced that splitting one waterfall up into several will in itself make a methodology approach agile. But not every project should be expected to fight that battle, and it's still a good way to build up trust in a sceptical organization: both speakers implied that, with the right agency involved, certain bureaucratic aspects could be finessed. Also, deliverables from a successfully completed subproject have their use in themslves, decoupling parts of the project and mitigating against a combination of factors you can get from agile-as-lipservice e.g. product-owner absence or overstretch, just-in-time documentation not being timely enough, timescales drifting etc.]

It was fascinating to hear honest discussion from clients who find themselves broadly happy with Drupal, but also willing to be critical of it publicly, and I'd love to hear more of it at Drupal conferences and camps in place of preaching to the choir. If I were to raise one niggle it was that, if anything, Carolyn and Neil were almost too happy with, or perhaps close to, Drupal, and hence the perfect clients! I've found most clients much less well versed in, or indeed amicable towards, the technologies they're using; it would be great to hear how they've seen client/agency roles in the past, and what (sometimes, if anything) could be done to improve them in the future.

But that's a minor niggle, and it was still great to be able to shift the tone of the discussion from proposing or bashing out technical solutions to managing, maintaining and nurturing team/supplier relationships: after all, however much PHP you can write, the latter is how projects ultimately ship.

Comments

Hi J-P.  Didn't think I'd ever be accused of being a perfect client! That may because in my role I do what I can to keep the non-relevant discussions away from the agency, and we have those debates/battles internally.  

We've certainly had our 'fallen out of love' moments with Drupal (endless updates, excessive markup etc) but I think its advantage for us is that there is normally always a way to do what you want, and a glut of Drupal expertise around to help get you there.

I still hold with my view that the agencies we've used, and the attitude they adopt when helping us (so different to the multi-national 'monster' software companies we ar forced to use for some of our applications) means it's a breath of fresh air using them.

 

 

 

I think in terms of what an agency actually needs to get moving, you and Carolyn both were, because you had motivations to dig into the subjects—Drupal, agile methodologies, PM generally—that defined your projects. I'm not saying every client should want to get so involved, but doing so has the effect of removing the kind of client/agency frictions that (in the role of a one-person agency) I would want to avoid.

That doesn't mean you've removed all frictions altogether, though: that then also depends on your choice of agency!

Great blog, J-P, was looking around for some notes on this as I couldn't make it (rather annoyingly).

The idea of differing expectations is one that seems to come up a lot and can be hard to find a simple solution to. However, much you discuss expectations and deliverables upfront, these can shift very quickly, almost subconsciously as the project progresses... So perhaps one way to manage this better is to review and revise those early discussions and documents throughout the project or to build in a way of discussing this more overtly during the demo and review. These can often end up being more demo and less review due to time constraints and a tendency to look at the details (testing user stories) and not the bigger picture (project plan).

Yes, I don't know if there's a one-size-fits-all solution, because there are so many ways in which assumptions can diverge: you can literally be talking about the same thing, with the same words, but meaning (and thus assuming) different things. I've heard mention of setting up "project glossaries" and things like that, but I think "ask the stupid questions" is as good advice as anything!