Teaching fishing

Most people will be familiar with the saying “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime”. In the World of web development this equates to helping organisations to build their own web projects rather than doing it for them.

Photo of Steve Cowie
Tue, 2013-11-05 16:50By scowie

Looking back over the last year's work, we've noticed that we're increasingly working on projects where we're supporting internal teams. In some cases this has been required for experienced teams that are getting to grips with Drupal for the first time, and in others it has simply been to supplement an existing team.

This feels like a change from the fashion of outsourcing and reducing internal teams. No doubt money was one driver for this, with an immediate saving gain from reducing in-house staff. However, there's also plenty of examples of where outsourcing has failed in terms of quality, and ultimately in terms of costs. Certainly we've done numerous projects stepping in to rescue disastrous Drupal implementations.

From the client perspective we identify a number of benefits of running an internal team and supplementing it with staff from an external agency. One is that you reduce the risk of being locked into a relationship where you depend totally on your external supplier. Admittedly, you depend on your own staff, but hopefully you have more control over that relationship.

Combining in-house resource with agency support offers the potential of achieving the optimum financial balance between salaries and project costs; with professional agencies charging several hundred pounds per day for each resource, you don't want to be hiring them for months on end.

Another benefit is that you can adjust the intensity of your development work so when things are just ticking along you use your own team but when you need to either ramp up for a new project, or just have an intensive blast at an existing one, you can pull in extra help.

Related to this balance between routine and intensive activity is the level of expertise you actually need on a day-to-day basis. A considerable percentage of many Drupal projects is what we'd classify as "site building", and much of this work can be achieved with mid-weight developers. It makes good financial sense to match up the complexity of the work to the staff expertise. You'll pay more for the custom development being done by your agency partner, but you'll hopefully minimise their input.

So much for the client benefits - how does it work from our perspective as a supplier? Actually, it has a surprising number of benefits. The cost savings for the client translate into affordability for us. Having a team of experts means we have to charge a substantial day rate, so we get why a client wants to keep the number of days to a minimum. Provided the work can be achieved, everyone wins because we get our day rate and the client gets the work done effectively.

Another aspect of working with clients where there's a limit on our input is that we work with more clients. We've increased our client base by over 30% in the last year so we have to find more work, but we're much less vulnerable to losing a major client. Anyway, we find that having an affordable relationship with clients makes for more long-term business relationships.

Working with an in-house team often makes it easier to run projects using Agile methodologies. Two fundamental aspects of Agile are that the project ownership stays with the client in the shape of the product owner, and projects get estimated or sized in terms of capacity. Both of these come more easily where the client has his own staff engaged with a project, and where there's a de facto recognition in having staff that people cost money, that doesn't correlate automatically with output. By contrast, where a client is commissioning us to do the whole thing, the focus shifts towards a fixed-price specification. Another feature of Agile is it promotes the idea of development taking place at a constant velocity and that's much more plausible where there's an in-house team to provide continuity.

There are also some specific benefits for the members of our team who are working with the in-house team. Sometimes the external developer is working on the more complex features, and all developers like to solve problems. On the other hand, sometimes what's needed is a very close interaction with the in-house developers, mentoring and training. Being able to introduce people to professional techniques such as sophisticated version control or fully integrated testing is really rewarding - not a great surprise given that so many Drupal developers are attracted by the community sharing aspect of Drupal. Also, several members of our team have done training in the past so welcome the chance to do focused training. On some projects, mentoring requires members of our team to be embedded onsite with the client's team, and that both makes a change from working remotely and also provides opportunities to rethink our processes.

Some mutual benefits for both client and agency are that having a combined team encourages clarity about what needs to be done and what the resource implications are. This also encourages clarity and transparency about costing because the client needs to make informed decisions about who should do what.

All in all, then, we think supporting and mentoring in-house teams is likely to grow because enterprise Drupal implementations need regular attention and that is often best left to in-house developers familiar with the day to day requirements of their organisation. However, those developers will need periodic support from specialist agencies to handle the edge cases, or just intensive phases of development.