How far to enforce standardisation?

Posted on Tuesday 20 October,2009 by Ben

We’ve just started work with an existing client on a fair sized project. Essentially they have inherited a rack full of IBM servers and associated equipment from a related organisation, all a couple of years old, but still great kit. For this particular client this presents a long overdue upgrade to their existing system. This particular office has grown extremely quickly to the point that we’re now supporting over 30 users on a single HP ML110 server (that’s the reeeaal small baby server, by the way). It’s been a great test of what the ML110 can do, given that we would never put one of those in for more than 5 users. I can tell you though, we’ve been working pretty hard here at the garden shed lately to keep that poor little box running.

So in a nutshell the project is to migrate their one little SBS 2003 Standard system onto SBS 2008 Premium, splitting out various services onto different physical servers. The final system will look something like this…

Server 1) SBS 2008

Server 2) SQL Server, SharePoint, Search Server

Server 3) Terminal Server

Now running this as a project, we know how much time it should take. We know that it should take x-hours to migrate SBS off. We know it should take another x-hours to build up SharePoint, migrate their intranet across, and so on. So how’s our time going so far? Not so great to be honest. And do  you know why? Because the initial resourcing for the project was outside of our control. We’re working on IBM kit here, whereas we normally work on HP. Am I worried about IBM kit? Not in the slightest, it’s good stuff. But the point is we don’t work with it every day like we do with HP. We don’t know the kit inside out, so we’re having to go through a substantial learning curve to come up to speed. Not only that, the kit is all second hand, so it’s been configured, spec’d and so on to fit together in a certain way. To a degree we’re having to reverse engineer that process to understand how and why things were spec’d the way they were, so that we can put them back together again in the right shape. And all this takes time..non-billable time.

It really does raise the question of how strict we should be in enforcing our standards on our clients. After all, we insist they have antivirus protection for their own good. Ultimately we insist on this to save them the pain and cost of an infection. So what about enforcing standards such as what hardware we’ll work with? And I’m not talking about ‘only tier one’ stuff, I’m talking about ‘only the HP xxx series’.  If we work with hardware that we know inside out, we can provide much better, faster support on that kit, which should ultimately provide the client with a better, cheaper experience. Or is the fact that I’m classing our learning time as non-billable really cushioning the client from that reality, at our expense? Where do we draw the line between flexibility, and efficiency?

And I say all of that non-rhetorically. That’s a question. What do you think?


2 Responses to “How far to enforce standardisation?”


David Harcourt October 20, 2009

It may seem a little cold, but I feel that if we have to spend time learning a client’s systems, it *should* be billable. Whether that’s learning about a proprietary LOB application, specific hardware configuration or obscure/undefined chain of command/authority etc, we are investing time (and let’s not forget that time = money) and losing revenue in order to overcome the shortcomings in a client’s infrastructure, whether that be hardware, software or meatware.



single_blog.php