Thursday, November 01, 2007

The beta generation

When we are developing learning solutions for clients, we have a process that we follow. Once a project has been scoped and the contracts signed, we draw up architecture and design documents and start to mock up the solution. We do this in stages with sign-off at the end of every stage. Alpha. Beta. Gold.

While the process is restrictive, it is also necessary to prevent "scope creep". We will have quoted our clients on the delivery of a specific product, and entered into a contract to that effect. As the project progresses, there is a very strong chance that one of the stakeholders (or one of us) will have a brilliant idea that has the potential to transform the solution. Or the client will suddenly realise that a particular issue wasn't mentioned at the time of scoping, but is critical to the issue at hand. Unless the client-side sponsor is prepared to completely re-evaluate the budget for the project, it may be impossible to implement said brilliant idea, and there will almost certainly be an additional cost involved in expanding the brief to include the overlooked issue.

I totally understand the drivers behind this. We can't work to an ever shifting brief off a fixed budget. That's what the scoping document and change control process are there for.

Sadly, we now live in a different world, where it is not just the epiphany that has the potential to upset the apple cart. Allow me to elaborate.

I have been working with a client on and off for about two years on a transformation project. My role is to design the learning solution to support the client side staff members through the transformation process. The problem is that the transformation process keeps, well, transforming. We never seem to reach a point where the processes are robust enough to warrant spending money developing a learning solution to support it. We seem to be burning budget just keeping up with the changing process, without ever getting as far as building the solution. Every now and then, the client will call us in, thinking that the time has come to start developing the learning solution. Then, in the course of the discussion, it will become evident that this or that area of the process has yet to be finalised, or an issue comes to light that no-one had even considered before, so we will be put on hold while these matters are addressed.

And while all these changes are going on, the staff members are speculating and no-one is quite certain where everything is going and what the medium-to-long term implications are for them as individuals. This has happened more than once, with different clients. On a previous occasion, the project simply fizzled out.

It puts me in mind of all those analogies we use about life being what happens while we're waiting for something else, or about children learning as much from their parents' unguarded moments as they do from those that are intended to be informative. It seems to me the time has come to develop a business model for a permanently beta learning solution for a permanently beta transformation process, because these seem to be increasingly the norm.

If we wait for the processes to be firmed up before we deliver a learning solution, we may never deliver the solution and, in the meantime, the staff are wondering what the heck is going on and why no-one ever tells them anything. In extreme situations, they may even get the impression they are deliberately being kept in the dark.

So how will this model look? Maybe it will have to look more like an SLA and less like a fixed contract. Or perhaps there needs to be less initial solutioneering and more on-the-fly stuff developed on a time-and-materials basis.

Looking ahead, (I think) I see an increased need for fleetness of foot and handbrake turns. And my opinion is that, not only will/should this influence the nature of the learning solutions put in place for staff. It should also influence management styles. Keeping everything close to your chest until you have "something definite" to tell your staff may see you never speaking to your staff again!

Those with more commercial nous than I have tend to groan at my naievete on this point, but I can't see how we are going to successfully navigate our way through the murky waters of permanent beta unless we are open, honest and transparent about it.

So that was me, thinking aloud. What do you reckon?


Ignatia eLearns through the web said...

Seems a very sensible approach, the more open a change management is, the more people feel inclined to add their thoughts and actions to it. This can only increase the changing momentum and speed up the acceptance.

Did you see the link SoulSoup posted yesterday? This manager - Ricardo Semler - opens up to change and I really like(d) that speech.

Karyn Romeis said...

Hi Ignatia. Thanks for the link - somehow that one slipped by me. Wow! What a secure man he must be.

Nicola Avery said...

Ricardo's great isn't he, I have Maverick and 7 day weekend, it was the first time that I skipped along the road, in many years - in Bournemouth when I read them :-)
Still he lets his people experiment and as he says, if we try and implement some of the things Semco does along with the regular corporate strategies, cultural fit - it is hard to do because somewhere along the way - policy is going to get you!!!

Re the eternally evolving learning solution, how frustrating !!! I'm not sure what the answer is, if the client is insisting that the solution is still appropriate for their original business case (have they looked at those figures in a while ?), where do you stand - if you scrap the solution like you say - there goes budget and in terms of the solution and reusability - hmmm
If it is a contractual amendment or would it be an additional 'project risk' (can't think of a better business description at the moment) clause in the original contract.

I dod like the idea of an open solution though and seeing as many web 2 startups are very quickly opened up in beta, maybe this is an answer - to deliver the solution in some form - to the client, allow the client's organisation internal knowledge (i.e. get their people to contribute to the learning solution in an agreed way of inviting feedback - wiki or whatever)to develop the solution further under your expertise.

Or they give you access to pilot the solution or part of it with a group before beta (i'm all for rapid prototype type pilots or mini-tests)do they do this anyway?


Karyn Romeis said...

Nicola: Thanks for you input. I'll have to track those books down.

Some of your suggestions have been put forward and we have varying degrees of buy-in to them. Others I'll have to consider to see whether they're a cultural fit - because, to borrow your phrase, somewhere along the way - culture is going to get you, too!

jay said...

Karyn, the entire world is in perpetual beta. Nothing is ever finished. Check out Stuart Henshall's post on David Snowden. Complexity precludes closure.

Some people will always be satisfied to quit earlier than others. It's so satisfying to say "I'm done," even when it's a delusion.


Karyn Romeis said...

Jay: I appreciate this. However, in the past, processes have remained stable for a long enough period to warrant an orchestrated roll out, with carefully constructed learning support.

Nowadays, there isn't even enough time to master one thing before it fades into obsolescence. Instead of seeking to master things, we now seek simply to keep pace. Hence the need for more transparency in management, IMO.

LaDonna Coy said...

Hi Karyn,

I found your blog via the Complexive Conference and what you are describing resonates with my experiences in social change work with government and non-profits as well. I've struggled with getting things "out the door" in "gold" form including timing, content, etc.

I think it is in Wikinomics that Tapscott mentions, rapid protyping, meaning shorter, tighter development cycles. I wonder how that might translate here with your thinking about projects in perpetual development (always beta)? I would imagine there's plenty we can learn from software developers (particularly open source) who develop enough to roll out and then continue to develop and update. Some updates being more significant in size and scope than others.

I have no answers, just plenty of healthy curiosity and willingness to learn deeper. I'll give it more thought. Oh, and nice to make your virtual acquaintance!

Karyn Romeis said...

LaDonna Nice to (virtually) meet you, too.

I reckon the problem with this approach is that it's going to be a tough sell. I can't think of many clients who will be comfortable spending money on something that will never really be "finished" as we have understood it up to now. Even if they understood the reasoning behind the approach, they are likely to have understandable qualms about explaining their decision to the board/shareholders!