Start Business Modelling Now!

Your organisation needs a business model � right now.

Actually your organisation already has one. Even if you don't have a business model defined explicitly, your organisation is still operating based on an implied business model which you don't understand.

Before roles and responsibilities, before scope, before strategy even, you should be documenting your business model right now!

Already done that? Well communicate it. Do your employees know it? Proceed to Step 2...

Step 2... Even better than documenting your business model is modelling your business model.

A working model of your organisation is not only a great communication tool but will also aid in formulating your business transformation strategies.

Does business modelling sound to 'old school' to you? You're wrong. It's important to every type of organisation.

So, if your organisation is zany and creative try modelling with Logo Serious Play:

http://www.tayfundemiroz.com/
New_Economy/Play/index.htm

If you're all engineers at heart perhaps you could try something like Top Modeller:

http://www-rcf.usc.edu/
~majchrza/topmodeler/

Pick one (or find something better); just start now!

Organisational Systems have a life-cycle?

Author Jason Pettus tells an interesting story about the inevitability of organisational systems turning feral:

http://www.geocities.com/
jpettus.geo/fp03/0702.htm

Perhaps there is no conspiracy here. Perhaps organisational systems have a life-cycle? What does this mean for management and organisations?

What is a Solution Architect?

The purpose of a Solution Architecture is not just to ensure a technically superior solution. An effective Solution Architecture enables the distributed design of a technically superior solution.

As such, a Solution Architect is not simply a senior technical designer. An effective Solution Architect combinations the skills of a technologist, business analysis, and change agent to visualise and drive the delivery of the overall solution.

The term 'solution' implies a fit within a particular business context and challenge. The Solution Architect needs to define that business context (and the required business transformation) with the same rigor as the technical components of the solution.

Once the layered solution architecture is defined, the Solution Architect switches to change agent mode � ensuring the delivery programme contains the most effective set of projects and work streams to ensure successful delivery.

Is Cutter. Is Good.

Cutter has always had interesting things to say about IT project management and development processes.

Agile Project Management
http://www.cutter.com/workshops/22.html
(pair programming is still a dump idea)

Agile Requirements
http://www.cutter.com/workshops/11.html

KM response

I had a chance to read through your knowledge management synopsis. I think we can twist a few of the ideas on there head and perhaps extend them further:

When you say 'a lot of knowledge is being held by the senior staff' I'm wondering is this is a cause or a symptom. Are these people senior staff because of their knowledge? Have they been promoted because of there knowledge? Or is the knowledge flow in EDS such that knowledge flows upwards more than it flows down?

It appears, as you have identified, that the value system which manages our organisation values our senior staff having knowledge rather than enabling its flow.

If these senior people are subject matter experts their specialist knowledge should be rewarded. EDS needs SMEs, they are a vitally important part of our business.

A senior EDSer with a lot of knowledge is an SME. If that knowledge is about the multitude of EDS processes they are an EDS Processes SME.

EDS needs to reward our SMEs. EDS needs to retain SMEs. EDS needs to develop more SMEs.

But an SME is not a manager.

A manager will never be measured by the knowledge they have; only for the capability of their team. Measurement of managers will always be like this. It will always be 'one step removed' from the management itself.

You will never hear a real manager lement that their staff don't know enough - because a real manager knows that they are responsible for the knowledge of their staff.

The essence of effective measurement of management activities is to always measure things one step removed from the management - thing that can't be directly controlled or manipulated. Numbers can be manipulated. People can be manipulated.

In this way management measures are more like market indicators. But to have market indicators you need to have a market. Most organisations already do.... But we'll get to that later.

Doesn't this mean that SMEs and specialists should be just doing what they want? Absolutely not! Specalists have all sorts of industry standards of practice that they have to follow.

When correctly applied this professional standards of practise might be called 'best practices'. But this term almost has no meaning anymore...

But we already know that employees should follow best practices don't we? It common knowledge that best practices are the way to go - this is true by definition. The best way to do something is the best way to do it.

Principle number ?; if something is bloody obvious. The simplist most logical thing to do. Then why isn't it being done? Easy. Because organisations do name operate on logic. They are social and they are political but they are not logical.

Two principle are at work to solve this. Firstly, 'time spent doing one thing is time not spent doing another'. Best practices are driven from listening to peer. To comparing the results of competing processes, behavours, and value systems.

If SMEs and specialists are going to learn 'best practices' (either from experimentation or from others) they need to stop doing something that they are currently do in order to spend the time developing capability....

What to stop doing? Easy. Stop listening to their managers telling them how to do there job. Stop listening to their clients when they tell them how to do their job. Seriously.

Christopher Alexander often inspires me. I've never read a single book of his or seen anything he has designed. But each quote I read is fasinating.

That the time he was trying to design a process that would allow anybody to design a building project in Mexico (remember Chris is on a misson to save the world from a bad built environment - and he realises that he simply can't do it himself).

When he design the process for this project in Mexico he basically said 'you get all of the requirements, making sure you really do cover all of the requirements [don't wanta miss any of those requirements] and then build a solution that is isomorphic to the complete set of requirements and [da da!] you have a solution.

You know what happened. The buildings sucked! Or at least they failed to impress Chris. They really did meet all the requirements but they were different to anything else. No differentiation. Ask Micheal Porter. That means death.

When our clients demand more innovation. From our proposals and from our solutions aren't they just saying 'don't simply meet our requirements'.





But they are responsible. That's what hierarchy means.

But what are managers left to do? Nothing. No way! There is plenty to do.

Schedules (but they are personal and not above deliniation. Because the sequence in which you do something is part of the competency!)

Resource marshling (but how can you marshing resources if nobody is allowed to leave you? If you get given 'responsibility' for them. But you can never be given responsibility for anything......)

They can be a type of architect too. A delivery architect. But they are measured by the particular architect soft and hard skills. No the vague 'manager' skills that have got us into this mess.



How do we start to make these markets?

* blogs:- not everybody will want one but; what does it mean when a manager never posts anything? if a subject mater expert never posts anything? if a manager posts a lot but nobody reads it? if somebody only collects links to everybody elses information (does EDS value this? should they?)?

* leave gaps for them

MWT/IT - Programme Definition Worksheet - Review 1

MangeWithoutThem is largely a general management model. But it advocates the creation of 'collaboration architectures' which are task-specific. Because I'm in the IT consulting business, and because I claim that the management process should be more task-based than it is traditionally, whenever I get specific I'm likely to talk about IT management.

Even more specific than that, I'm likely to talk about the delivery of technology-enabled business transformation programmes. Sound like buzz-words to you? So be it. You'll notice IT content is designated MWT/IT. This content shows how the ManageWithoutThem model applies to IT consulting and may be skipped by those without an interest in this area.

The first collaboration architecture I'm developing is used to define the various projects, work streams, and delivery responsibilities within a technology-enabled business transformation programme.

This is a tool I have used for a few years now for trying to get clarify around how a programme is organised. The initial unannotated diagram can be found at:

http://www.managewithoutthem.com/
posters/Programme Definition Worksheet - TEBT.pdf
(AvantGo users will need to visit ManageWithoutThem.com)

I will be annotating this diagram and developing instructions for its use in the next few weeks; but any feedback is appreciated.

Phones and Clouds

I recall when working in a recently (partially) privatised government department that the IT department manager's two young children come into work one day.

These were good kids, also very bright. They ran around good naturedly exploring the cubical-scape we all worked in.

In the middle of the floor was a whiteboard we never used and they managed to find some whiteboard markers that worked (I have no idea how � I never could).

The picture they drew was quite simple. It was a field of telephones. All the telephones were ringing. In the top left hand corner there was an extra large telephone in a cloud. An arrow pointed into the cloud, labelled 'My dad'.

Beside each and every telephone, even Dad's, was a sad face. How would a child draw your workplace?