It was the best of service and the worst of service.

This blog has a Dickensian feel to it. The reason is that the lessons discussed are nearly as old as Dickens and its a bit long winded. Many, many years ago I saw a Tom Peters video where he talk about customer service. He said that companies paid small fortunes to create the right image but it was the sweaty delivery man in a nylon uniform who really represented you what you were about. He said that every customer who had a good experience with your company would, on average, tell one other person. A person who had a bad experience would tell ten. That was before the internet and twitter. On Saturday I experienced bad service from Monarch Airlines and within minutes I had told over 500 people about it.

On Saturday afternoon, about thirty minutes before we boarded our flight to Majorca, we were told that we would be subject to a five hour delay. The reason given was that another plane had failed and our plane had been given to the other passengers as their destination airport closed at a certain time. These things happen. When airlines are operating on razor thin margins, none can afford the luxury to have aircraft hanging around just in case. As a traveller, you expect the odd delay. However, instead of arriving for last orders we were looking to arrive at 5am, just before we would wake up normally.

Having told us of the delay, the Monarch supervisor told us to go to the information desk in the main terminal to pick up our £5 voucher from the information deak in the main terminal.The information desk would be able to answer all our questions.

People did some quick math. So we wont get there until two in the morning? “What about my hotel?” “What about my car hire?” “What about my bus?” “What about my friends?” . At this point the supervisor let us know how important she was. “Look, this is one flight. I have many flights to look after. The information desk will answer all your questions.”

Now you might think this was delivered in a way we could all hear. An announcement perhaps? Nope. Each group had to send someone to listen to the increasingly exasperated supervisor send us away.

I used my mobile to call our car hire company and hotel. I like to use my mobile phone to call foreign countries. The car hire and hotel said they would wait for us.

We went to the information desk to find out what was happening. They did not know. He rang Monarch Rachel to find out. He was none the wiser as well. So Monarch had lied to us to get us to go to the information desk and were now hiding. As we stood in a half empty airport with a third the normal number of passengers I’ve normally seen we were told it was the busiest day of the year.

Our flight. the 228 to Palma was due to leave at 5.30 and had been rescheduled to 22.45. The 224 at 8.30 was also delayed to 9.30 for the same reason which did not make sense. We considered trying to get the last two places on the 224.

Given the long wait we decided to delay eating until later as a means of killing time. We visited all the restaurants and chose the one that looked the nicest. I noticed that the flight time on the monitor had changed to 19.10 and went to the information desk to find out more. Apart from the last sixteen to book in, we were all to board a smaller plane. The gentleman next to me was one of the sixteen. “I’ve travelled from up North and got stuck in a jam on the M25.”.  He was travelling in a family group of seven. We hurried to the plane and grabbed a sandwich on the way with our £5 voucher. We grumbled to the man next to us about not having the chance to eat. He was a diabetic and even less impressed. The flight crew loaded the plane starting at the back but forgot that some people would not have a seat due to the smaller plane. Confusion ensued with some people sitting where they were not meant to. We set off and the flight was thirty minutes faster than expected.

On Monday morning @Monarch followed me on twitter.

On Tuesday @Monarch asked me to contact DM them.

On Tuesday we recieved a letter of apology.

I am emailing to offer our apologies for the late departure of your recent flight with Monarch.

I can assure you that it is never our intention to cause a delay and we do our upmost to operate on time departures. Regrettably, situations can develop but we always take immediate action to try and recover as quickly as possible.

I am aware of how disruptive delays can be for passengers. I would like to assure you that we really do value your custom and I sincerely hope that you will choose to travel with us again in order that you can enjoy our normal standard of service.

Kind regards,

Monarch Customer Relations Team

NB: This is an automated e-mail. Please do not reply.

I love the last line myself. This is not a conversation. I also love “…in order that you can enjoy our normal standard of service.”

So Monarch, here is some free consultancy. If you want more advise, I suggest you ask Bob Marshall, Grant Rule or Karl Scotland for help.

1. This IS your normal service. The 21st century traveller understands that things go wrong. Its how you deal with it that matters. As a company you have been running for decades and I am guessing this is not the first time this has happened. Learn from it and improve… or die from a thousand twitter cuts.

2. Never let operational staff deliver bad news to customers. You should get marketing or customer relations staff to do that. One of your customers may have a following of 20,000 and you just wont know it.

3. Understand your customer’s value stream. My travelling value stream ends when I get to my hotel. Your part of it ends when I collect my bag at Palma airport. Understand that you have disrupted it and aim to help them as much as you can. This is easier than you realise and cheaper. Get the gate staff to tell people to ring your sales number on a priority help line to alay fears about car hire, hotels, tour operators, buses. They can then ring them back to let them know everything is OK.

4. COMMUNICATE! The gate staff used a tannoy that would have embarressed even British Rail in the 1980’s. Get a few white boards to write up important information. Simply changing the time on the board is not enough as it can cause delays. Rethink how you communicate with customers when there is a delay (Jamies hand out pagers to people waiting for a table).

5. Use Real Options to work out how to reschedule your flights to minimise costs AND within a constraint of no delays past a certain time. Practice and learn how to do it fast. Then communicate the changes to all your staff.

6. Go and sit in Atlanta or Chicago O’Hare airport and study how they get people to take a later flight. They offer free flights and cash incentives. People like it when they get the opportunity to get bumped. Charge it to marketing. You chose to condemn a family of seven ( two adults, three children, two seniors?) to an extra early hours arrival.

7. If you cannot handle the peak in service agent demand, go study how SWA/NWA handle it with “Home Staff”.

8. Train your staff in the fastest way to load an airplane. Oh and by the way, as a parent, I would rather minimise the time I spend on a plane with my children. As long as I have seats together I would rather let the adults who have more patience load first.

9. Having staff following people in Twitter is failure demand. Check out John Seddon’s “Freedom from Command & Control.”

10. Never let your staff speak anything but total truth. Never let them hide. If they do not know, tell them to say they do not know. What they think is inconvenient is nothing compared to the misery your customers will experience.

Finally, the flight was pleasant. Your staff were pleasant, even the self important gate supervisor. The only problem is that you fail to understand that when something goes wrong, it is your normal service! And it was the worst of service.

Last night we went to a lovely port on the coast. The restaurant we wanted to eat at was full.The maitre’d asked us where we were from. An hour’s drive away. We walked off down the promenade. Five minutes later the maitre’d caught up with us. He had run down the promenade to tell us he had squeezed an extra table in for us.

That is the best of service.

Two weeks ago Naked Juice (part of Pepsi) hired a Wave Machine to promote their new range of healthy drinks. All week, the fittest and finest of the banks surrounding Broadgate Circus queued up to have a go. The Finance department had booked a place and on Friday I was asked to replace someone at the last minute. How would a fat and unhealthy middle aged guy compare to all these uber fit runners and cyclists?

Each 45 minute session consisted of two groups of four. The session was split into three parts. Part one was a training session on a body board. Each person got a minute and a half with an instructor who shouted out instructions on how to do ever harder tricks. Part two was a training session on a wave board, akin to a skate board but without wheels. Simply standing up for five seconds was the goal. Part three was a competition where each person tried to do as many tricks as possible.

Richard, a colleague who is keen photographer, came to take photos. Lots of fit looking people and a middle aged guy whose wetsuit made sure everyone knew he was widest in the middle. Richard told me that I had provided the audience with lots of amusement during the wave board training. The fit guys strode confidently to the wave board and stood tall for a fraction of a second before falling off. The fat middle aged guy huffed and puffed and stood shaking on the board. He knees were buckling under the strain of simply standing up, never mind standing up on a wave board. He wobbled and flailed around but he stood up. According to my colleague, the crowd thought it hilarious. After about a minute, I gave up and fell off trying to do some trick.  I was exhausted.

During the competition, all the competitors gave it their all. The fat guy with the lower centre of gravity did a few more tricks than the others…. It nearly killed me, especially when I dove from the top into the wave rather than carefully enter like the others. My team scored 350 points, enough to beat the other team. When I got back to the office I checked the score board for the week. The current top score was 320. On Monday, Naked Juice announced the official results. My team won the week long competition.

The team with the fat middle aged guy beat all the others composed of super fit concept II addicts.

Why is this interesting?

We all make assumptions. Sometimes the assumptions are so subtle that we do not even realise we are making assumptions. They are the really dangerous as we end up following the wrong people. We look for the wrong stuff and do not even realise what the right stuff is.

In the case of a competition which consists of three minutes of wave boarding and body boarding, the key ability is balance and NOT fitness. However, most of the audience assumed that the key ability was fitness or stamina. Those funny movement made by the fat guy were balancing movements. He knew what balanced felt like and moved accordingly. The crowd had not seen someone balance before and thought it was funny. Think about that. The crowd thought the most competent person in the activity looked funny because they did not look like they assumed someone would look like doing the activity. Have you ever seen someone balancing on a stationary bicycle or unicycle? Are they still or do they wiggle about. Someone on a moving bicycle or unicycle is much more stable. And so it is on a wave board.

Even though I was not fit. Even though I carried more than a few extra pounds. I had the benefit of experience due to my other interests and hobbies, namely Windsurfing, Wake boarding, Snow boarding, Skiing, and Tai Chi. All sports that require balance, and improve your balance.

The same is true of managing projects and what people assume to be the right skills. People are hired to be managers because they are confident or commanding in style. However, a competant risk manager may need differents skills and abilities. If they are managing risk rather than their image, they may appear funny to those with an uninformed mindset. Their behaviour may different to what you expect. they may become friendly with their team rather than command total obedience. They might back down in the face of a superior argument. Look at the results, not the behaviour.

The next time someone achieves results but in a way that seems funny, ask yourself “Have I made the wrong assumption about how that needs to be done”.

Remember the winner is the one who stays standing on the wave board, not the one who looks cool just before they get on it.

Willy Loman* was a man with an option. He knew that whenever he needed a job, all he had to do was ask and he’d get one… except this salesman had it wrong. He did not have an option. Although he had been offered that job, it did not really exist. The option wasn’t real.

People are very generous when they do not have to deliver. They will promise great things when they do not need to deliver. Being generous makes us appear magnanamous or larger than we really are. Being generous makes us look good.

I have been in meetings where IT is generous with it’s services. However, they have failed to deliver as they promised.

The first advice to the business investor is simple. Test your options. Excercise some of them. See how they perform. The IT resources may exist in the budget but getting them deployed to your investment may result in unfortunate delay. You will discover how the process really works rather than how IT tell you it works.

The second advice to business investor is just as simple. Keep testing them on a regular basis. This change ALL the while. Some for the better, some for the worse. Something introduced to make one investor’s life better make make things worse for other investors.

Don’t fall into the same trap Willy Loman fell into. Don’t test your option for the first time when you really really need it.

Willy Loman is the salesman in “Death of a Salesman” by Arthur Miller.

“When the gods wish to punish us, they answer our prayers.” (Oscar Wilde, An Ideal Husband)

When we think about rewards, most people think about pay rise or salary. Anyone who has encountered dog training* will know that the most important form of reward is praise and attention.

People are like dogs when it comes to rewards. Praise and attention are more important than pay rises and bonuses when it comes to changing behaviour. We all crave the praise and attention of those that are important to us. Our bosses are clearly important to our careers.

When a serious problem occurs on the system, our management will pay attention and we will be in the spotlight whilst we fix the problem. We get to show our best work whilst in a crisis. At the end we get praise. At the end of the year, management has lots of examples of good behaviour for the review process.

When we create a system that does not have serious problems, our management forget we exist. At the end of the year, management has hardly anything to say at the review process.

Can anyone see the problem?

* Inspired by Jerry Weinberg’s Keynote at the Agile Development Conference in Salt Lake City.

Heroes are great. They often form the backbone of the team. They wade into fixing problems at any time of the day or night. They often are the only people who know the nitty gritty details of how a system work.

They are also a significant risk to the project simply because the do so much and know so much.

When a hero leaves a system they often leave a big hole that is hard to fill.

So what is the main risk associated with a hero? The risk is that they leave and the system struggles to recover the lost knowledge and experience.

This can be for a number of reasons.

• The hero becomes ill.
• The hero decides to leave.
• The hero meets a partner who does not like the way work dominates their life.

The key thing about a hero is that they are not the problem. They are a symptom of the problem. The real problem is likely to be…

• A culture that rewards heroic behaviour rather than discourages it.
• As culture that rewards individual efforts rather than team efforts.
• A system that creates lots of opportunities for heroism.
• An understaffed department (The understaffed department may have lots of staff but only a few experts who know the system).

The Dragon Slayer only exists because there are Dragons. Without Dragons, the Dragon Slayer is simply a guy in a silly costume. They will soon stop wearing the armour and carrying the sword when there are no more Dragons.

Einstein apparently said. “Everything should be as simple as possible, but not simpler”.

He would probably have said “Never use a tool you do not understand”.

From experience, most stories I’ve seen use the “As a… I want…” format with “So that…” added to improve their appeal to business investors. A bit like lip stick on a pig.

Consider these “So that” examples from a super duper tip top team I know…

• “So that I can start using the system”
• “So that I can cover my arse”
• “So that there is less risk to manual error”

The problem with “As a… I want” format is that business value is an afterthought. However, it is a dangerous after thought. Seeing it there leads the business to think that some thought has been put into value when the reality is it has not been.

A subtle but more insidious problem with the format is that the user is the starting point. This means that the target solution starts by assuming certain roles will perform certain functions. Often a project will result in responsibilities being re-distributed to different roles. This situation needs to be handled with care and delicacy. By stating who will perform which roles, you may be signalling to a user group that they are losing or gaining new responsibilities… both of which may be unpopular.

Although I do not use the formats, I prefer “In order to… As a… I need” which places business value up front as the primary concern. Check out Antony Marcano’s blog post for more detail.

Currently the best way I know to develop software is to grow it using TDD and Mocks*. Even if your team uses TDD and Mocks, there is a still a risk of you building legacy code.

The quickest and easiest way to build legacy code is to have a team of smart developers who write code that is smarter than the people that will inherit it.

Some organisations like banks have a standing army of “smart” developers. Other organisations do not have a standing army and need to bring in consultancies to build any strategic system. In doing so they may be building instant legacy applications as the consultancies will be building an application that is “smarter” than the developers who will be supporting it. The consultants may use thought processes and techniques that the team supporting the application are not familiar with.

This leads to the risk of legacy code that cannot be supported or changed. Parts of the application will become no-go zones that are coded around. Solid lumps of gristle in the application. Tests will break and go red but no one will care. All of this will lead to code that is hard to change, slow to change and subject to regression.

As you build an application, you need to build the team that will support it. Invest in the team as well as the software.

I’m sure others can share examples of how they do this.

* Check out Steve and Nat’s book on growing code guided by tests.

When developing an IT solution, there is always the risk that a new requirement will break the architecture. That a new requirement will need a significant change to the way the system is designed. The system re-design will take significant time and introduce significant delay. The business investor will be kept waiting for their new BVI which includes the significant change.

There are a number of architectural principles that can be followed to reduce this risk of significant system change.

However, as an architectural principle, when choosing an architecture for the solution, consider the cost of changing from one to another.

Imagine you have a choice between two architectures. They are similar and are both candidates. One can easily and cheaply replaced be by the other. The other cannot be changed easily and the cost of replacement is high. All ealse being equal, chose the architecture that is easier to change.

It may be necessary to create some additional functionality to lower the cost of change.

Consider you are building a web-site for a new business. You have the choice of implementing persistance using a flat file or an Oracle database. The flat file is cheaper and would be ideal if the volumes stay low whereas the Oracle database would be needed if the volumes grew significantly. The ideal solution would be to start with the flat file and then migrate to the database if and when it is needed. In order to do this, the team will need to build a persistance layer to isolate the business logic of the system from the persistance mechanism. Interaction with the persistance mechanism would then be through an explicitly defined interface. Changes to the persistance mechanism would then be isolated from the business logic. The additional cost of the persistance layer should be thought of as an option to enable the cheap and easy change of persistance mechnism.

The application of this approach leads to high cohesion and loose coupling.

The general rule of architecture should be to avoid commitments in the design.