'Tis a fool who repeats his own mistakes.
'Tis a wise man who learns from the mistakes of others.
I have been in the business of providing bespoke software solutions, from analysis and design through to development and implementation, for many years, and I have seen many systems installed with varying degrees of success. All too often I see the same problems occurring time and time again, but with different customers and different developers. In the belief that prevention is better than cure, I offer my experiences and observations so that others may be able to spot these potential problems and nip them in the bud before they blossom into full-blown disasters.
Experienced professionals will recognise that the following comments are based on common sense and can be applied to the purchase of goods and services from almost any sector of the market place, not just the computer industry. Indeed, the design and construction of a computer system has much in common with the design and construction of a building, therefore I may use examples from the latter to add weight to my arguments.
It is taken for granted that a building contractor cannot begin the construction of any edifice unless detailed plans have first been drawn up by an architect. It is the architect who takes the customer's rough sketch and turns it into a detailed blueprint. The builder must know what the end result is supposed to be, and what materials and labour are required before a work schedule can be produced and the first shovel is lifted. It is just not practical to build a room from a rough sketch only to discover later that the size and shape are wrong, the doors and windows are wrong, the power supply is wrong, the heating and lighting are wrong, the plumbing is wrong, and connections to other rooms are missing or are in the wrong place or are the wrong size.
Similarly, a computer system must be designed before the first line of code can be written. As a computer system is comprised of data and functions that manipulate that data, if either of these constituents has not been specified to an adequate level of detail then any work done will probably need to be reworked at a later date, and incur the expense of any reworking and delays to the schedule. Do not be tempted to skip the design phase and rush into coding as you will not actually be saving anything, instead you will simply be storing up trouble for yourself.
I have lost count of the number of times that a customer has asked for a fixed price even before he has adequately identified his requirements. The only reply I can possibly give at that stage is "£x per day" where 'x' is our current daily charge rate. "But I want to know the total amount!" they insist. "Then tell me the number of days that you want" is my reply.
The cost of developing bespoke software can be calculated by using an extremely simple formula:-
TOTAL PRICE = DAILY CHARGE RATE multiplied by NUMBER OF DAYS.
As the daily charge rate for each category of worker (manager, designer, senior/junior programmer, etc) is usually fixed, the only variable is the number of days. To provide this figure it is first necessary to identify the total number of modules within the system, then identify the complexity of each individual module so that the effort required to construct it can be estimated.
A module is defined as a single, specific task (eg: create an invoice, copy an invoice, print an invoice), rather than a group of tasks (eg: invoicing). The complexity of each module is directly proportional to the number of data elements it has to read in or write out, plus the number and complexity of any calculations it has to perform, or business rules it has to verify.
It should follow that if the number of modules, or their complexity is not accurately identified at an early stage, then the timescales and resultant costs will also be inaccurate.
One of the initial documents for any computer system is usually the Specification of Requirements (SOR), which usually accompanies the Invitation to Tender (ITT). The customer will invariably ask for a fixed-price quotation for the development of the system based on the contents of this document. Sadly, most customers are incapable of producing more than a vague outline of their requirements which is full of high-level abstractions rather than low-level details, and they fail to understand why this cannot be used to provide a fixed-price quotation. If the description of the system is not accurate then the cost of building it cannot be determined with any degree of accuracy. It is the degree of confidence in a price that determines whether it is provided as an estimate rather than a quotation.
Some customers are under the impression that they can negotiate a price first, then decide what they want later. They think that they can keep changing their minds, or add in more and more levels of complexity, or merely tinker with the design until they are happy with the result, and without incurring any additional costs. This attitude would not be accepted in other businesses, therefore there can be no logical reason why it should be accepted in ours. If the consultant is to be constrained by a fixed price, then the customer must be constrained by a fixed design, otherwise it would be like trying to hit a moving target.
The term "specification" when linked with "requirements" can be misleading. To be classed as a "specification" a document should be specific, explicit, precise, exact, clear, complete, accurate, definitive, comprehensive, unambiguous, unmistakable, incontestable, indisputable, incontrovertible and unopen to interpretation. If the vagueness of the specification leads the consultant to make an incorrect assumption, or to apply a different interpretation than that which the customer envisaged, then the fault lies with the specification for being non-specific.
This is why the outline requirements specification must be turned into a detailed design specification before any accurate costs can be given. All the holes must be plugged, any loose wording tightened up, all the i's must be dotted, and all the t's must be crossed.
The first and most important phase of any project is the analysis and design phase in which the Requirements Specification (rough sketch) is transformed into a Design Specification (detailed blueprint). It is not sufficient to take each statement in the SOR and treat it as if it were gospel as any mistakes or omissions will be echoed in the design. Most customers will swear on a stack of bibles that their requirements are complete and accurate, but it has been my experience that this is rarely true. The person (or group of persons) who compiled the SOR is usually not completely au fait with the detailed workings of every aspect of their business, and any missing detail which is not spotted until the system is running "live" and a particular set of circumstances is encountered could have serious consequences.
If the customer cannot give a satisfactory answer to Why?, it usually means that the What? is not as necessary as was first thought. There may also be various possibilities for How? depending on the level of complexity or the size of the available budget.
Any inconsistencies in the terminology must be identified and resolved in order to avoid any subsequent confusion. This information can be stored in a Data Dictionary or Repository so that it can be referenced directly by the chosen development tool.
A third part of this phase is to define the size and scope of the system, it's boundaries (beyond which it will not pass), and any connections to other systems. For example, when a customer asks for a stock control system, is he expecting a stock control system on its own, or a stock control system with built-in purchasing, or a stock control system which connects to a separate purchasing system?
Another part is to examine the data requirements of the system in order to determine what data is going in, what data is expected to come out, and the size, meaning and possible content of each item of data. This is used to create the data model from which the application database(s) will eventually be generated.
The final part of the analysis phase is to identify the functional requirements, where certain data is processed in certain ways. Each function will allow data to be input (manually or electronically), output (to a screen, a printed report, or other electronic media), or otherwise manipulated (subject to some form of conversion or calculation). If any conversion or calculation is required the customer must supply precise details, giving examples if possible, so as to avoid the possibility of any misconceptions.
It is during this phase that any vague statements must be identified and clarified. It is not enough to ask for a flexible system - the limits of that flexibility must be defined. It is not enough to ask for a selection of reports - each report must be specified in full, including all the data items and their derivation.
Some customers are incapable of defining their requirements in sufficient detail. They provide nothing more than the basic framework and expect the consultant to fill in the blanks. They assume that it is the consultant's responsibility to discover what they want. This is a false assumption. Nobody but the customer knows how his business operates, and nobody but the customer knows what objectives are supposed to be achieved.
The biggest problem with most companies is that they do not have such a thing as a manual on Standard Operating Procedures which provides their workforce with adequate documentation on the tasks which they are supposed to perform. New employees are taught by word of mouth rather than from proper written descriptions. It is unreasonable to expect a consultant to go through the same word-of-mouth learning experiences as a new employee. The consultant is not a clairvoyant. He cannot read minds. He does not come equipped with a crystal ball. The only way to guarantee that he has been informed of every eventuality, both normal and exceptional, is via the written word. It is therefore the customer's task to provide adequate documentation of his requirements, and the customer's responsibility for any errors or omissions. The consultant may be asked to provide assistance, but the ultimate responsibility rests with the customer. The customer cannot pass the blame for any mistakes onto the consultant with the excuse "I gave you all the answers you asked for, but you failed to ask the right questions".
One thing that really annoys me is that the customer will sometimes allocate a small amount if time, usually measured in weeks, for the consultant to come in and study their requirements. I usually ask them a simple question:-
Instead of defining what is supposed to be achieved, some customers can only describe how they think it ought to be achieved. In my experience this has always been a mistake.
In the first place the customer's solution may not be the best, the most reliable, or the most cost-effective. He will probably not be aware of the capabilities of current computer technology therefore will not be aware of the viability of any alternative methods. He may resist other solutions with those immortal words "But we've always done it this way", but in the absence of any logical arguments these words can safely be ignored.
In the second place if it is the consultant's professional reputation which is at stake then it is unreasonable to expect him to accept responsibility for a design which is not his. If there are any faults in the design then it is the author of that design who must take responsibility.
Customers are very fond of merging several different inquiries into a single screen, resulting in a complicated mish-mash which accesses large segments of the database, and which involves numerous levels of selection criteria. It is never a good idea to implement a design such as this as it is rarely possible to provide an efficient solution for different inquiries within a single transaction. It usually transpires that one or more of the different inquiries runs very slowly. It would be far better to isolate the requirements of each specific inquiry into a separate transaction so that each can be optimised to provide the best possible response times. In the long run the customer would rather have separate transactions that run quickly than a single transaction that runs like a pig with a wooden leg.
The customer should limit his involvement to those areas which he is supposed to know best (how his business operates) and leave the consultant to the area which he is supposed to know best (how to design and build effective and efficient computer systems). The customer should not, for example, try to dictate how the software should look and feel, or how it should operate - he should limit his involvement in describing what needs to be done, and leave the how to the consultant.
In my experience it takes two different skills to create a successful computer system - that of a Business Analyst and a Computer Analyst. Contrary to the opinion held by some naive customers these two skills are rarely found in a single individual. A business analyst knows every aspect of a particular business from top to bottom, inside and out. He knows what is being done and why it is done, and, if there are alternative methods, why one particular method is chosen in place of another.
If a customer does not currently have a business analyst it would be a wise investment to obtain one before attempting to upgrade to a new computer system. All too often the business knowledge is spread amongst a group of managers or supervisors who know only the workings of their own departments and are therefore unaware of the "Big Picture". They are likely to resist any change in business practices which, even though it may benefit the company as a whole, does not have any direct benefit for their own department.
Just as the Business Analyst knows the inner workings of the business, the Computer Analyst knows the inner workings of the computer. The former defines the problem while the latter designs the solution.
Some customers insist that the computer consultant has direct experience of their particular business area. This usually implies that they do not have their own business analyst and that they expect the computer consultant to perform this function for them. This can be a mistake. Even though the computer consultant may have worked on similar systems for other companies there is no guarantee that the internal details would be the same. It would be dangerous to skip any in-depth analysis of certain areas in the assumption that the underlying details are identical to those found in a previous system. If these pre-conceived ideas are not verified they could lead to expensive mistakes.
As the time taken to perform this in-depth analysis for comparison with a previous system is just the same as that for a system where there is no prior knowledge, it follows that prior knowledge does not offer any real advantage, and may actually be a disadvantage.
Before the customer accepts the completed system he will want to ensure that it actually meets his requirements. The best way to do this is by running through a checklist and ticking off the items one by one. Each of the items on the checklist should therefore be a simple statement that can be verified quite easily.
There is a school of thought that argues that the SOR should initially be presented in the form of a structured list of Essential Business Rules rather than an unstructured document containing complex requirements. This has the advantage of not requiring the checklist to be produced in a separate exercise, and also ensuring that the checklist does not contain items that were not identified in the requirements. Software packages are being developed which will help produce this list by storing the rules in a database so that they can be sorted, analysed, verified, cross-referenced and reported.
If a customer asks for a system that does A, B and C, but after costs and timescales have been agreed states that it should also do X, Y and Z, is this a change to his requirements, and therefore subject to an additional charge, or not? The customer may argue that the consultancy has contracted to build a system that meets his requirements, and as X, Y and Z are his requirements they must be included in the system as part of the contracted price.
This is not the case - the consultancy is contracted to build a system which fulfils only those requirements which have been properly documented. Undocumented expectations cannot be included in the contractual obligations. It is the customer's responsibility to ensure that what he asks for is precisely what he wants. Any subsequent "refinement", "adjustment" or "clarification" may not be a change to the requirements as the customer perceives them, but will be a change to the requirements as documented.
There are times when it is not possible to give the customer exactly what he wants. Either it is not possible to provide anything at all, or it is only possible to provide a close approximation. Every solution is a compromise between budget, timescales, the capabilities of the chosen software, and the performance of the available hardware.
Some departmental managers may attempt to define how they think things should be done without finding out how things are actually done. They may not be aware of some of the circumstances that have to be dealt with, therefore the resulting system will have holes in it. It is only by involving the whole workforce in the system, by gathering and evaluating the views of as many people as possible, that a truly successful system can be implemented.
If the first the users know of the new computer system is the day that it arrives on their desks, and they don't know what it does or how to use it, or they spot vital functionality which is missing, or is inconsistent with the way they work, or is more of a hindrance than a help, there will be instant hostility to the system which will be difficult to overcome.
There can be instances where egotistical individuals attempt to enforce their own point of view on the design of the system. They try to add unnecessary complexity just to make their own jobs easier, or to exaggerate their own importance (a case of "I'm in charge, and what I say goes"). They insist on changing the appearance or behaviour of the software so that it is more to their liking, even though there may be no discernible benefit.
Instead of being able to use the natural features of the development tool, or techniques that have been both tried and tested, the consultant is asked to assign valuable resources in the creation of questionable alternatives. The cost of implementing these alternatives is rarely matched by any corresponding increase in performance or usability, therefore it would seem to be rather difficult to offer any justification for their inclusion in the system. What a particular individual wants may not necessarily be what the company actually needs, so instead of providing a cost-effective solution to the business as a whole, the result is an expensive solution to a problem that nobody else understands.
A customer may say "I must have the ability to enter data in any sequence that I like". This is in conflict with the way that most database systems actually work - where a one-to-many relationship exists it is usual that it is not permitted to create an occurrence of the "many" entity without linking it to an existing occurrence of the "one" entity. For example, the relationship "CUSTOMER has INVOICES" means that it is not possible to create an INVOICE entry without linking it to an existing CUSTOMER entry. Anything else would not be logical, and not in keeping with actual business practice. The effort required to design a system that bypasses such a fundamental feature of database integrity would not produce any visible benefit, and would probably cause more problems that it would solve. Therefore, as it is not a genuine business requirement, and its exclusion would not cause the business to suffer, it can safely be ignored.
When it comes to solving a problem the possible solutions may vary from the simple to the complex. If a simple solution is available it should always take preference over a complex one. Complex solutions have a habit of being much more complex than was originally envisaged. They are difficult to design, difficult to test, and difficult to unravel if anything goes wrong. They may also be difficult to enhance or upgrade in the future. This is especially true if the original author is not available to explain his original thought processes. A simple solution, on the other hand, although it may involve more components or stages, is simple to understand, simple to build, simple to test, and much more simple to upgrade.
Some rules provided by the client may sound surprisingly simple, but they may cause difficulties when being applied in certain situations. For example, there used to be a rule on French roads that at a road junction one had to give priority to any vehicle approaching from the right. This was a blanket rule that applied to any and every type of junction. This caused chaos on roundabouts because cars entering had priority over those cars already on it, and the cars on it could not move as their path was blocked by all those cars trying to get on. In a short space of time the entire roundabout could become locked solid.
This rule also caused many fatal accidents in the countryside where a major road carrying large volumes of traffic met a minor road from the right. A vehicle could legally drive from the side road and turn into the flow of traffic because it had the right of way. Imagine the result if a heavy vehicle travelling at high speed down the major road is suddenly presented with a slow-moving vehicle which pulls out from the side road directly into its path.
We all know that each particular type of road junction needs its own rules, therefore some simple business rules which are applied globally may need to be replaced with specific variations to deal with specific sets of circumstances.
A customer may hint at a function which, at first glance, sounds relatively simple. Upon closer inspection it may come to light that the degree of difficulty is much, much higher. A certain level of skill may be required, or a certain talent that few people possess and which cannot realistically be described in simple terms.
For example, when the famous sculptor Francois-Auguste Rodin (1840-1917) was asked how he managed to make his remarkable statues he replied, "I choose a block of marble and chop off whatever I don't need". If it is really that simple then how come the rest of us can't do it?
When a customer says "It's only a simple system" it invariably means that he is only aware of the simpler aspects of his system. He may be familiar with what happens normally, but may be totally unaware of those situations which only occur occasionally. When managers get together to define the system requirements without consulting with their workers, in the mistaken belief that they are saving time, they invariably miss out some of the essential little details. These exceptions, or deviations from normal behaviour can sometimes increase the complexity of the system by a disproportionate amount. In some cases the cost of dealing with each single exception can be just as much as dealing with the normal conditions.
A serious problem is caused when the SOR describes only the normal situations and fails to mention any of the exceptions. Any item which is missing from the requirements will also be missing from the design, timescales and costs, and will therefore be missing from the final system. When these omissions are eventually spotted there will be an interesting discussion on who is to blame for the omission, and who is to pay to have it rectified.
Before making a purchase, especially a major one, it is customary to perform a cost-benefit analysis in order to compare the costs to be paid with the potential benefits to be gained. If the benefits are greater than the costs then the purchase will, in theory, provide value for money. If the costs are greater than the benefits then it would probably not be good value. If the savings made by an item will match its purchase price within a reasonable period of time then that item may be considered to be good value.
If the customer demands the inclusion of fancy features (known in the trade as go-faster stripes, or bells and whistles) without any regard to their costs, and is not prepared to perform a cost-benefit analysis in order to eliminate those items whose price exceeds their performance, then he has no right to complain afterwards that the product does not provide value for money.
I once did a study for a company who were eager to replace their old computer system with a new one, and their told their staff to ask for what they wanted. Unfortunately no one vetted these "requirements" to see if they were actually justified or not, and this is where things went pear shaped. One particular person asked for a specialist subsystem that was not connected at all to the main business. It turned out that he had a laborious task that took him one hour each week, and he wanted the computer to do it for him. After we had designed and costed it we came up with a figure that was equivalent to his annual salary. If the cost is one year's pay and the benefit is one hour saved each week, how long will it take for that investment to pay for itself? Would you consider that be a worthwhile investment?
Just ask a builder to install doors that open and close automatically, or lights that switch on and off automatically and watch the effect on the price. The major difficulty when attempting to automate a process is defining under what conditions each operation is supposed to take place. Some seemingly simple manual operations turn out to be very complicated and very expensive to automate, and require a lot of time before all the bugs can be ironed out and they can be said to be functioning adequately.
A short while after the initial implementation the customer then decides that he wants manual overrides for those circumstances when the automatic settings are not quite right. It eventually transpires that the manual overrides are used more often than the automatic features, which means that all that expense was for nothing.
Each category of person involved in the development of a computer system will have a different daily charge rate depending on their field of expertise and level of skill. This daily charge rate is carefully worked out to cover the person's salary and benefits, management overheads, and a modest portion of profit for the consultancy. The cost of development is therefore directly proportional to the amount of effort it takes. Once the number of days has been estimated, based on the detailed design specification, any changes that are liable to affect the total number of days will also have an affect on the total cost. It is therefore unacceptable for the customer to demand changes to the system which involve additional effort from the consultancy without allowing a corresponding increase in the price.
The consultancy is a business, not a charity. If it works for no payment it will not be able to pay its staff and will soon be declared bankrupt. If it goes out of business then who will finish building the customer's computer system? Who will produce documentation and give training? Who will be around to maintain and enhance it in the future? The costs of finding a replacement consultancy to pick up the broken pieces of somebody else's software will always be far more than the costs of the additional work, so it is a false economy on the customer's part not to pay for it in the first place.
If the consultant estimates the effort required to build a customer's system to be 100 days, but the customer is only prepared to pay for the equivalent of 80 days, why should the consultancy be expected to provide 20 days of effort free of charge? The only reasonable solution is to alter the requirements and the design in order to bring down the estimated effort to 80 days.
It would also be unwise for the consultancy to charge for days not actually consumed. If the consultancy overcharges its clients it will not win a reputation for giving value for money, and the clients will eventually fall into the arms of cheaper competitors. Not having work to charge for has the same result as having work but not being able to charge for it.
Although everybody seems to agree with this principle, there is always a great debate deciding the difference between a "fault" and a "change".
This is why it is vitally important that the customer's requirements are properly documented. Experience has shown that it is impossible to keep track of undocumented requirements.
After working out the estimates for building a system the consultancy will normally add in a contingency element of at least 10% before incorporating the costs into a fixed-price contract. This contingency is for use by the consultancy if it is forced to employ additional resources to meet its contractual obligations due to circumstances beyond its control. These circumstances include such things as key workers becoming unavailable due to accident, illness, jury service, winning the lottery, being run over by a bus, or other acts of God.
If, during the development of the system, it transpires that the customer wants something different than was originally requested, or needs to rectify an omission, it is unreasonable to expect any additional costs to be absorbed by the consultant's contingency. It is therefore highly recommended that the customer has his own portion of contingency built into his own budget, over and above the amount specified in the contract, to act as an emergency fund for "oversights".
There is a popular misconception that a computer has built-in intelligence. This is far from the truth - it is nothing more than a fast idiot that follows instructions. It will follow its instructions religiously, literally, without question and without deviation. These instructions come in the form of programs which are written in a language that the machine can understand (machine code). Programmers are the people who translate business instructions into machine instructions. It is not uncommon for a computer system to contain millions of lines of code. If there is a fault in any of these lines the computer will generate the wrong result. If the business instructions from which the code was generated contained a fault then the computer will generate the wrong result. If the computer encounters a set of conditions that were not catered for in its programming it will not know what to do. It may do nothing at all, it may do the wrong thing altogether, or it may come to a complete stop.
In order to guarantee the performance of a computer system it is vitally important therefore that the translation of business rules into machine instructions is accurate and complete, right down to the lowest possible level of detail. If there is a fault in the business rules as defined by the customer then the skill of the programmer is irrelevant.
When replacing their current manual or primitive computer system with a more up-to-date version, some customers make the mistake of being over-ambitious with their expectations. They think they can move from state-of-the-ark to state-of-the-art in one jump. They try to implement a computer-controlled solution instead of a computer-assisted solution. It is not a good idea to attempt the transition from the Stone Age to Star Wars without pausing at the intermediate stages. The best systems evolve over a period of time, they do not suddenly appear in one big bang. Customers should not attempt to implement new technology without first studying it to determine its strengths and its weaknesses, its capabilities and its limitations, its costs and its benefits. Unless these can be adequately identified and assessed the new system could turn out to be a mill stone instead of a mile stone.
There is an old saying:-
"If a job is worth doing, it is worth doing properly. If you can't do the job properly then you shouldn't be doing it at all."
In order to do any job properly you must allocate enough resources for a proper job. One of these resources is time. It is a false economy to try to cut corners, to take shortcuts. If, in the experience of a professional, it takes 5 days to do a particular job, then don't try to insist that it is done in 3.
Sometimes when I tell a client that a particular task is needed before work can continue and it will take 'x' days they tell me "We don't have time for that!" They do not like it when I tell them that unless they allocate enough time to do the job properly they will not have the job done properly, and the responsibility for failure will be entirely theirs.
Most customers are unaware of the level of involvement that they are required to put into the project. When this error is pointed out the common excuse is that the relevant personnel cannot spare the time. This is a false economy. Any effort not spent in verifying something before it is built will seem insignificant if it has to be rectified after it has been built. Proper involvement from the customer should therefore be supplied in the following areas:-
I have often seen the situation where, after having judged the size of a project and taking into account the customer's expected implementation date, the conclusion has been "We should have started this six months earlier!" The response from the customer is usually "Throw more resources at the project. Put more people on it!"
Believe it or not this is sometimes just not possible. A manager of mine had the habit of answering such a request with the question: "If it takes one woman nine months to have a baby, how long will it take nine women?"
If a project is expected to take 1,000 man-days it is just not possible to put 1000 men on the job and have it finished in a single day. Even if you have the room and equipment for 1000 men it is just not possible to have them all working on the same tasks at the same time. There is a limit to the number of people that can be effectively assigned to a particular task. Certain tasks have to be completed before other tasks can be started. There is a saturation point after which the addition of more resources actually decreases output.
This saying is often trotted out by customers who seem to think that just because they are paying the bill they can make all the rules. Any intelligent person should be able to point out that when you employ a piper that this is what you get:-
The moral is:- If you employ a professional to do a job, then let him do it without unnecessary interference.
As you progress through life you will come across many different ways of achieving objectives. Some will be good, some will be not so good, some will be bad, and some will be downright disastrous. Some may appear to work but have unfortunate side-effects. When something goes wrong the intelligent thing to do is to investigate it, discover what went wrong, and try to do better next time. It may take several attempts to hit upon the best method, but that's life!
I have developed in several different languages, and I have noticed that each one has its own set of advantages and disadvantages, things it can do very well and things it can't do very well. The only way to approach a new development language is to study it, experiment with it, and find out its strengths and weaknesses. Only then can you discover the most efficient and effective way of providing a solution to a given problem. You must build the methodology around the language, not bend the language to fit the methodology. Consequently my approach is to make maximum use of the natural features of the language and not to waste time on pointless or expensive alternatives. It is always easier to 'go with the flow' instead of 'against the grain'.
I have seen too many instances where a development methodology has been decided upon without knowledge of or regard for the chosen development tool. The results have always been the same - disastrous. Either the system won't work at all or it can't be made to work without blowing the budget or missing the implementation deadline. What amazes me is the amount of time it takes some people to admit that they have made a mistake.
When people try to force an alien methodology on me I ask them one simple question - if I can demonstrate a system that allows me to build solutions in hours, how can you possibly justify a system that takes days or weeks?
This is the original description for a Subscription system:-
"We have numerous products which we supply to customers on a regular basis. The price of each product is held on the product file, and may be expressed in any currency. Some products are supplied by external suppliers. The price we charge the customer for these third-party products is the price quoted to us by the supplier - there is no additional handling charge. Customers may be from any part of the world, and each invoice must be presented in the customer's chosen currency. Invoices are generated monthly, in advance, using the prices defined in the product file. If there is any conversion from the product currency to the customer's currency, the original charge must be shown on the invoice as part of the charge line description. Unless changes are made to the list of products which they receive customers will be invoiced for the same amount month by month."
This seemed reasonably straightforward, so we designed a relatively simple system to handle those requirements. However, while building the system we were informed of other factors which the system was expected to deal with, but which were not included in the documented requirements:-
These points were also missing from the design document which the customer signed off. When asked why he had signed off an inaccurate document he could only say he had assumed that we knew what was really meant. When these omissions became apparent, during user acceptance testing, he was told that they were changes for which he would have to pay extra. He objected strongly by saying "These are not changes - they have always been part of my requirements". When asked to provide documentary evidence to support this statement he could not, therefore his argument failed.
A customer wanted a computer system to serve two departments whose needs were similar, but not identical. He thought that it would be too expensive to have a separate input screen for each department, therefore provided the consultant with the definition for a single input screen to serve both departments. The screen was implemented exactly as requested, but neither department was very happy with it and requested changes.
Neither department's requests could be implemented in full without conflicting with the other's, therefore only a compromise solution could be reached, resulting in only minor changes being made to the screen. Despite these changes both departments remained unhappy with the screen, and their hostility to it grew to such an extent that the entire system, which cost over £200,000 was scrapped after one year. The customer blamed the consultancy for this failure, and awarded the new contract to a rival company.
Had the consultant been informed in the first place that the requirements of the two departments were so dissimilar he would have designed a separate solution for each department. It was wrong for the customer to force his own design onto the consultant in the mistaken belief that one input screen would be less expensive than two. As any experienced professional will tell you it is the complexity of each transaction, not the number of transactions, that has a bearing on the costs. Two simple transactions, each performing a single function will always be easier to implement, and therefore cheaper, than one complex transaction which performs two functions.
It was also wrong of the customer not to invite the consultant to the meeting in which the two departments expressed their displeasure at the single input screen which they were forced to share. The cost of splitting that single screen into two so that each department would get exactly what it wanted would have been much less than the customer envisaged, and far, far less than the cost of scrapping the entire system.
A customer wanted a computer system which included, amongst other things, a Purchase Order Processing subsystem linked to a Purchase Ledger. The Purchase Ledger was to have been implemented as part of a third-party financial package, to reduce costs, while the Purchase Order Processing was to be entirely bespoke. The procedure for dealing with supplier invoices for goods received was to have been as follows:
This did not satisfy one particular user. He did not want to write the document number on the invoice manually, he wanted the system to print the number on a sticky label. He was told that this would be extremely expensive and not worth the effort, to which he replied: "That is not my problem - I have been told to ask for anything I want, and I want sticky labels".
The cost of satisfying this "requirement" would include the additional hardware (printers, and a supply of special sticky labels), plus changes to the software. It was the software element that would prove to be the most expensive, even though the user considered it to be nothing more than amending the existing code to include a simple "print" instruction. The problem was that we could not amend the existing code as that part of the system was being supplied by a third-party package, and the authors of that package would not release their code to anyone. Neither were they willing to insert the additional code themselves as they considered it to be an unnecessary waste of time which none of their other clients would ever use. The only option would be to write a bespoke version of the relevant module in order to produce a set of code that could be amended. Unfortunately it would have taken many man-hours of effort in order to find out exactly what the original module in the package actually did so that it could be duplicated and tested.
The cost of providing this label printing facility would have been equivalent to the best part of that user's annual salary. The cost of the original manual system, as envisaged by the consultant, would have been no more than the cost of a ball-point pen.
This, when coupled with all the other user requests, caused the development estimates to increase four-fold. This was unacceptable to the management team so the whole project was dropped. All those users who asked for everything ended up with nothing.
30th April, 2001
Back to TOP.