Low cost, Low stress Customer focus-Here’s how

I know that some of my readers are from a technical audience and others are from business, so it is always a struggle to pitch the language right. I have decided to write a mixture of blogs in both styles so that we can talk about the same subjects from different viewpoints.
Last week, I spoke about agile. I wrote it in a non technical way, hopefully, but it was intended for IT directors, Programme managers and Developers.
Today I want to get right down to brass tacks.
20 years ago when I was running marketing campaigns for Encyclopaedia Britannica and my job depended on this months results, I learned very quickly that I needed to get right inside the customer’s head and stay there if I wanted my campaigns to work. A leaflet drop on the day of the FA cup would have been very amateur. I found we had too types of customer, book lovers and proud parents, so I wrote about the love of learning and about helping our children out achieve us.
I delivered the message when they were relaxed and receptive and through trusted media.
Why am I teaching my granny to suck eggs you are hopefully asking?
Well here’s why customer focus is at the root of agile methodology.
You may remember the parallel to lean and the spoon bending example
Just as the spoon factory relies on the bending of the metal to create value, so your business relies on the customer experience to create value.
When we create products, we are creating a perception of value in a consumers mind. Hold that thought. A Jag costs more to build than a Ferrari, but sells for a lot less. Why? Customer perception.
Amazon customers return regularly, most websites fail to get a second visit, why? That’s right, customer experience.
How agile delivers on customer experience
Agile should always begin with a customer journey. Remember, this is the spoon bending moment and agile gives you the hot 20% first, hence we begin by describing the customer experience and understanding the thought processes, fears, hopes, wishes and aspirations.
Now most agile practitioners talk about customer journeys. The words are fine as long as the understanding is clear and I suspect that it rarely is, experience seems to point that way. Customer journey is a whole lot better than programmer’s viewpoint, but it is still a process viewpoint.
While understanding the buying process is an advanced state for many marketing professionals, making an attempt to understand the customer experience is an enriching journey in more ways than one.
The agile process should begin with real live customers explaining their experiences in a focus group or other comfortable setting and then continuing to review and comment on the wireframes and prototypes as they emerge into a system ready for pilot with a larger group.
Release early and release often
The Dragon’s Den may be mostly high Farce, but they all agree on one piece of solid advice, The only true market research is to go out there and sell it to real customers. This is the second strongest argument for agile.
Start with customers, pander to their experience, produce something quickly and test it with more customers until your customers have built you a winning product that can be released with confidence and with a loyal and knowledgeable user base attached.

Ed Taaffe

Tim Berners Lee is on the money yet again.

There’s been some hype going around that the internet volumes are beginning to clog it’s arteries and that there are issues ahead.

TBL reacted to this by saying something to the effect that; the internet is not at risk form volume of information but volume of misinformation.

Let’s just think about that. There was a time, long before Google, when a tool called webcrawler claimed to index every document on the internet and as I recall, it went damned close. Today nothing can do any better than scrape the surface and what is more, there is little appetite for doing it.

It was incredible what you could find with a bit of patience back then. For me the quality lay in the surprise. I was exploring as opposed to searching. In those days surfing was something a few cool people did instead of watching Corrie. Nobody has time for surfing now though.

The novelty became the business tool, became the competitive advantage became the essential productivity tool in less than a decade. Not only do we not have time to explore for nuggets of knowledge and correspond with interesting knowledgeable people around the globe, we need filters to delete 80 % plus of our mail, we are trying to develop trusted networks to find people it is safe to talk to and our problem in finding the information we once only dreamed of, but now rely on for survival, is one of wading through the rubbish to get to it. I suppose this effort counts in that equation, but if you can’t beat them, well!
My point is this, if you don’t know something, or worse still you don’t know that you don’t know, then more information, data, or even knowledge is probably not going to help you and in fact, it is inevitable that before long you will find several contradictory experts.

So where did it go wrong?

Man’s access to and use of knowledge has always involved trusted sources, be they books, or advisers and when things were really important, second opinions were critical.
It was never important to be right, just to be trusted. All sources were expected to be wrong sometimes, but far better than no knowledge at all

My favourite description of knowledge is the one that says it is “to know”. That implies it is known by a person. In scientific terms it is often broken down into explicit, implicit, and tacit.

Let’s explore this concept for a moment;

Very little knowledge is explicit and it generally refers to hard data in my view, though some will argue otherwise.

The fact that john selected b as his favourite response out of abcd is explicit. It’s not much use though.
Let’s jsut assume that we all now what the context of absd was, 100 replies like this would make up a useful block of explicit knowledge.(data in my book)
What that information tells us (implicit knowledge) , may be that the males prefer B and the females D. However, an experienced researcher might spot the fact that it had nothing to do with gender but, was a result of colour blindness, or another aspect lost on the rest of us. (tacit knowledge)
At this point you have the full package and you are reasonably safe to make a decision of some sort.
My view and most business people would go along with me, that any less than the full pcakkage would be dangerous indeed.

If we follow that hypothesis and set these standards for knowledge and if we measure the internet in this way, there is an enormous need for reliable knowledge that combines at least the first two elements if not all three, in order to be truly useful as a source of knowledge.

So far we have succeeded in creating a few working proptypes of semantic modelling and inference engines that are capable of implying a level of information int the raw data out there, if and when we ever find a way to implement it.

Here are my questions:
 Where does the internet serve this need for knowledge?

Is it ever likely to get be achieved?

Is this need actually worth serving?

What would success look like?

Would more information or even more knowledge lead to better decisions with any degree of consistency?

Ed Taaffe

Agile software development, why every business ahould know about it

The name conjures up interesting images that appeal to most directors and senior managers, but when it is all discussed in the open and fully understood, the enthusiasm sometimes evaporates to a whispered yes. Why should this be?
Well I know of a number of reasons:
1. Agile done badly dispenses with change control, from requirements, technical specifications control, all the things that a business feels protects them from misuse of their budgets and at the same time all the things that prevent programmers from grinding the world to a halt with their vision of what a system should be.
Everyone has a great time for a period and then it all comes home to roost and back to waterfall, the BA, the signed-off documents and formal everything.
2. Agile done well shares responsibility for the success of IT projects equally and fairly between the business leaders and the system designers, developers and maintainers.
They’ve had it easy for years blaming it all on IT departments and bemoaning the fact that “these fellows talk gibberish we don’t understand”. IT ranks just ahead of Estate agents and Lawyers at the moment and not all unearned, so it is easy to generate sympathy and blame it all on IT. Now the tide is turned, communication is there, gibberish is gone and decisions are made and shared out in the open with shared accountability.
Not everyone has the stomach for this.
3. Agile is different. It does not feel comfortably familiar and it’s not always easy, especially in the beginning, to see what is coming and why it will work. A bit like trusting your Sat Nav for the first time.
4. Most people claiming to do agile are just flying by the seat of their pants. This is like comparing Billy Connolly , renowned ad lib stand-up comedian to a drunk who thinks he is funny. The only thing they have in common is that they both appear to be ad lib. And of course one is.
Agile works and delivers tens of millions in value every year, so why should you be using it?
Here’s why;
· Agile gives you the thing you need most and it delivers it on time so you can stay competitive and stay in control of your business.
· Agile puts you completely in control of your IT department for the very first time.
That’s pretty strong stuff and here’s how it works;
History shows that between 15% and 20% of the functionality in any system is still in use after one year. Much if this is down to the way requirements are gathered and accepted conventions in the world of software engineering that are never tested against a business case. E.g. reusability.
The time and cost overruns that drove you to distraction were nearly all spent on the 80% of that system that was rarely or never used.
Agile can’t entirely remove the wastage, because only an element of inspired stargazing could predict every change in circumstances coming your way, but it can reduce this wastage to an absolute minimum..
Agile quickly focuses your thinking on the core functionality that you desperately need and the bear minimum implementation that will work for the business and it gives you this quickly. They used to call this “Low hanging fruit”. Then based on demand from your stakeholders and users and a sound business case, it fleshes this out to the optimum system in bite-sized , low-risk chunks.
If you took lean or six sigma principals and you applied them to the waterfall process for software development, you would end up with agile
An early lean evangelist spoke of a spoon bending factory that bent blanks into spoon shapes and sold them to spoon manufacturers. The business shad sales, shipping, HR and the usual refinements, but the only time and place value was created was under the hammer when it bent the metal blank. Everything else that happened in that business was creating waste and the purpose of lean is to reduce that waste.
Agile gives you the hammer first, this way you are creating value quickly, then it looks at your other needs

Change is not monkey business

Now let me give you a puzzle to solve.
By the way there’s no right or wrong answer to this, but please keep ending them in.
The case study.
Five monkeys were thrown in a cage with a banana on a shelf in the centre.
Each time a monkey approached the banana all the monkeys were sprayed with ice cold water from a hydrant so very soon they began to attack any monkey who approached the banana in order to avoid being sprayed. Then the hydrant was taken away and each monkey was replaced with a new one over a period of months. Each new monkey approached the banana and was immediately beaten up, therefore quickly learning the rules. Eventually there was not a single monkey left who had seen the fire hydrant yet the beatings continued.

The test.

If you were the next monkey to be put in the cage, what would your strategy be?.

If you were a monkey put in the cage to stop them beating each other, how would you approach it?

If you were the scientist controlling the experiment, how would you stop the beatings?


Don’t you want your change sir?

Let me ask you a few simple questions. Do you have a favourite tipple?

Why is it your favourite?

Was it always your favourite?

What was your previous favourite?

What made you change?

If you tried your current favourite sooner, would you have had more enjoyment out of life?

Do you think it is likely that one day you will try another drink and like it better?

Maybe you could apply this argument to your job, or hobby if this is more meaningful.

The thing most of get out of this little exercise is the realisation that we probably all miss out on a great deal by being adverse to trying new things until we find ourselves directly in their path and suddenly discover a new source of pleasure or value. The second point that generally emerges from this exercise is the realisation that we are all generally content with adequacy rather than in pursuit of excellence or optimisation of value or pleasure perceived.

Now let’s play for bigger stakes. Does your family have a favourite restaurant? Was this always the case?. How did you arrive at the consensus that this was you favourite restaurant? Are there one or two who don’t agree, but go along to keep the peace?

What would have to happen in order for you to adapt a new restaurant?

What would make you seek out a new one, who would instigate this and how would the decision get made
  I suspect that these simple questions woke a few skeletons in most household cupboards. Hopefully they also lead you to consider how your family deal with these issues. Does one person lay the law down and solve the issue?
  Do you talk it out until there is consensus?
  Do you give way to certain individuals who seem to have the knack of getting their own way?
  Or maybe there’s a close knit clique who stick together and dominate everything. How will you decide whether it was a good decision or whether to keep trying?
  What will make you settle for a new place?
  Fatigue? Lack of ideas? Adequacy? Excellence?

There are many potential ways forward, but that’s not as important as stopping to think about how a close knit organisation with trust and communication go about changing their behaviour in some small way.

Risk management, please not another session like that one, ever.

I just survived one of those mind numbing risk management sessions at a project board meeting.
As PM, I was expecting to handle this myself, but this particular project executive was determined to do it his way.
We’d just sat through nearly two hours of meandering discussion when it was announced. Last item (not even on the agenda) risk management.
We then went round the table of business stakeholders and interested parties and began to record all their thoughts, fears and imaginations and give them scores. At one time I definitely believe that we had two in hot contention for the title.
Eventually we wrapped it up and I asked my assistant to make sure that was all circulated so they could enjoy their handiwork.
Actually I had picked up a really important risk in there, if you encourage people with wild imaginations to get creative, you may never make it home, at least not sane.
Why do we do risk management?
We want to spot things on the horizon that are heading straight for us and figure out if we need to ignore it, take evasive action or prepare to absorb it and then to make someone responsible for watching it in case it becomes closer or more dangerous or both, or goes away.
It’s a bit like Indian scouts in the old westerns, a bit of recce saves much bullets and many scalps.
What is it we are after? And what is it we are not after?
Well mostly, we want to recognise real risks that are there, visible or discernable and with a real likelihood of occurring and causing us significant damage. If they are things that could become risks then they are shadows and should be ignored. “The horse that is wary lives long, but the one that dodges at shadows is eaten by his master.”
Who do we rely on for risk management?
This is one area where there is no substitute for experience. Only the battle hardened can tell the difference between risks and shadows and can really estimate likelihood and severity. When carrying out risk management it is critical to talk to the most experienced people you know, whether or not they are involved with your project and learn from their experience.
Don’t ask turkeys if Xmas is a good idea, as I have seen done in many a business change project, you know the answer you are going to get.
What information do you need?
1. A good unique memorable name so you can discuss it without confusion
2. A succinct and accurate description of what will happen if it comes to fruit
3. A measure of how likely it is to happen based on the current situation (today)
a. What will happen that will tell you the likelihood is increased
4. A measure of the impact it will have on you project (severity)
a. What will happen to tell you the likely impact has increased
5. Who is responsible for monitoring 3a and 4a and sounding the warning to you
6. At what score will this risk “go red “, the project is in critical danger and action is required.
7. What is the current action if any required .
8. Next review date, who is involved, what format.
9. Escalation procedure if it goes red
What should you do with this information?
Assign the risk to someone, but make everyone aware and ask them all to watch out for the signs
Put the review date in your diary.

Planning and comunication is the root of management stress

How long will it take?

Let’s start with scheduling. How long do you think it takes your average employee to handle email, chat to his/her colleagues, dip out for cigarettes, have lunch, wind up in the morning and wind down at night? 2 hours, 3 hours, 4 hours, 5 hours? Are you sure you want to know?

 I suggest you monitor this for your own purposes over a period of about a week.

Now have you allowed for the long drawn out meetings and the important ones called by you and have you allowed for timesheets and project meetings and the team meetings? And of course the stream of emails.

Are you sure you have not missed anything?

Be honest with yourself, how far out was your first stab at this in terms of percentages?

Privately, you should perhaps consider what your estimate might have been, had you not been primed for it by this blog.

Now ask yourself what effect this minor oversight might have had on a project involving ten people for nine months.

Are you feeling the stress already?

Are the stakeholders behind you?

OK, so we started at the easy end. Now let’s up the stakes a little.

Do you know who all your stakeholders are?

Are you confident that a new stakeholder won’t appear out of the woodwork and bring it all to a halt unexpectedly?

So you have a comprehensive list, are you absolutely certain that every one of them knows exactly what you are planning to do and what the impact will be for them.

Ok so you circulated an email. Can you be absolutely certain that they read it?

Be honest, you know they didn’t, now ask yourself this; do any of these people have the power to stop you, officially or not, if they decide that they don’t like what you are delivering?

We both know the answer to this and we both know that even if you had extracted signatures on paper documents it would not really make much difference. By now you probably don’t want to go to work tomorrow and frankly I don’t blame you.

Are your team with you on this?

So we have covered some very important ground, but there’s still some way to go. It may have crossed your mind that if you planned this project on a poor basis and you tasked ambitious, hardworking people with targets, which we now know are impossible, they are probably already struggling and keeping it from you.

Ask yourself this; what will have to happen before a team member lets me know that there is a problem? Will you still be in a position to resolve the issue at that point?

Ask yourself this; how much easier would it be if you had scouts out there watching out for potential problems and warning you

in advance of the risks so you could be prepared?

Are you sure everyone is expecting the same outcome form this?

Finally let me throw the big one at you. How will you know you are finished?

What will success look like?
Will your stakeholders know whether you have succeeded or not? 


Will you get a pat on the back if you do a good job?

Be honest with yourself here. Try to envisage the scenario where you are toasted by top management for a great job completed and you have a warm feeling inside. Now step back from this to visualise the things management saw that made them feel like this about your work.

Are you still with me and are you still feeling confident about the outcome?

If you don’t know what success looks like there’s not much hope for stakeholders is there?

If nobody knows what success will look like, you are in a lose/lose situation, should you not be considering a new employer or maybe a new career?
What about all the loyal people who put up with you through all of this and received not a word of recognition, how will you motivate them next time?  




Reblog this post [with Zemanta]

Management is about common sense, methodology is just a reminder

p class=”MsoNormal” style=”margin: 0cm 0cm 0pt;”>“So you don’t know what you want and you’ll be upset if you don’t get it. OK I’ll do my best?”

Where to sir?

Every journey begins with a vision of where the destination is. Sometimes you just have a good idea and expect to do a little exploration along the way, sort of watching for the signs, but without a very strong indication of where it is. Your’re runing a few extra risks here, you need to know when to recognise that you are lost and cut your losses. You do have an exit strategy I hope.

How long do you expect it will take driver?

Once you have a good definition of where the destination is you need a strong indication of what the journey is going to be like, how long it might take, whether it is dangerous, if you will need public transport and how you will recognise your destination when you arrive. If you assume that you can cover say 300 miles a day but you find out later that every city and bridge takes several hours to pass through, you may run out of food or fuel and the best thing to do is put your feet up and cancel the trip.

Speka the english por favor

Then of course there’s a different culture to contend with both on the journey and on arrival. Can I speak the language? Will they understand mine? Will I be able to find my way around? Will I be safe? Where will I get all the new skills from and will I be comfortable with this new experience?

Of course your future livelihood may depend on making this trip, what will you do then? Well here are a few suggestions:

  1. Find someone who’s been there and ask them to give you clear instructions so that you know exactly what to expect and are confident that it is where you want to go.
  2. Find someone who knows the way and ask them to travel with you.
  3. Find a service which will take you there safely all in one go and drop you in the city centre.

In everyday life we have little problem understanding these simple dilemmas and making the right choices. It is really easy to see how these issues interlink and the importance of getting it right. We weave different combinations of all these strategies with consummate ease on a day to day basis because we are seasoned and sophisticated travellers, children of the low-cost revolution, broadband and the set-top box.

Some of our friends and neighbours left far flung lands in difficult circumstances and completed journeys like this with spectacular success. Why then do some of the smartest people in government and business fail so miserably to plan simple journeys in business, neglect to identify their aims and requirements, fail to plan sensibly, ignore the risks and shy away from help lest they look weak or go over budget?

Yes you read it right, poor planning and failure to seek help is usually blamed on wanting to save money.

When is a business case not a business case?

Read part one   part two Read part three  Read part four

  1. When it establishes that there is no case for the proposed initiative.
  2. When it fails to identify and present the benefits of the propsal sufficiently well to win support.
    Both of these situations have the same result only the second one is a lost opportunity for the business.
    A process for deveoping the business case for IT change

You can talk to five different people who have that word in their CV and each one will probably have a different take on what a business case is for, who should prepare it and what it should contain.
In fact, you could say that  the whole science around business cases, especially those involving IT investment has moved on substantially in the past two or three years.

Many of the concept of benefits were rarely discussed ten years ago, let alone benefits realisation.  Today all that has changed. Some examples of the importance this subject has achieved is the Cranfield university  Benefits Dependency Network Tool  and more recently the Microsoft REJ framework.
Here is a simple explanation that takes into account more recent developments in thinking and puts a simple framework around what a business case is and is not.
1. A business case must live up to billing and make a case for the proposed project. That means demonstrating how the project will deliver benefits for the business
2. A business case should take three forms,
a. Initially it should be an outline business case. This is a non detailed and very tacit explanation of why some very knowledgeable stakeholders feel that this is a very good idea.
b. A full blown business case with detailed cost benefit analysis and detailed financial calculations such as ROI, EVA, IRR,NPV etc
c. A one page summary of the final business case for people with little time for detail.
3. A business case must take a analytic view and not be an excuse to purchase my new toy, hence it should examine tactical solutions and doing nothing.
4. A business case should take into account political ,economic, sociologic and technologic trends likely to impact on the projects ability to deliver
5. It should take account of the organisations ability to deliver the project and realise the benefits.
6. The business case should always be a living document that is carefully managed by someone who carries a key responsibility for the project.

The diagram above shows a simple process for producing and managing a business case.
The top section represents the activities that generally occur prior to going into the implementation phase of the project .
The bottom section represents the activities that continue during and after implementation.
The first priority is to expand a little on the initial concept and capture high level requirements.   In dong this it will be key to get an understanding of the benefits hoped for by stakeholders and to abstract form them the knowledge and experience that has lead them to this conclusion and the assumptions that are underpinning it.
Next a high level examination of the potential solutions, include the ones that are likely to be already suggested, a do nothing scenario and a tactical solution.
From here an outline business case can quickly be created that encapsulates all the motivations, expectations and tacit understanding of the problem and potential solutions and provides a building block for stakeholder mapping.
In the next instalment we will look at some of my favourite tools for helping to create a business case that serves it’s purpose.

Read part one   part two Read part three  Read part four


Reblog this post [with Zemanta]

Return of the OMLB prepare for the Rescuing Angel

The power struggle rumbles on.

Am I hitting an unlucky patch, or is there an epidemic out there. Two projects in succession that I have been involved with at two large organisations have suffered the same problems. It goes something like this.

The organisation has a large IT department and like all large IT departments it has a fairly rigid set of processes and constraints. These were put in place some years ago by a rescuing angel who untangled the glutinous mess they had created and explained that now things are running again, to keep things running they need a few rules and processes.

Bit by bit over a few years, two things happened simultaneously;
1. The IT department began to abuse the rules a bit in order to wield their newly discovered power and slowly, but surely the tail began to wag the dog.

2. Certain people in the business, the ones most responsible for creating the mess, became increasingly irate at not being able to buy toys at will and play with them without having to explain themselves. A career based on the “One eyed man in the land of the blind” (OMLB) strategy had suddenly found itself on rocky ground and they disliked having to discuss these things with people that understood the manual and could ask awkward questions.

The upshot of all this was that IT shot itself in the foot once again. Their rulebook waving and power broking created the perfect opportunity for the OMLB to retake the high ground.

Now you have the situation whereby the OMLB has a new title like Business Project Manager or Business Change Manager and instead of representing the needs and responsibilities of the business in IT projects, he rules every IT project totally.
He has banned business analysts, they are too technical and he doesn’t understand their UML and work flows so he has a junior creating squiggles on Powerpoint slides. He has alienated the IT project manager and he has a supplier who is his trusted adviser and uses the OMLB as a blunt instrument to batter IT into providing them everything they need.

Testing, Change control, detailed requirements and all the other tools that help reduce the risks are viewed by the OMLB as IT placing barriers in his path and he has regular ranting sessions in the canteen with others of his calling where they bemoan the constant battle with IT.

The IT project manager manages nothing, in fact in many cases the recruitment is done very deliberately to hire somebody with no formal or other IT training, he just attends meetings with a gant chart and ticks off what is completed and he has a full set of Prince 2 documentation that often bears little relationship to the project and will never be read by anybody. He is kept well out of things other than to warn him of when he must be ready to run the application. When things go wrong of course that ‘s where the IT project manager comes in, it will be his fault.

Just to make this muddle even more confusing and hopeless, the IT Project manager reports to a matrix manager in charge of Project managers, who knows and cares nothing about any projects.
There is a PMO and they have a planner who actually manages the gants and updates a master program plan. He knows nothing about IT projects, just gants. There’s a Matrix manager for Business analysis too, but he also keeps well below the parapet.
Success for each of these so called managers is a green light or a tick in a box in a map of a journey that has no known beginning, middle, end or real purpose, It just has a map.

It has a few guide books, but they are not reliable and nobody is interested in whether this system is really beneficial, whether it will do what it promises, whether it is the best way to deliver on requirements, if there are any.

In the background, behind all of this activity, there is a huge IT department struggling to support last years white elephant and the one from the previous years. There are several projects afoot, with new names and budgets of course, adding on the requirements that were missed out on previously implemented systems and fixing the ones that didn’t work. Doing it this way hides the abject failures and overruns

Duplication of systems and data stores is epidemic and burning money in vast amounts. The inside of the IT department is once again a bulging spaghetti bowl and the day for wringing hands, IT directors resigning, OMLBs retiring and the return of the rescuing angel is becoming ever closer.

When is the IT profession going to start behaving professionally? When is it going to start engaging senior managers in business language and becoming a trusted adviser instead of an enemy?