allan kelly

It is not often I feel sorry for EDS. Early in my career I had contact with EDS and I was not impressed. Since then nothing I have heard about them has caused me to change my opinion. So it is pretty unusual that I ever give them the benefit of the doubt, let alone feel sorry for them. But this time maybe I do…

Just at the moment EDS are being sued by BSkyB – part of News International – for failure to deliver on a project. In 2000 BSkyB agreed to pay EDS £48m to develop a new ‘state of the art’ customer service system. Unfortunately the project collapsed in 2003, BSkyB completed the project without EDS at a cost of £265m and are now suing them for £709m. The case is being covered by the FT if you want to know more.

Basically EDS claim that BSkyB didn’t know what it wanted. It seems the requirement was simply: a ‘state of the art’ customer service system to provide BSkyB competitive advantage over their competitors. BSkyB respond that EDS didn’t follow any recognisable project planning system.

I don’t know the rights and wrong of the case, what I do know is that businesses frequently don’t know what they want. I’ve written about this several times before (Software requirements and strategy and Requirements: A dialogue not a document for example). This case is about EDS and BSkyB so it is high profile but the same debate is acted out between thousands of IT providers and their customers every week. Because these names are less well know, and because these companies can’t afford to go to court we never heard about them and some agreement is reached.

This happens internally too. Companies with their own IT groups often get into this mess, the business can’t tell the IT people what they want. Perhaps it is because I’m in London but most of the stories I hear involve banks. Sometimes being part of the same company can help, and sometimes it makes things worse.

Rather than ask whose fault is it? we need to ask How can we fix it?

Well there are two parties here and both need to be involved.

The business side needs to set the overall goals – ‘build a state of the art customer service system to produce competitive advantage’. And the IT side – whether in house or outsourced – needs to implement what was asked for an no more. But in between there is a massive, massive, gap.

• What does a state of the art customer service system look like?
• What is competitive advantage in customer service?
• How do you avoid spending so much on ‘state of the art’ that you loose competitive advantage?

These aren’t easy questions to answer. Neither side can answer them alone and neither side can expect the other to answer them. You need co-operation, you need an on going dialogue.

Business needs to be able to articulate what it wants but it is wrong to think it can articulate everything up front. It can set goals but in achieving those goals there are thousands, indeed millions, of options and decisions to be made. The devil really is in the detail. Business and IT need to make choices together.

Making those decisions requires people in the role (business analysts or product managers), it requires IT people who understand business goals, it requires business people who understand how IT is created and how to recognise the benefits, and it requires a process to keep talking and making decisions.

In this case it is wrong to think BSkyB can just throw the problem ‘over the wall’ to EDS. And it is wrong of EDS to expect fully defined requirements documents up front. But, the nature of competitive business encourages people to take this approach.

I don’t know how EDS and BSkyB structured this project but here some advice:

• Start small: IT projects are often far too big, if you can find the real benefit it then stick to delivering just that, keep it small. Inside every large project is a small one struggling to get out.
• Requirements have to be driven by the customer, who needs to set business objectives and vision. However further elaboration needs to come from close collaboration between the business and the supplier.
• If you intend to build a ‘state of the art’ system, and gain competitive advantage then know your enemy, know what state of the art means and know what other systems do.

Finally, make sure you are building your ‘state of the art’ system for the right reason. Will a state of the art system really deliver competitive advantage? Maybe you don’t need ‘state of the art’, maybe you just need to use an ‘average’ system better. Maybe you don’t need to build a system at all, maybe you can just take one off the shelf. This won’t be cheap – especially if you have to customise it – but it will be a lot cheaper than starting from scratch.

As a PC user there was only one game in town for office software – Microsoft Office. Yes there was other software but very few people used it. Everyone used Word, Excel, etc. and if you used anything else people thought you were strange.Since moving to the Mac I’ve discovered the hegemony doesn’t exist here. I’ve discovered people who use NeoOffice and as Mark points out in his comment today there is Apple software too.

Funny thing is I first met Mark when we both worked for a company which produced UNIX based office automation software, Quadratron. In fact the company had made a good job of missing the PC market and realised it needed to catch up. Somehow Mark, Adrian, myself and a couple of others weren’t going to make it happen. Once it became clear the company had no future we jumped ship.

But now it appears the office automation market might be on the move again.

Yesterday I used the Google spreadsheet and word processor for the first time. In fact I was using them in collaboration mode with Till Schuemmer as we started the process or organising EuroPLoP 2008. They worked well – despite my very slow ADSL connection – and I was impressed. However shortly after we finished the ADSL connection collapsed again so while Google Apps might be the future they are not the present.

Also this week I learned that IBM is launching, or maybe re-launching, a office automation suite called Symphony. Lotus Symphony was an integrated office package in the days of 8Mhz 80286 CPUs with 640k RAM. It worked but not well enough too make much of a mark.

Why has IBM done this?
Will Google Apps (or ADSL) ever be stable enough to challenge desktop software?
Will NeoOffice or Apple displace Microsoft on the Mac?

I don’t know the answers to these questions but I do see the start of a change.

Back in April and May I discussed failure modes in Agile software development. Well I’ve found another. That is to say I’ve found another way in which an Agile development practise can go wrong. I’ve seen this before but I didn’t recognise it as a failure mode, I saw it as a little local difficulty now I’ve seen it a second time I understand it a bit better. The trouble with this failure is that at first it looks a lot like what should be happening.

One of the core ideas behind Lean and Agile is improving quality of code. Improving code quality enabled several other benefits. Improved quality means fewer bugs, so future development is less disrupted because there is less rework. Improve quality means less time spent in test at the end of a development. Thus short iterative cycles become possible. And improved quality means you can deliver (or just demo) any time. So quality improvement is important.

One way in which we seek to improve quality is through automated unit testing. This is usually undertaken as Test Driven Development or Test First Development. Now there is a whole host of reasons why it can be difficult but that is another blog. With automated unit tests fine grained functionality can be tested very rapidly which provides for rapid regression testing and increased confidence in new code.

This is where the failure comes in.

We actually want the tests to fail if we change something because they prevents errors slipping into the system. So we add a test for new code, write the new code and by the time we check the code it is finished and the test pass. But, if later something changes which will break the code then we want the test to fail in order to catch the error that has been introduced. In this case we want the test to be fragile so that it catches anything which is now wrong.

The problem occurs when the test is fragile in the wrong way. In the case I’ve just observed the test was fragile when data in the database changed. Previously when I saw this the tests were fragile around COM. The test was/is not sufficiently isolated from its environment.

True dyed-in-the-wool Agile/TDD practitioners will immediately jump to say: you shouldn’t do it that way. And they are right. These fragility points should be addressed. This might be by stubbing code out, using mock objects or by tearing-down and restoring some element – such as a database.

As a consequence instead of the tests helping you validate code and move faster they become a hindrance. The need to update and change the tests regularly adds to the work load and complexity. Instead of the test showing everything is good they add to the maintenance burden, the exact opposite of what was desired.

The problem is that those trying to take the Agile/TDD approach have good intentions by they don’t have the experience, but how do you get the experience without doing it?

Well there are three answers here: first the organization should have invested in training for these people. Second the organization could have hired someone with experience to help them, perhaps as a part-time coach or perhaps as a full time co-worker. And third, the management could have helped the teams learn faster and better and encouraged them to reflect more on what they were doing.

Trouble is Agile development is often introduced bottom up, so people do just jump in. And even where management introduce it then such training and coaching can be expensive – that is if you know who to call and where to buy it in the first place. (If you don’t know who to call then let me know, I know people who do this stuff.)

So although it is well intentioned and the ‘just jump in’ / ‘just do it’ approach can get you started but it can also start building up bigger problems further down the line. If you know what to look for you can spot the problems and – at least try to – take corrective action. If you don’t then it is quite likely you’ll give the whole Agile experiment a bad name,

I wish I had read Crossing the Chasm (Geoffrey Moore, 1999) sooner. Not only does it give some good advice to technology (specifically software) companies but it also explains a lot about the technology and software market place. I guess I’ve known the basic argument Crossing the Chasm makes so I’ve never felt compelled to read it until recently. However I’ve missing out on so much more.

The basic premise is that for any technology product the buyers can be divided into five types. Initially the product sells to Innovators, then Early Adopters. While these groups will buy the product early they are quite small. Many companies sell to these segments and it looks like success but they are only addressing a fraction of the potential market.

The challenge facing a technology company is to break out of these two groups and sell to the much bigger Early Majority and then the Late Majority. These groups are so much bigger they represent the big money. (There is also a small Laggard group bringing up the rear but this is another small market so its not worth bothering with.)

The problem facing companies is that selling to the Early Majority segment requires a different approach and different strategy to selling to the Innovators and Early Adopters. In fact, while selling to these two groups can be profitable continued success here can harm your attempt to break into the Early Majority. This is where the Chasm comes from. Moore says that the difference between the first two and the third group is a Chasm, it is absolutely massive.

What Moore does is explain this problem and sets out a solution to overcoming it. The solution will be familiar to anyone who has followed my arguments on product management. The argument is also familiar from a bunch of other books too. The familiarity of this argument can probably be traced back to Moore anyhow. And the solution is…

To decide who you want to be your customers. To understand their problems. To craft a product that directly addresses your customer problems. To designate yourself the market leader in the field and make you solution utterly compelling.

It might seem an odd idea to declare yourself the market leader but what Moore says is: find a niche with your customers, define the niche so that you are the only people in it, then the niche is yours. It doesn’t matter if the niche is small to start off with – in many ways the smaller the better. The trick is to win one niche, one vertical market, then move onto the next. Over time you roll up the markets one by one.

I’ve worked with many software technology companies and I’ve seen many of them try to do this. Some successfully, most less so. Some of them knew they were following Moore’s advice but I think most of them were following it by default; i.e. they find their product fills a niche but don’t set out to do that. In these cases the companies have trouble moving from one niche to the next.

The main problem I see with companies following Moore’s advice is the need to say No. To select and dominate a niche companies need to focus on this niche. Most companies find it impossible to say no to a potential sale. The company’s software can be used for many things, the idea of turning a potential sale down is just not possible. Consequently they end up being all things to all men. Sure they take the sale for good reason – its money – but the short term fix damages the long term strategy.

And there you go. There is the link. You need a strategy. You need your sales-force and your development efforts to follow the strategy. Not to sell outside the niche and to develop products with features which directly assess the niche. Once again this is the role of product management. You need someone to do this.

So, if you are in the tech business, and especially if you are trying to create a successful technology company read this book. It is well written and easy to read. It might not be the strategy you follow but you should at least understand it. If you don’t follow Moore’s strategy you should know why you are not and why your strategy is right for your company in your market.

A few weeks ago I wrote about the role of requirements in software development, and then I wrote about business strategy. What might not be obvious is that: in order to have product requirements you need to have a product strategy, and a product strategy needs to come from corporate strategy. If you lack either you might still go through the motions of developing software but it is unlikely that it will meet market or business needs, and it is unlikely you will have a successful product.This happens in all industries but is particularly important in software development because software products are usually the realisation of strategy, so:

1. In order to properly and coherently create a software product you need to have a product strategy. You need to know how the product is going to make you money.

2. In order to have a coherent product strategy you need a coherent corporate strategy. Because the product is the implementation of your corporate strategy.

It doesn’t matter much if your local shop lacks a strategy. People still come and buy things, the shelves are restocked and people get paid. But if you have no strategy for your software why would people buy it? What good does it do them?

You might sell a few copies but without further development the product will rot and sales will dry up. Bugs will become apparent, new operating systems will appear, new applications will emerge that you need to interface to and competitors will match your features. Fail to answer these issues and people will stop buying your software. Things change whether you want to or not. And they change much faster in the software industry than in the corner shop industry.

So you need to move your software forward, keep it fresh, release new versions. And that means you need requirements. But you can only create requirements if you know what your company is trying to do. Otherwise you will end up filling you software with a bunch of features which seem like a good idea to someone but don’t add up to a coherent package.

Now as I said before, it is not enough to have corporate strategy, or even a product strategy. You need to have one that can be communicated and understood by everyone. And you need to actually communicate it and keep on communicating it. Part of the way you communicate it is through product features and updates.

So, you need people who’s job it is to turn that strategy into product features. Those are the people who need to have the ongoing dialogue with customers, the market and developers. These people may be called Product Owners, Business Analysts or Product Managers, what ever, someone has to decide what is in the product and the code developers are not the right people.

Now the difficult bit. Too many companies don’t have a strategy, or they have one they cannot, or will not, communicate. They fail to employ the people who will turn that strategy into reality. So it looks like they are busy but the people doing the coding are directionless.

If you want to play the software business game then don’t leave home unless you have:

1. A strategy you understand
2. People who can make it a reality

To do anything else means you are heading for a software failure.

Unfortunately very few software development books, courses and methods address these issues but I am convinced these problems lie at the heart of many, maybe most, software development failures.

My last two blog entries, and some recent reading (I’ll write about it soon) have given me a lot of food for thought about business strategy and how it relates to software development. Fundamentally strategy is about knowing what you are doing, articulating what you are trying to do and using this understanding to drive what you do.

All companies have a strategy whether they realise it or not. I don’t expect many local shop owners spend their time thinking about strategy but they have one. For them strategy is mostly location, location, location. Open a shop in a good location and you will get trade. OK there is a little bit more to it, does the shop sell newspapers? fruit? ethnic foods? In the abstract these are issues of strategy but I expect each one is considered without the need to use the s-word.

This is what I think off as implicit strategy, these businesses have a strategy but it is not spoken about. This approach works – well it mostly works, provided little else changes they can carry on as it. However most of these business are small, one shop, maybe two. But, the more these business grows the greater the need to make the strategy explicit.

An explicit strategy is one that is stated and articulated. This means it can be shared and communicated. If you are going to expand beyond the ideas on the owner’s head then it is necessary to communicate so everyone can pursue the same aims.

Moving from implicit strategy to explicit strategy allows three things (at least) to happen:
• Strategy can be communicated and therefore shared so more people can be involved in the business
• Strategy can be analysed, therefore problems can be spotted and new opportunities can be found
• Strategy can be used to drive execution; so structures, processes and products can all be built to ensure the strategy is successful.

In other words strategy is about scale, it is about creating the conditions to grow.

Now we can return to software development… where exactly the same process happens occurs.

A programmer can have a great idea for a program, and like the shop owner, they can build it. They can stick it on the net and may even sell a few copies. As success grows they may want to hire more developers, thats where the software requires design, architecture and so on. Its about scaling. Once again it is about sharing the ideas and communicating them. It is about analysing the design, finding problems and creating the support infrastructure.

Just to be clear, I’ve said it before in other words: Software Design is equivalent to business strategy. It is about scaling up.

And as this software is success, and more programmers work on it money generation becomes more important. The first program sold because, like the local shop, it was in the right place at the right time, but to sell more copies, to pay for more programmers, you have to know what you are trying to do.

So the software is no longer just software, it is a business, and like all businesses it needs a strategy. And since this business is growing it needs to move from an implicit strategy to an explicit strategy – for all the reasons above and more. The software industry is highly competitive and international, things are always changing. If you don’t consider the changes, and how you will responded you won’t survive long.

Strategy matters more for software companies than to many others. This is because software, indeed all IT, is about change. You use IT (and therefore software) to create change. Either in your organisation or in your customers. You need to understand what kind of change you are creating, how you are creating it and why you are creating it. Organisations are in greatest need of strategy when change is in the air.

There are actually two strategy tracks in a software company, one embedded in the software design, and one stated as business strategy. The two are interlinked and can hinder each other. You cannot pursue a business strategy that your software architecture will not support, and you cannot expect a software design to work well if it runs against business strategy. We’re back to Conway’s Law but that is not my primary point here.

There are two problems I want to highlight. The first concerns strategy itself.

The trouble with strategy is that it is grand, it sounds grand and as the economist John Kay puts it strategy is a synonym for expensive. Consequently all too often strategy formulation becomes the work of ‘big brains’ in the company, or even outside consultants.

This excludes the bulk of the employees and this itself has two problems. First you miss out on their thinking and thus potentially miss out on new ideas and emergent strategies. Second once you have decided your strategy you need to communicate it. This isn’t trivial. Communicating a strategy means you have to be able to communicate it, then you need to actually communicate it, then you need to re-inforce the message and keep re-inforcing it. This takes time.

The second problem with strategy is that it doesn’t happen. Maybe we continue thinking like a small shop keeper: people keep buying our products so we don’t seen the need to rethink anything we do. Or perhaps we do rethink our strategy but perhaps we fail to communicate it. Perhaps only the ‘big brains’ know or understand the strategy.

And these problems are important when you are developing software. Because product requirements derive from the company strategy. If you don’t have a strategy, or you don’t have an strategy people know about and understand then you stand little chance of understanding what your software products should do.

I’m not a lover of requirements documentation. I’ve discussed this at length before – see Why Do Requirements Change? and The Documentation Myth. However requirements and even requirements documents do have a part to play in the development process. This fact has been brought home to me recently while working with ‘Requirements by Bullet Point’ and ‘Requirements by Project Name.’

These two conditions arise when people try to take short cuts with documentation. In the first case, Requirements by Bullet Point (RBBP), somebody lists ‘the obvious’ requirements, or the ‘things we all know’. In the second, Requirements by Project Name (RBPN), people come to believe the project name conveys all the requirements necessary, unfortunately, the same name tends to mean different things to different people.

What such requirements miss is that the devil is in the detail. Every line of code in a software product contains multiple decisions. A product with 10,000 lines of code contains millions of individual decisions. Some, many, of these decisions relate back to the requirements. When this information is not available the guys writing the code have to guess. When developers have to guess it is the business which suffers.

Agile development lends a whole new twist to the problem because it specifically sets out to deal with changing requirements. But some people believe this means you can start out with no requirements. In traditionally waterfall projects requirements came at the start so projects should not proceed without them. Thats the theory but in practice such projects also fall pray to RBBP or RBPN.

The problem isn’t helped by developers who believe requirements are not necessary, after all, developers know best. Occasionally this is true, normally it occurs with very technical products or where a developer is themselves an expert in the field. The danger is always that developers mistake what they want to do, or what they can do, with what needs doing. What needs doing (the requirements) always needs to be rooted in what the business or market wants and needs.

To make things worse requirements often play multiple roles in a project. Not only are they technical requirements but they are also part of a legal contract and a financial rewards (and penalties) system. When they are called on to fill these multiple roles things just get more complicated.

The problem is that requirements (and I extend this to include specifications here) are just plain difficult for all the reasons I outlined in Why Do Requirements Change? and The Documentation Myth and more.

I think the solution is to recognise that project requirements are an ongoing, evolving, entity. They are not written once and set in stone, they are a continuing process not an event. Or to put it another way, they are a Dialogue not a Document. And to have a dialogue you need multiple people. One of these people needs to be the owner of the requirements, these may be called the Product Manager, the Product Owner, a Manager or a Business Analyst.

The important point is there needs to be someone who is charged with having these dialogues and ensuring a consistent view emerges. Consistent doesn’t mean unchanging but it does mean it remains fairly stable and only changes when new facts or events emerge.

This person needs to be hold an ongoing dialogue with all the stake-holders: the customers, the end-users, the developers, the market, the wider organisation and even the software itself, by looking at it, evaluating it and looking at its competitors. Somebody needs to be charged with knowing what the product needs to be and articulating that view.

Requirements documents have a part to play too. The process of creating the document is an learning exercise for the product owner. In writing the document they are forced to research the subject and pull all their thoughts together in a logical order. For other people the document shows that somebody has done their due diligence and thought about the issues.

Unfortunately too many people in too many companies believe a static document, or RBBP, or RBPN or thought-transference is sufficient to get a software product created. Waterfall had it partly right in this respect, you need requirements to a project, you need to know what you are trying to do, but you need to constantly keep asking and re-asking that question and stating the answer.