Steve Jobs vs corporate bureaucracy

In 1985, Britain’s ICL was the largest computer maker in Europe.  ICL invented an incredible piece of kit called the One Per Desk (OPD).   The OPD was a revolutionary product in 1985 that was marketed as an intelligent telephone.  It came with either a 9-inch monochrome monitor or a 14-inch colour monitor.  Communications featured large and it came with a modem to connect with mainframes.  The OPD was also a tiny computer.  It shipped with (I recall) a 100 entry address book and a suite of applications that contained a word processor, database, spreadsheet and business graphics.

It was a brilliant concept but sadly ICL combined just about everything that was wrong in technology.  It had a non-standard processor, but the worst was the use of Sinclair Micro drives (see in lieu of disk drives.  Microdrive cartridges were postage stamp sized tape cassettes and were unreliable.

The OPD was well received and several companies launched software to run on it.   But ICL never corrected the flaws and despite much marketing hype, lost interest in the product and it was consigned to history.

Twenty years later, Apple launched a revolutionary product.  The iPhone was a smart telephone that featured a graphical display, internet communications and a computer operating system that allowed the iPhone to run applications.

The ICL OPD was functionally the same as the iPhone.  Steve Jobs saw the potential.  ICL management was locked into corporate politics and the status quo.  Like the OPD, ICL is now history.

John McMillan

John writes and talks on technology and advises companies on developing and marketing software products. He has published e-books on writing and marketing software and apps. He has 30 years’ experience in the IT industry and has enabled several bodies to sell their knowledge through computer applications.

John’s e-book

“How to Write Software for Sale” describes how to write and sell an app or other software.  It is available from AmazonSee details.

Controlling software costs

Software projects are seriously prone to run over budget. There are a number of reasons why this happens. Some common ones are:

  • lack of clear requirements
  • late changes
  • focus on the desirable rather than the essential
  • uncontrolled implementation

Be clear what you want

When planning a software project, you should know what you want it to do. You should make a list of everything you want the new application to do. You may be clear about this, more often you will talk to the users and find out what they need and would like. As you do this, create two lists of functions and features. One will list every thing the app needs to do, the other will list what people would like it to do.

These lists will form the basis of tender. The more thought you give to the requirements, the easier it will be to control the project. Suppliers will be clear as to what they must provide. If you skimp on this, after the software is ordered, more requirements will emerge. This leads to unplanned extra costs and often wasted work and disputes. The wisdom in the software industry is that every day skipped in the design phase of a software project consumes a week in the later phases.

Avoid Late Changes

Late changes are expensive. They mostly happen because not enough work was done laying out the requirements. Late changes result in wasted work. Work that has been done has to be discarded, other work is duplicated.

Software projects are like construction projects in this – imagine changing the design part way through building.

Focus on the essentials

Another factor is a lack of focus on what is essential and what would be nice to have. The way to overcome this is to break the requirements into mandatory features and desirables. Then, concentrate on implementing the mandatories first. (A main reason why major government I.T. projects fail is because the government fails to do this).

If the budget runs out, discard some of the desirables. If the quotes for the work are too expensive you can also discard some desirables.

Despite what I have said about late changes, most software projects do uncover extra requirements as they progress. Don’t commit the whole budget – allow for extras. Make sure your supplier understands which features are mandatory. A good software company will expect this. Then, make sure he delivers the mandatory features first. Only provide the desirable features when all the mandatory ones are working. You can always add the desirables later.

Control the roll out

It can be difficult to test software. Applications tend to be complex and there can be thousands of routes through an application. Some combinations of data or events can be obscure and the testers will miss them. But the hardest thing to test is the human computer interaction. Computers are predictable, people aren’t. The developers and managers know what should work: other users don’t and they do unexpected things that can break the system. It’s not a bad idea to test the system on the least tech savvy person you can find.

If you have a large number of users, don’t launch new software on all of them at once. Apart from anything else, most support issues occur within a short time, so rolling out the software smooths the support. Dealing with issues from 5 users is a lot easier than from 500.

When I supply packaged apps, I usually find that only around 80% of problems are found during the in-house (alpha) testing. The first few users will find about half the rest of the problems, then successive users each find about half of what remains. Thus, each roll out can be to a larger number of users.