Preparing to return to work

It has been a long break for me, and I have mixed feelings about what awaits me on my return to work. Most of the other staff also took the week off between Christmas and New Year (though Jiri did not). I am slightly embarrassed to admit that I always feel that I should invite Jiri round for Christmas lunch and never do. He is probably perfectly happy on his own.

There is the standard stuff that always appears when you have had a break. The stack of problems that people discover because they’re not really working but are exploring the software to have something to do. The new features that Gavin has invented while going on a long walk after an all-night party. The new contacts that David has made while playing golf on Boxing Day, and their suggestions for what is needed to penetrate new markets. The stale issues that people couldn’t deal with just before Christmas so they put on the pile to be dealt with after Christmas when they would feel more inspired and less jaded.

All the tinsel that draped the stairs and monitors has been put away. Jiri is very happy because he managed to get an enormous amount done while the office was empty. The cleaners haven’t been in over the new year so his desk is festooned with crumbs and empty packets of Czech festive items. Jack isn’t back yet – he’s gone ski-ing with his girlfriend. Mr Grumpy is in, and he is delighted to be back at work. For someone who complains so much, he seems to enjoy life far more than most of the people I know.

I promised that I would provide a systems analysis of the company and I am just considering how to do it. Like most small companies, it consists of a series of departments, each run by a manager. Departments contain some specialised staff and some people who have ended up there and learnt on the job. In a good company, the departments will be work-shaped. That is, a department has a function to perform and its staff and systems enable it to carry out the function within the department. That’s easy if it’s a closed function, but speaking from experience, every function will require (at the very least) information from the rest of the company.

For example, marketing has a big marketing push to carry out in the new year – get customers before the end of the tax year in April, when they’re likely to have some extra budget to spend. Marketing need to know all the stuff about customers patterns of purchase (which is their own skill) and they need to feed that back into the company. They also need to know what the company is producing that they can sell in the new year. How do they do that? Do they get the over-optimistic views of GandD, or do they get the more realistic views of Ian? Do they have to come and chase and check whether what they have been told is true, or will the right information be passed on at the regular meetings? Have they got the experience to discount GandD’s over-optimism, and if so, how do they know which bits to discount? This is not something that can be codified, because the (say) 30% of stuff to discount will change each time? This is skill, but to be able to learn the skill, you have to know what goes in and what goes out. You have to know at what point the product starts to stabilise and you have real information to deal with. And from that, you have to find out what customers want and feed that back into development.

So marketing has several roles:
1. To sell stuff to customers (this is how it’s seen within the company, anyway)
2. To understand what the company produces and when it will be ready
2. To understand what customers need and when they buy it (that’s their own skill that enables them to do their job)
3. To tell the company what customers need and when they buy it
4. To create a trustworthy competent public image for the company

Now Jeanette is fabulous at selling. She’s pretty good at knowing what the company produces and how much of GandD to ignore. And when to ask them what is actually happening. And when to tell them stuff is a waste of time. But I’m not sure how much all of her knowledge about customers – why they buy, and even more importantly, why they don’t buy, filters back into the company. Should it? Can Jeanette’s sense of what people want be as important as what David picks up on the golf course?

Failure demand and value demand

Today’s lesson is not about how long it takes to drive to Newquay and why it rains when I am driving but not when my partner is. That would be yesterday’s lesson (and that would explain why I didn’t post yesterday). The surf was quite impressive in Newquay. As always, I wish that I’d gone down into it rather than stayed up on Pentire Point with the wind trying and failing to get me off my feet and face-first into the gloopy mud.

Today’s lesson is from John Seddon, and it’s about what work is worth doing. He splits the work people have to do into value-demand and failure-demand. Value-demand is when your customers/clients/ citizens ask you to do something for them that you want.
Failure-demand is when your c/c/cs ask you to fix something for them that they didn’t want.
So, selling someone a piece of software that does the job they want is a value-demand. Responding to a support call is a failure-demand.
Registering their details, is that a failure-demand or a value-demand? I think it’s a failure-demand. Most customers don’t want to fill out their details unless they can see the point. Yes, they’re happy to provide a delivery address, that enables you to give them something they want. They may or may not be happy to register the software, depending whether they can see the benefit. They want to provide the minimum of information to do so. I.e, if you hang your marketing questionnaire on the registration document, they want want to complete it. And every time they make a mistake filling out a form and you ask them for more information, that’s a failure demand. You’re not asking them to fix their problem, you’re asking them to fix your problem.

Back in the days when I used to train people in using software, we used to provide a questionnaire so that people could comment on the training. At the end of it was a comment box, asking people what sort of training they would like. Some people wanted online training that they could access as and when they wanted. Some people wanted a member of staff to come and sit with them and help them through the problem. They didn’t want training, they wanted a good fairy.

There is a question. If someone wants help are they asking:
1. Please can you make this problem go away (that’s a failure-demand)
2. Please can you show me what to do in this situation (that’s a value-demand)

Many of our current problems are because people are in situations that they don’t want to be in in the first place. The usability problem is how do you design things so that they help people not to be in the problem in the first place?

Sometimes that’s done by changing the product’s interface. Sometimes it’s done by changing its function. And sometimes it’s done by changing its marketplace. The water pouring down on the West of England this December would be highly desirable in other circumstances. Unfortunately, the only desirable aspect I can think of at the moment involves a steep slope and a mud-slide (followed by a bath, a fire, and a lot of washing).