Day: 5 November 2006

Varieties of Work-Changing IT

I had the opportunity to spend some time with Andrew McAfee in London last week, but for some reason I hadn’t yet seen his article in November’s Harvard Business Review. So we didn’t talk about it. Shame, but one that’s easily corrected.
It’s well worth a read; I’m working on my comments and will share them with you in a post later. In the meantime, I believe it’s available free-to-air for the rest of this month, so do try and take a look, you can find the article here.

I just can’t resist one comment though. Take a look at the table below.

R0611J_A.gif

Andrew makes one very very important point. Not that the others aren’t important, but one of them really stands out for me.

In the table above, he defines Enterprise IT as “IT that specifies business processes“.

He does not say “IT that is specified by random and ever-changing and poorly articulated and inconsistent and sometimes even nonexistent business processes.”

IT that specifies business processes.

By this I don’t mean that the IT department has to specify all the business processes, that’s just plain stupid. What I mean is that enterprise systems work well only when there are rigorous standardised processes; they work well when these rigorous standardised processes are industrial strength, with external frames of reference; they work well when the number of processes is kept to an absolute minimum, and where process divergence and diversity is avoided. The “system” consists of people, processes and technology, working to common goals and held together by a common culture. Too often it’s the process piece that goes AWOL, aided and abetted by avaricious consultants, accepted and nourished by inertial inhouse staff.
IT that specifies business processes.

If only that were true. If only I had a dollar for every time “respectable” consultants plundered the heart of an organisation by mangling an enterprise resource planning system until it was as unfit for purpose as humanly possible. If only I had a dollar for every time “responsible” business users lapped up all this attention and “blamed” the internal IT department for rampant project failure, because they believed the lie. The lie that an ERP system was meant to mirror their existing processes. because they wanted to believe the lie. If only I had a dollar for every time the internal IT department quietly acquiesced and said it was all their fault, fired a few innocents, promoted a few bystanders, whatever. If only.

Of birds flying around unwalled gardens: There’s hope in them thar hills

For a while now, I’ve been tracking what’s happening with Songbird, and more recently I’ve started playing with it. It works. At least the parts of it that are meant to work, work.

cross_platform.png

Ross Karchner at Ross Notes puts it succinctly:

  • Songbird looks like it is shaping up to be the cross-platform, open-source iTunes replacement I’m looking for, with some really great integration with the larger music web– It’s like taking iTunes, ripping out the music store, and replacing it with the rest of the internet.
  • Browse to any web page with links to music, and it becomes a playlist. Songs play instantly, and saving them to your library becomes a single-click or drag-and-drop operation.

I love iPods, and will continue using them. Because they’re fantastic. In design and execution and usability and experience.

I’ve never bought anything from iTunes, though my children have. iTunes is nothing more than an elegant way for me to manage my music, music that I’ve paid for.

I love Macs. I still have fewer Macs than iPods, but the gap’s narrowing :-)

So why do I like what I see in Songbird? Because I don’t like lock-in. I want to be able to choose my device, choose my platform, choose my connection, choose my everything. I understand when that is technically impossible. I am less tolerant when it comes to creation of artificial scarcities and blocks. Just look at the garbage that is Region Coding on DVDs and you will see what I mean.

Songbird may not be the answer. We have to wait and see. But it has possibilities. And is “directionally” sound. [Pun intended].

On filmmaking and software development: Part 2

Yesterday I ended my post with a quotation from Wikipedia on development hell, and that’s where I want to start today. There are many reasons why film (and software) projects go wrong, and they all have to do with the script.

The script is central.

When producers and directors are looking to attract talent into a project, they use the script. When producers and directors are trying to get funding for a project, they use the script.

The script is central.

It represents an embodiment of the idea that sparked it all off, the problem that needs to be solved, the market with a barn-door sized gap, the customer itch that needs to be scratched, the business plan that’s looking for funding.

And unlike the past, unlike the waterfall and cascade days that led to their development hells with inflexible scripts, the script now evolves. We iterate through scripts. We cut the script down into bite-size chunks so that everyone understands what is needed, what is happening, what each individual’s role is. This iteration process helps us visualise what is happening, what needs to happen.

It is only when the script is stable that funding can be obtained. It is only when the script is stable that the project is initiated. It is only when the script is stable that we can speak about going “into production”.

Development is about scripts. Production is about making those scripts leap off the pages and becoming alive. Post-production is about making the experience available to all.

What are sets? Nothing more than reusable infrastructures with temporary skins. The key thing is that set designers really worked on making the sets reusable.

What about stock shots? Nothing more than reusable commoditised components that add limited value, yet remain necessary. So it’s important to spend as little time and money on them as possible.

The concept of calling a “wrap” is nothing more than really understanding modular design. You’ve compartmentalised something so that it’s got high cohesion and loose coupling, you’ve iterated through that piece until everyone is cool with it, then you’ve said “Enough”. Not Perfect. But Enough. You have time in post-production to fiddle with it, this is not the time. Move on.

More in the 3rd but not final part, which I hope to write sometime later today or tomorrow. It will summarise what I consider the lessons that parallel the two sectors, in tabular form. So why will it not be final?
Because Stephen Smoliar kindly pointed out that Tom Davenport wrote some parallel thoughts down in Information Ecology in 1997, particularly in a chapter headed “As shown on TV: A new model for information staff”. I promise to find a copy, read the chapter and try and tie it all together in a fourth and final post. Can’t say when, it depends on how long it takes for me to receive the book. I could cheat and use Search Inside, but I’m not like that. I’d rather fight to change the law.

And because I want to read the book now that I’ve peeked inside :-)