The shape we're in (with a musical digression)

Today I'm still making the most of the quiet to dig into my vinyl and I'm working to the sounds of the german underground, mainly circa 1970-75. Right now, though, Phew (1981). This just so blows my mind. Can fans must have it, and they can get it on CD now (perhaps I will too, it's so hard to get at my LPs most of the time). Given that I've been writing about what our organisation needs to do to get its digital act together perhaps its good that the previous listening has been pretty calming: Alpha Centauri, Tone Float and Outside the Dream Syndicate (not that mellow, actually, the last one). Phew has lovely peaceful moments (like Dream, now), but a driving, anxious motion to some tracks too (Signal). The legendary Roger of defunct Revolver Records in Bristol sold me my copy, I don't think I've thanked him enough and probably never will, but thanks anyway, Rog.

I've been thinking about the holes in our policies (notably concerning the preservation of UGC - we may not want to bother, but we have to at least formulate a policy towards it), and I've been looking back over the 6 years I've been there and thinking about how our responsibilities have developed. We need to work up a business case for a larger team, and perhaps one of a different shape. Frankly it's a no-brainer, but the case needs to be made and it's a good exercise to outline those changes. We also need to work out with the Godot-like web committee (I'm sure it will be along any day now, with purposeful stride and a keen sense of what needs to be done) quite what role we want the web folk at MoL to have. There is a wide range of things we could be doing, and right now we try to do most of them, with some key exceptions like web design and rich media work (Flash, video), which we always farm out. But we do too much and can't always do it properly, and I feel the need right now to consolidate, to work on our infrastructure. If we can decide on exactly what we should be done in-house, and what can be effectively handled out of house, then we can get and give a clear idea of just what resources we need. Right now we have our content manager Bilkis (the one net gain since 2002), Mia, who does a lot of web work as well as various databases, and me, essentially just web.

Personally I reckon we need more people in the team, but there are alternatives, even if they're idiotic: the Museum could decide to draw in its horns and use our expertise just to commission, integrate and manage third party work, as well as content. We certainly do plenty of advising on this at the moment, and most of the vendors we've used recently have done great work for us (please drop me a line if you want to know whose work was not up to scratch), but I'm one of those who think the core work of a museum web team must also include taking care of the plumbing and probably building/running the core CMS too. Perhaps when I've finished my musings I'll post a proper list here of what functions I identify, what I think we should take into our remit, and what I think we should hand out. Best get on with it, then.

On the back foot with SMTP nightmares

Lots of catching up to do. Though I didn't post much before holidays, with too much going on at work, there are quite a few things I need to note down for my own benefit if no-one elses.
Firstly, though, my current trials.The last week or so have been a battle with e-mail. Mail from the web server has failed to get through and we have lost key capacity to diagnose and rectify the problem. The trouble is that it is a function that bridges several areas of comptetence and when we lost Rich May, network/helpdesk manager and good friend, back in April we lost vital knowledge, not to mention simple capacity. One of the great things about our team's structure is that we work side-by-side, pitching in as appropriate, whether we're developers, managers or HDEs, and I know it gives us an advantage over larger organisations with more differentiation/compartmentalisation because it we can have rapid, informal communication and the flexibility that comes from being all the same department. On the down side, the loss of one central member, not to mention the pitifully slow process of replacing him, leaves us badly holed. By the time a replacement is in position it will be three, perhaps four months since he left, plus one for his notice period. Of course, no-one will have exactly the same patchwork of skills nor the case-specific knowledge of the person they're replacing, but this is a study in how not to manage knowledge - far from allowing for a cross-over between outgoing and incoming employees the organisation has ensured that we have a 3 month gap between them. Of course, as much as possible was handed over to our excellent HDEs and to the rest of us on the team, but being short-staffed Help Desk have been unable to exercise much of its knowledge as they fight fires elsewhere. Projects have slipped and broken stuff gone unfixed - unavoidably, given the policies that left us underpowered for so long.
This brings me back to my e-mail issue. It turns out that e-mail from the web server does get through to external addresses (in fact, some, esepcially spam, gets through to our own mailboxes), and its looking like a spam filtering or probably DNS/SPF problem. I dabbled with these possibilities early on in diagnosing the problem but there were, as always, a number of overlapping or coinciding problems and red herrings and I spent a lot of time following these up. This is a very good example for me of how loss of capacity or knowledge can incapacitate our services or cost us dearly in time.