Tuesday, November 28th, 2006
Adopt early, adopt often
Back in 1998 when I started teaching myself web design, I would spend a lot of time talking to clients and trying to explain what the web is, and why they needed a web site. Most of them didn’t grok it, and disappeared back into their analogue world. The internet wasn’t all that new, but it was new to them.
The design cycle was pretty long. There’d be meetings where I’d try to figure out what they wanted. Then I’d go away and put together the site architecture - which pages link to which and what do they have on them? I tended to work very hierarchically, starting with a home page at the top and then creating a sort of family tree of pages. I’d do draft designs at the same time - screens, rather than wireframes, because most of my clients weren’t sophisticated enough to know what a wireframe was. (Come to that, neither was I.)
Then we’d haggle. They’d tell me I was charging too much, so I’d pare down the scope of the project and give them a cheaper price. Eventually - hopefully - we’d have a deal. I’d then go away and design the site, frequently also editing or writing the content, and Photoshopping the images.
Then I’d upload the site to their hosting, they’d pay me (or I’d sue their asses), and that would be that. Job done.
Some projects took months, half a year or more. How quaint all that seems now.
That was eight years ago, but I am still having the same conversations now. All you’d have to do is replace ‘internet’ with ‘web 2.0′ or ‘blog’ and you could parrot one of my client meetings from ‘98 almost verbatim and no one would notice.
The problem is, companies are still have very long decision making cycles. These painfully slow processes are fine when the world around you moves slowly, but technology changes quickly. If you want to get the best out of social software and ‘web 2.0′, you have to be on top of what’s going on. That doesn’t mean jump on every bandwagon that goes past, but it does mean assessing and adopting new tools at a speed a bit faster than glacial.
IT departments are used to the traditional software development model - one, two or more years before releases, and what you get is what you’re stuck with until the next update, bugs or no.
Web software doesn’t work like that. The adage ‘release early, release often’ has been taken to heart by many of the developers working on social software and web apps. Start with a limited alpha, move on to an invitation-only beta, scale your beta slowly and then, eventually, you might reach the mythical Version 1.0. Or not, depending.
For users of this kind of software, the update is a regular attraction. Some software even updates on a nightly basis, with test builds released for the keen user to try in between major releases. And you do have to keep up, not just for the bug fixes, but for the new features which are quietly released, with no fanfare and, usually, no additional fee. Major upgrades you might have to pay for, but in the most part, these small apps accrete features as a matter of course.
Within big business, this poses a problem. If you have a traditional IT department that likes to slowly do its due diligence, it’s going to find that the software it assessed a few months ago is unrecognisable today. It’s tempting to say that this is irrelevant - businesses use enterprise software so why should they care that the small developer releases early and often?
Well, if you want a decent RSS aggregator, or a desktop blogging application, or even just a blogging platform, you’ll be hard pushed to find anything half decent from a major player. All the good ones are created by companies (or individuals, or open source communities) orders of magnitude smaller than your normal enterprise mush.
Why does this matter? Well, whilst your IT department is faffing around on a never-ending cycle of due diligence, you’re failing to take advantage of the really useful stuff that’s out there. The opportunities to use blogs and RSS and wikis to help your staff do their jobs more easily and more efficiently are passing you by.
So I’d like to propose a new adage for those struggling with the concept that software doesn’t have to be perfect to be useful: Adopt early, adopt often.
Loading ...
November 28th, 2006 at 1:15 am
One of the things we do to determine if we should adopt a new technology or not is to listen to what the customers want. And continue having a close relationship and dialog with them. That way, we make sure we are adopting the right and most useful technology, instead of constantly looking at what our competitors are doing
November 28th, 2006 at 9:43 am
Yes, decision making cycles in the corporate space are long. Although the conservatism of IT departments outlined above is a significant factor, one also needs to bear in mind that many companies are stuck with relatively rigid, hierarchical structures, into which websites don’t always fit easily. Responsibility for the website could fall to IT, or to sales and/or marketing, or corporate PR, or worse yet a committee…
In my experience the people within the enterprise with interesting ideas tend to be newer and younger, and there could be several levels of management between them and whoever signs off on a project - all of which equates to time lost on meetings and memos, and of course the potential for miscommunication along the way.
This sort of rigid culture isn’t healthy, and it really only works if there is a pretty clueful person at the head of the pyramid, who’s able to appreciate the potential benefits and also take an overview of how each department can best participate.
Of course, it’s far better to do away with the rigid structure and have a corporate culture where “respect for hands-on knowledge wins over respect for abstract authority”. But this is decidedly rare, and the enterprise space is the poorer for it.