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.