Tag: organization

Minimum Viable Bureaucracy: Introduction

Posted on September 18, 2013August 3, 2017 by Doug Belshaw

We really are rather fortunate, aren’t we? I mean right now, as I write this there will be conferences all over the world taking place. And a good number of those, especially in my areas of interest, are likely to be livestreamed meaning I can (theoretically) follow along at home. But more than that, these live streamed sessions are often also recorded meaning that these talks can kept for posterity and used as learning materials in a course (like a MOOC).

The difficulty with the super-abundance of learning resources is that it’s difficult to know where to begin. It’s hard to know what’s worth paying attention to – hence the Web Literacy Standard (“here’s the things you should pay attention to if you want to get better at reading, writing and participating on the Web”). At Mozilla we have ‘brown bags’ every so often – talks that take place at a Mozilla office (often Mountain View) that are streamed out via Air Mozilla. As with any kind of event, some of these are of more or less interest to me and/or feature people who can present better than others.

Recently I my colleagues directed my attention towards a brown bag given by Laura Thomson entitled Minimum Viable Bureaucracy. It’s so good that, after giving the talk at OSCon Laura was asked if she could repeat it so it could be streamed and recorded via Air Mozilla. It’s an hour long so I’ve taken the video, extracted the audio and created a separate MP3 file from each section of Laura’s talk.

So what’s it about? What is ‘Minimum Viable Bureaucracy’ (MVB)? Well, as Laura rather succinctly explains, it’s the difference between ‘getting your ducks in a row’ and ‘having self-organising ducks’. MVB is a way of having just enough process to make things work, but not so much as to make it cumbersome. It’s named after Eric Ries’ idea of a Minimum Viable Product which, “has just those features that allow the product to be deployed, and no more.”

The contents of Laura’s talk include:

Basics of chaordic systems
Building trust and preserving autonomy
Effective communication practices
Problem solving in a less-structured environment
Goals, scheduling, and anti-estimation
Shipping and managing scope creep and perfectionism
How to lead instead of merely managing
Emergent process and how to iterate

I truly believe that MVB is an approach that can be used in whole or in part in any kind of organisation. Obviously, a technology company with a talented, tech-savvy, distributed workforce is going to be an ideal testbed, but there’s much in here that can be adopted by even the most reactionary, stuffy institution.

My posts writing up Laura’s ideas can be found below. The original talk is on Air Mozilla, the slides are on Speakerdeck, and there’s a backup of the slides and audio on the Internet Archive.

Also, you might be interested in following Laura on Twitter – she’s @lxt.

Image from Bonkers World

How to implement technology successfully in your organisation.

Posted on August 8, 2012 by Doug Belshaw

Technology adoption

I spent some time in a local school this week talking to some members of staff about implementing educational technology. It made me realise that I haven’t talked nearly enough here about how to do that successfully. It’s simultaneously straightforward and painfully difficult.

Let me explain.

Technically, pretty much anything is possible. Short of thought-transfer and teleporting to the moon we live in a world with endless possibilities on the technical front. Whatever it is you want to do is probably possible.

Sucessfully implementing technology in your organization is therefore not a technology issue. Yes, it’s important to get right. But no, if you just focus on that your technology implementation will not work.

Here’s some advice for those seeking to introduce a new technology into their organisation.

1. Solve other people’s problems

This is the number one priority. If technology isn’t solving someone’s problem somewhere, somehow, then it’s superfluous. My experience is with educational institutions where I’d very much focus on solving teachers’ problems if you want any meaningful traction.

2. Get other people to evangelise for you

If you’re known as technically competent, then any success you have with technology is not necessarily seen as replicable by others. Get influencers on board. Embrace skeptics. Again, solve their problems.

3. Embrace constraints

You will always face constraints. These could be financial. They could be political, social, emotional or hierarchical. Whatever they are, if you can’t change them easily there’s no point whinging: you need to use the difficulty.

There might be a certain technology you’re being forced to use. So use it.

There might be some awkward members of staff or departments. So convert them or avoid them to begin with.

Strategise.

4. Have a strategy

This is blindingly obvious, but if you don’t have a strategy you can’t be strategic about your deployment of technology. “We want to introduce iPads to improve engagement” is not a strategy. It’s a hope. It’s a wish.

Strategies should be user-focused and have appropriate timescales. There’s a lot of talk around technology changing so fast that most strategies are meaningless.

Bull.

When technologies evolve rapidly, then strategies are more important than ever. They’re not perfect but use research such as the yearly (free!) NMC Horizon report to see which way the wind is blowing.

5. Turn on everything / default to open

You don’t know where innovation’s going to happen. In fact, it usually happens at the edges, at the places where you least expect it. That’s certainly been my experience.

So, when you’re deciding which features of a platform to turn on, first look at your strategy. If that doesn’t tell you what to do, turn the feature on. Let the users drive the innovation.

And, finally, default to openness. It’s what makes the world go around. Don’t hide behind e-safety. Don’t hide behind ignorance. Don’t hide behind what you think other people will think. You’ll be pleasantly surprised if you let go of the reins a little. 🙂

Image CC BY Veribatim

PRINCE2 for schools (or, why don’t schools have project managers?)

Posted on February 27, 2011 by Doug Belshaw

I spent last week studying for and taking my Foundation and Practitioner PRINCE2 examinations. Programme and project management is an expected part of the world I now work; in fact, funding and facilitating projects too risky for institutions to take on individually is pretty much what JISC does.

PRINCE2 logo

PRINCE 2 is a project management method standing for PRojects IN Controlled Environments. It’s generic and applicable to everything from painting and decorating your house through to the machinations of multinational corporations. Granted, at first the rather abstract concepts seem needlessly convoluted (‘dis-benefits’ anyone?) but the commonality of language and ability to tailor a workable organizational structure make sense in the end.

What I can’t understand is why most schools shun formal project management methods? More than any almost any other type of organization, schools have to deal with constant change: personnel, curricula, buildings – so many different elements! Whilst it would be overkill (and the cost prohibitive) to have everyone within an organization PRINCE2-ceritified, I would definitely recommend the following:

Senior & Middle Leadership – full PRINCE2 Practitioner status

Teachers, Learning Support Assistants and Site staff – PRINCE2 Foundation status

If tied to professional development activities, the 7 PRINCE2 principles could really make a difference to organizational efficiency:

Continued business justification
Learn from experience
Defined roles and responsibilities
Manage by stages
Manage by exception
Focus on products
Tailor to suit the project environment

The three I’ve highlighted would in particular benefit schools and make them much less frustrating (and much more productive) places to work. To explain those three:

Continued business justification – at the end of each stage the Executive (usually be the Headteacher) decides if the ‘business case’ is strong enough to continue the project.
Defined roles and responsibilities – project roles are based upon the ability of the person’s role within the school to allocate resources and carry out the task (and not on personalities).
Manage by exception – once each stage plan is agreed with specified tolerances, the project manager gets on with it, only raising exceptions to the Project Board if the tolerances (time, cost, scope) are exceeded.

I’ll explain more about PRINCE2 if there’s enough interest. I may not be qualified to give the training, but I am qualified to write explanatory blog posts. 😉