One single model for all Barely Repeatable Processes: IMCI, OODA and uttering of eureka!
Most of this summer I've been busy building real world pilots, process model templates for Thingamy that is.
When implemented and tested (such radical stuff) always inspires "straight and honest" reactions from uninitiated users - reactions that frequently had me slapping my forehead, utter a "duh!" and execute a quick dive into the code. An inspiring and quite practical process indeed.
A summer of Aha!s and Real Leaps Forward.
All the builds were for classic examples of BRPs (Barely Repeatable Processes), albeit bits, pieces and chunks of such.
Yearning for some holistic solution coupled with a hunch that we were getting closer I made many attempts on merging different builds and many, many rebuilds from scratch. Not always a success, but somewhat fulfilling as it seemed I was getting closer for each step.
Until the other day. Nailed it. I think...
Suddenly all the mess sorted itself out and in my mind I could see clearly how all Barely Repeatable Process were following the same four phases. With different time and resource use on each of course, but still the same four phases. Then I implemented those in one single working model. Enter, turn the key and drive off...
For lack of better words I termed the phases Initiate, Mature, Convert and Implement - IMCI.
Then my good friend Adrian went "hey, that reminds me of the OODA loop!". But of course, double duh: OODA - Observe, Orient, Decide and Act, a decision model/method devised by the US Air Force ages ago, also widely known in business.
My feeling of being so amazingly original was replaced with a warm and fuzzy feeling that I must be on the right path given the "prior art".
One thing is different though - I could build a working framework (in Thingamy) for that method / process model that could cover almost every iteration of it's practical use. In other words a generic BRP running engine that could cover most of what humans do in non-automated processes. Operate in one single and efficient framework where a mashup of collaboration software, knowledge and document handling systems, office apps, meetings and email does it's best today.
I promptly named the build BRP One. And it works. Suddenly bumping Thingamy from a platform onto which you had to build your own model to a out-of-the-box product.
Here are the four phases:
- Initiate (Observe in OODA):
The trigger, the source of activities, the initiator of what we do.
Observation of changes, new activities by the competition, a request (for a service, consulting, legal help, etc), an idea of any kind, a problem/issue is raised, anything.
Activity triggers in places where you work; consulting firms, in support departments, in R&D, in business strategy departments ("will the merger between Sun and Oracle affect us and what can we do?"), in marketing departments ("our Fiesta model is losing market share") - any and everywhere.
Observe and gather information from the source.
- Mature (Orient in OODA):
Sleep on it, discuss it, punt it back and forth - let it mature.
Put the "topics" (idea, issue, request..) in an easily accessible "pool" to allow free discussion and adding of notes, files and suggested "solutions". Allow participants to pick up a "topic" or a suggested "solution", then add comments or requests to it and punt it to some other participant for further and accountable action - "Please do some research on this.." or "Could you check that...?"
Currently the land of "Collaboration Software", email and hour long meetings.
Maturity is reached when possible future paths of action start to gel.
- Convert (Decide in OODA):
When a "solution" emerges as the way to go for one or more "topic(s)"; time is ripe to act and implement said "solution".
That's when a "team leader" (Project owner) makes the decision and "converts" a "solution" to a "project" (implementation, research, whatever).
- Implement (Act in OODA):
Any single purpose action is a "project"; involving one person or 10,000, a single task or a myriad of tasks and sub-tasks in all kind of sequences. Anything from "buy milk" to "build the largest bridge".
Let the "project owners" (project managers) conduct it all with ease and in full view. Include ad-hoc adding of sub-tasks to own tasks (or any for Owners), add more tasks to Project for Owners, add notes and files to any task or project, change path and rhythm at any time and let it all be transparent and have no glitches.
Now that I have a working framework that covers it all - time to dive back into some more real world work. Interesting times etc.
[P.s. for testers; latest version including the "BRP One" now up in the usual place...]
[UPDATE: BRP One now has it's own little product site.]
A big leap forward. Bravo.
Posted by: John | September 08, 2009 at 11:30
Very interesting approach.
Posted by: twitter.com/AAinslie | September 08, 2009 at 12:54
This pretty much reminds me of an old idea of mine: a generic 'trouble ticket' system for everyone - not just programmers. You could use it instead of e-mail, having the additional benefit of having all the history with you as well as who's responsible at the moment.
Just look at a good TT system (like Jira) where you can even define different task types and workflows.
The only question I have is where have the business model (like finances) aspect fit into this concept? I'll need to look at the latest version methinks.
Posted by: Peter | September 11, 2009 at 20:24
Ooh, but it's "a tad more"! A ticket system would be only the "I" in IMCI or first O in OODA.
Add the "punting it around", mature it, discuss it, work on it - then allow the right person or group to make a decision what's worth doing - then, and here's the big part :
Run a project where the "project manager" has been elevated from the usual secretarial tasks (reports, getting status, updating tools) to a proper "conductor" in full view and control.
Never ever request a "status update" nor write a report or update anything. All in one...
[But go and pick one up, it has that BRP One built in ready to go! :)]
Posted by: sig | September 11, 2009 at 20:34