British Gas sues Accenture!

British Gas is suing Accenture. Accenture put in place a SAP based system which led to massive complaints against the gas supplier. It turns out that Centrica, British Gas parent, wrote off about 300 million dollars following errors with the system.

British Gas is seeking a multi-million pound damage for the installation of the billing system, which, “caused huge disruption” for the company and its customers. British Gas claims the billing system was riddled with “millions of errors.” Accenture is claiming this is “inaccurate” because it was probably on one million errors not millions, but who is counting.

A preliminary appeal brought by Accenture against British Gas was tossed out by an English judge. “British Gas is now one step closer to holding Accenture to account for the disruption caused to our customers.”

This lawsuit is paving the way for other “users” to sue its outsourced IT development.


Simple Solutions

One of the hardest things to do is to discover the simplest solution to a problem.  To often software developers come up with the most complex solution instead of the simplest one.

The simplest solution is the solution with the least amount of functionality to solve the problem.   This makes the solution simple to design, simple to code, and simple to test too.   Another advantage of simple solutions it is easy to document and communicate.

What is the purpose of Software?

My friend Grant Rule posted an interesting question on LinkedIn. He asked, “What is the purpose of software?” To me the answer is obvious and the purpose of software is to solve problems. Too many software applications are being built without a clear problem to solve. Too many in the field of software development focus on what the technology can do.

Let me make an analogy for you. I travel a lot internationally and I went to my bank (Bank of America) and asked for a line of credit. The banker said,” of course we can give you a line of credit” and then she asked, “what problem you are trying to solve?” I explained that I travel a lot international and run up large expenses. The problem, in my mind, was the time between when I was paid by a client and I had to pay my credit card bills. The solution, in my mind, was a line of credit. Notice I had the problem and solution well in my mind. Then said asked me if she could offer a potential solution. She suggested, “Why don’t you ask your clients for a percentage upfront to cover your expenses?” It turns out I did not need a line of credit at all. I have taken her advice and it has worked well.

To many “customers” of software applications do not know what problem they are trying to solve and therefore cannot offer a solution. Tom Kelly (The Art of Innovation) points out too customers do not have the ability to articulate what is wrong and especially what is missing. So if the purpose of software is to solve customer problems, and customers cannot articulate what is wrong and what is missing, then exactly who is suppose to articulate the problem and potential solution?

Hide Complexity!

If your mind is empty, it is always ready for anything.  In the beginner’s mind there are many possibilities; in the expert’s there are few. 
- Shunryu Suzuki – roshi (1905 – 1971)

When developing software intended for human interaction (the user interface), there needs to an effort to hide complexity.   In sharing his ideas on complexity, John Maeda writes, “Hide complexity through brute force methods.  A classical example of this technique is the Swiss army knife.  Only the tool you wish to use is exposed.”

When developing software there is a tendency to expose all the complexity and put it right in front of the person interacting with the software. Too often there is a feeling that all the features need to be exposed, so to demonstrate all the hard work that went into developing the product.   Like the Swiss army knife software features need to be exposed only when they are needed.  In other words all the functionality is hidden away until needed.

When all the functionality is in the face of the user, screens become cluttered and it becomes difficult to navigate through all the functionality.  Often a software developer has a sense if they do not expose the functionality the user will never find it and it will never be used.  Instead they need to hide the functionality, expose it at the right moment, and the design needs to be intuitive.

The problem is that intuitive design is very difficult to do and requires the designer to understand how the software application is going to be used.

John Maeda blog (website)

Read more at Reboot! Rethinking and Restarting Software Development.

Published in: on September 22, 2009 at 01:01  Leave a Comment  
Tags: ,

Gather and communicating requirements using video

One of the best techniques I have seen for gathering and communicating requirements is video.  The customer is video taped discussing and actually working.    The team gathering requirements politely probes and the customer is asked open ended questions.  The problem gathering requirements is the customer often does not know what they want.  What they can tell you is how they currently do their jobs.

The reason why most IT organizations do not use video is because they do not have the skill set to video tape and to edit. It is as simple as that.

Read more at Reboot! Rethinking and Restarting Software Development.

Published in: on August 14, 2009 at 12:18  Leave a Comment  

Mistakes in gathering requirements.

The worst possible way for the software requirements process is to have customers write up requirements and toss them over some imaginary wall.  The software development team works on the project for months and then shows up with a semi-completed project during acceptance testing.  Of course, the software is missing functions and does not work as desired by the client.  The problem is not that the business problem and solution changed during this time;  the problem is the business problem and solution were never defined.

Another common practice is sitting in a conference room with a customer and asking, “What do you want?”  Sitting in a conference room asking questions may not be a useful way to gather requirements, and it certainly should not be the only way.  This has nothing to do with how smart  or how good you are at asking questions.   Some developers will code what they thought the customer said and then show it to the customer.  This is commonly known as a code/test iteration.  A logical question is, “Why does it take so many code/test iterations to determine what a customer wants?” What were the reasons the developer and customer did not get it right in one or two tries (iterations)?  While this method is known as code/test, it is really a trial and error method to gather requirements.  The problem with trial and error is there are a lot of errors made along the way.

None of the solutions I mention actually address the root cause of the problem.   Many software professionals have thrown up their hands and accept that growth and changing functionality is just the nature of software development.  They incorrectly conclude the best strategy is to learn to adapt as the customer changes his or her mind.   In this scenario the solution to the problem is adaptation.   The teams need to be formed in such a manner so as to react as quickly as possible to the growing and changing environment.

The best way to gather requirements is to learn how to elicit requirements and study the core business.  The business analyst needs to be skilled at ethnology and a master of the metaphor.

You can read more in the free online book, Reboot!  Rethinking and Restarting Software Development, free at http://www.RebootRethink.Com

Published in: on June 26, 2009 at 01:01  Comments (1)  
Tags: ,

Danger, Will Robinson! Lost in Space?

I need someone to explain something to me.  Too often I hear the following statement.  “Our software is too complex to document, so we just code.”   Danger, Will Robinson!  Think about his from a logical perspective.

When software applications become very large or complex, it is hard to keep track of all the functionality contained within the application.   To really understand any complex system you need to use a technique called functional decomposition. So how do you perform a functional decomposition of a software application?   The basic idea is to divide a system into small logical parts. These logical parts are called elementary processes.  This technique works when solving complex mathematical equations, engineering systems, software applications and even your home entertainment system.

Before you begin to classify and organize your documentation, you will need a functional decomposition of your software applications.

  • What are all those small parts (or elementary processes)?
  • How are all these parts interconnected?

Danger, Will Robinson!  If you can’t perform a functional decomposition of your software application because it is too complex, then you software application is too complex.  You need to simplify it and you are probably lost in space.  It is not a matter of complexity, but a matter of not knowing how to properly document the software application.

Published in: on June 19, 2009 at 01:01  Leave a Comment  
Tags: ,

How to Study Thy Customer

What always surprises me is how little software developers know about their own company and its industry.  The reason they know so little is because they have not taken any time to study.

One of the best ways to study customers is by using ethnological techniques.   Ethnological studies consist of looking  at what people do (behaviors), what they say (language), what they really do, what they make, and what they use (artifacts).   Too often what people say they do is not what they really do, and what they say they need to do their jobs is not what they really use.  It is important for the software developer to determine the real problem and the solution for the customers. Those software development organizations that are successful go to their customer jungle.  They follow their customers around trying to figure out how they actually work and what type of information is needed to complete the work.    They actually watch how their customers use the current applications.  They do not just rely on feedback they receive from user satisfaction surveys.

I practice what I preach.  Whenever I get a new client, I start to learn as much about their business domain as possible.  Since every industry has its own set of magazines, journals, organizations, and conferences, I start to subscribe to all these things in hopes of learning something about the business of my new client.  This is a common practice for an industrial designer.

Not long ago, I started consulting with a company specializing in the health care industry.  I subscribed to a series of free magazines such as Health Care Information Technology, Radiology Today, and Health Management Technology.   I also requested conference brochures. I am sure my mailman hates me because I get magazines and conference brochures from just about every industry now.  I read over these magazines and conference brochures to begin to learn about health care industry trends.  Back in the early 1980’s John Naisbitt wrote a bestseller book called Megatrends.  In his book he outlines in great detail how to study trends  and I use many of his ideas.

I learn the names of my client’s competitors.  I review annual reports, read articles and press releases. I make a list of my client’s competitors, a list of the top 5 trends, and a list of people I know in that industry.  Before I arrive at a client’s worksite I have a working knowledge of that industry. My background research is only a starting point for me.  Next I spend time at a client’s site studying them.

Read more at Reboot! Rethinking and Restarting Software Development.

Published in: on June 18, 2009 at 01:01  Leave a Comment  

What we’ve got here is a failure to communicate!

If men are from Mars and women from Venus, then software development is from Andromeda and the user community is from the Milky Way.   Men and women have difficulty with communication because they are from different planets and software development and its user community can’t communicate because they are from different galaxies.

The communication gap seems to be growing larger.  Software developers tend to communicate in techno speak.   Most developers lack basic communication skills and this is one of the root causes of poor requirements.  Developers are not very skilled at asking open ended questions or how to politely probe.   They tend to ask biased questions.    Too many developers prefer computers over people.  All of this leads to poor communication.

So what should software developers do?  Funny that you ask such a question.  Developers need to learn how to

  1. Avoid using confusing jargon and acronyms
  2. Ask open ended questions
  3. Learn to politey probe
  4. Master the metaphor
  5. Avoid biased questions
  6. Focus on the benefits and solutions not the features.

Read more at Reboot! Rethinking and Restarting Software Development.

Organization makes a system of many appear fewer

Mark Twain once said, “A person that does not read books is no better off than a person who does not know how to read.”  An organization that creates chaotic documentation is no better off than an organization that does not create any documentation.  The argument could be easily made the organization is actually better off by not wasting time creating chaotic useless documentation.

On any single software project or application, there can be 100’s perhaps 1,000’s of artifacts.  The artifacts can be requirements specifications, design documents, flow charts, code, test plans, test cases, so on and so forth.  Most of these documents will reside on personal computers or stored on some shared drive.   I have worked with organizations where all “important” documents are stored on a shared drive.  The share drive was created with no standards and no subdirectories.  In other words, there is just a big pile of documents.  Within those documents there are no naming conventions, no standard glossary and no standard format. It can be nearly impossible to find information, so developers just ignore any previous written documentation and start from scratch.

I ask software development organizations to compare how they catalog and organize their documentation to how a library organizes knowledge.  I ask, “What would the local library look like if they followed a similar process for organizing documentation?”  Some people tell me the library would be empty, others tell me books would just be staked up all over the place, still others tell me some of the books would be half written and some of the books would be tucked away in librarians desks.  For too many software development organizations their documentation is not organized at all and it is chaotic at best.

The idea of classifying information and knowledge is not a new idea and has existed for several millenniums.  Classifying was one of those skills in which Aristotle excelled.  Aristotle understood information is easiest understood when it is classified and organized.    The idea of organizing and classifying is nothing new and it should not be a novel idea to software development. The bottom line humans like things organized, we have been organizing information for millenniums, and it is time software development get on board.