niksilver.com

I was by turns initially horrified and puzzled when I read Ryan Sholin’s piece on “How to manage technology decisions in 5 easy steps”. Horrified because they seemed at odds with my own experiences of what works and what doesn’t, and then puzzled because Ryan is someone with a great deal of experience in digital media, so I couldn’t understand why he was writing these things. Eventually they made sense, but only when I realised his tips were for entrants of the Knight News Challenge (KNC), which is a very specific competition with very specific demands from an audience being mostly of a particular type.

It became apparent to me that much digital media advice for non-technical people really needs to come with a very strong health warning. Here’s one taken from a prescription medicine I’ve just retrieved from my bathroom. It needed only very light editing and seems quite appropriate:

REMEMBER this advice was prescribed only for you. Only a digital professional can prescribe it. NEVER give it to someone else to use even if you think their project is similar.

Looking at Ryan’s blog the advice is for “dealing with developers and choosing a platform for your [Knight News Challenge] project”. As a previous winner of the KNC he should know what he’s talking about here. Unfortunately in the process of being prepared for the KNC blog its intent seems to have been overstated. It is not, unfortunately, advice on “how to manage technology decisions in 5 easy steps” — which is a shame, because I and a lot people I know could do with easy answers to hard technology decisions. Nor does it provide guidance on “How to hire developers”, as the intro suggests, unless you’re hiring one or two developers specifically for the KNC.

This may sound flippant (perhaps, admittedly, because it is) but there is a serious point here. I suspect there are going to be many more people following the KNC than there are participating, and I think a lot of those followers will be people in the process of embracing digital media projects for the very first time, and will be looking for guidance. Perhaps they are just starting on digital projects within their current traditional media companies. They will need good guidance so they can make a reasonable success of their early projects and so feel confident about getting more involved. The media industry needs those people to be successful.

But taking the right advice for the wrong project will lead to problems. Here are some instances of Ryan’s advice and where your (or a colleague’s) situation might require something different…

1. Learn a little bit about any one Web framework, standard, or programming language

If you’re leading a 2 or 3 person team then it’s a good idea to understand the technologies your team members are using. But you may find yourself in a slightly different position in a larger team. In that case the level of conversation you need to have with people will be different. If the technology being used is fairly complex then deep-diving into a particular web framework or programming language is going to be far less useful than having, say, a good overview of the technologies involved and why they’re important — if only so that you can ask appropriate questions and deal with the answers appropriately.

2. Choose the people you want to work with and spend an ample amount of time telling them what you want.

I’d never disagree with the “ample amount of time” part — if you don’t dedicate a lot time to your project don’t expect it to go the way you want. But the “telling” part will only get you so far. It will probably work very well if you’ve become an expert in a particular web framework which is the basis of your project, and if you’ve hired someone with less experience there. But if your situation is different your approach should be different. For anything ambitious or complex or imaginative the development will be an evolving two-way conversation, not a one-way monologue in which you’re telling someone what to do.

So, lots of good advice on the KNC blog for participants of the Knight News Challenge. But if you’re sitting on the sidelines you should not mistake the demands of the Challenge as being the same as the demands of whichever project you happen to be working on next. Get advice that’s been prescribed specifically for you.

This information has been provided free of charge under the National Digital Health Service.

…which was one of the two highest priority launches of project. Yet it happened around 12 months after we planned it, and between the planning and the launch we also launched the guardian.co.uk home page, video integration, and sections for Media, Technology, Business, Science, Society, Money and Environment. If it was so important, why did we take that seemingly roundabout route?

Actually, it wasn’t that indirect. In January and February 2007 planned all the work that was to follow the launch of the Travel section, which had gone out in November 2006. From our senior stakeholders we sought the business priorities, and there were two major milestones: changing the home page of guardian.co.uk would send the clearest public signal of intent (even though it was only one page), and launching our news content in the new design would demonstrate the depth, extent and utility of the transformation. So those were our two major targets.

But there was another major requirement running through all our launches, and that is that they should be sufficiently comprehensive and largely complete at the moment of launch — there shouldn’t be any obviously missing features or tools. Since the news agenda is both urgent and highly volatile the news desk needed a comprehensive set of tools with strong integration to be able to deal with the daily demand. That included polls, improved galleries, an audio player with better podcast integration, a wider range of layout templates, many more navigational components, more streamlined tools, cartoon pages, very flexible keyword management, and much more.

It was, in total, around a year’s worth of work, so getting there directly would have meant no major launches — no tangible benefits — for a year, and that just wasn’t on. Agile development is about providing value early. To deal with this problem we exploited that fact that many sections, such as Science and Media, would benefit greatly from early launches and wouldn’t need such a comprehesive featureset as News from the word go. And developing those other sections would help build up towards News. We then calculated that if we wanted to get to the News launch with a detour through those other launches then it was a difference of only 6%.

Clearly there were big wins all round. Many sections were launched early so those desks got the benefits early; the commercial team was able to make use of the flexible advertising early; the technology going to the news desk was tested and refined well ahead of launch; and the risks normally inherent in a big bang launch were drastically reduced.

Speaking personally, I found the launch of the News section surprisingly muted. Lots of the public excitement and discussion around the reworking of our site had occurred when we launched the front page many months before, and continued in varying forms with the release of each subsequent section. By the time we got to the News section it was much less startling to those outside looking in. But in terms of internal change so much traffic goes through the News section, and it involves so many people working with it each day, it was very significant. Frankly, big launches which happen with so little fuss is something I’m very happy to live with.

…which was not part of the project scope when we started R2. It’s fair to say that when we began implementing in February 2006, the idea of a Guardian America launch was not on the radar. Yet by the middle of 2007 it was being talked about very seriously, and increasingly so. How did we fit in an additional sub-project?

As much as technologists might sometimes think they hold the key to success, when it comes to media it’s still true that content is king. Guardian America’s success is driven from its editor, Michael Tomasky, and his team. But technology did provide the vehicle for that.

The most valuable thing we technologists did for Guardian America was to not reinvent the wheel. We recognised that the core elements had already been built — most notably a front page designed to showcase a variety of content was already in use as the guardian.co.uk front. Making use of that also ensured design consistency. But that’s not to say there was no work to do. The content management system was not originally designed to support two major fronts, particularly with a variation in branding. The core work, then, was to extend something we had already delivered and make it more useful.

Using this approach everyone won. The Guardian America team got all the functionality and flexibility that we had delivered for the team running the original site front, and they got it relatively quickly. From an operational point of view, by managing Guardian America in the same way the guardian.co.uk front was managed, the GA team was able to share skills, people, advice and creative ideas. The tech team got to show they could deliver technology for a high-profile project on very short timescales. The business as a whole won because the overall R2 budget remained constant. We managed that by deprioritising a small amount of less important work in the usual Agile manner. I don’t think there were any arguments about what, exactly, was deprioritised, since Guardian America was so clearly more significant than many other features on our list.