The Art of Consulting – Designing (Affordability, Flexibility, Maintainability, Elegance)

Share

Designing well means designing something that does the job as simply as possible and is also easily used by its intended users. Good design also means:

  • Affordability
  • Maintainability
  • Flexibility
  • Elegance

Affordability and maintainability usually go together, and both are often related to simplicity and pragmatism. A good design will do as much of the job as it is sensible to do, as simply as possible, for as long as possible.

In the physical world there’s usually a trade off between high quality of materials (and consequently a long life) and cost. Choosing how well to build something is a matter of cash flow, the pattern of expected return on investment, required lifespan and available resources to invest.

For most people who need to go from A to B, this is a better choice…

small car

than this…

big car

And something like this…

goldfish

is easier to maintain than this…

showdog

In the abstract world of software design, maintainability also requires that know-how persists in your supplier or your workforce. Bear that in mind. Sometimes all the money in the world won’t buy the knowledge that the original designer had.

Flexibility is a more difficult concept. Good design will enable adaptation as requirements change. But anticipating the future, which flexibility requires, is always tricky.

Suppose you are designing an invoicing system and it must be completely flexible, then you must choose a word processing tool such as Word (not in fact a ‘system’ at all), though this comes at the cost of there being no constraints and controls on what a user might do.

Flexibility is expensive. I am a designer of a software package for Professional Services Management and Expense Management (see systems@work). This software must work for many kinds of companies so I must design it to be flexible. This costs a lot more overall than it would if I were designing just for one organisation, even if I designed a certain level of flexibility for that organisation. But even so, our software will sometimes hit a brick wall of impossible requirements and we can’t always do everything that a client might want. Sometimes, if this is a showstopper, we lose the deal.

Judging just how much flexibility is needed in good design is an art. It comes with experience, but you must take account of this. Not to do so can mean  enormous expense when requirements unavoidably change.

Finally, elegance. This is an insubstantial concept, and perhaps, if all other principles are adhered to, elegance simply emerges. The most efficient, pragmatic, simple, maintainable, affordable and flexible design may also turn out to be the most elegant. But, for sure, elegance involves art. It is a matter of aesthetics and it is as difficult to prescribe as it is to write music as well as Mozart did.

See also:

The Art of Consulting

The Art of Consulting – What’s the Role of the Consultant?

The Art of Consulting – Impartial, Honest and Independent

The Art of Consulting – The Essential Skills

The Art of Consulting – Listening

The Art of Consulting – What’s a Good Question?

The Art of Consulting – Representation and Analysis

The Art of Consulting – Writing Simply

The Art of Consulting – Designing (Completeness & Simplicity)

The Art of Consulting – Designing (Pragmatism)

The Necessity of Agility

Share

I’m a nuisance when it comes to system design because I can’t get things right first time. I feel guilty, of course, because asking that things should be done again, or done differently, costs us time and money, and I really ought to be able to get it right at the start, if only I thought about it more carefully.

But, better that I should raise issues now rather than later when it’s too late.

agility

Last Friday I was reviewing the new browser-capable version of invoicing that we’re developing for Version 4.9 of time@work, due out in September (or so). Our invoicing module is complex (I should say ‘sophisticated’ really – it’s the right salesman’s euphemism) since our system is multi-company, and invoicing allows recalculation, discounting, exclusion, addition, rounding and all sorts of other features. Producing a .Net browser version has taken months, but we’re nearly done.

It all began some months ago when I sat down with our systems analyst and looked at the mock-up he’d produced. This followed some hours of discussion over the previous days. The mock-up allowed us to click through the invoicing process, from one dummy screen to another, ‘trying out’ how invoicing might look. Our invoicing process can involve about six different pages, and we’d thought very carefully about what fields should be where, and how to reduce the end-user’s clicks and make the whole process as intuitive as possible..

But, despite that, a mock-up isn’t real, so, to our developers’ dismay, when I looked at the system on Friday, with real data and real programming logic behind the screens, it didn’t seem so easy to use as we’d thought it might be, and it was obvious to me that we’d made a few mistakes.

Years ago, when I worked for Coopers & Lybrand Consulting Services in Budapest I went on a ‘Summit D’ course which was all about systems analysis, specification and development. I was taught the typical ‘cascade’ method. Each phase must be completed before the next phase is begun. Once systems analysis is complete, a requirements document must be produced that the end-users will sign off as correct, then a system specification, and then you build the actual system. Not much room for revision. When the system is complete, it’s take it or leave it, and ‘this is what you signed off on!

But we’re human and our imagination is limited. We need to touch and feel things before we know they are right. So, nowadays, I much prefer the ‘agile’ method of system development or system implementation. You engage in repeated demonstrations and mock-ups and at every stage you allow for revision and successive approximation to what is really needed. The end-user sees what he’s getting long before the system comes out of the laboratory. Of course he’s never HAPPY but he’s less UNHAPPY this way!

True, without careful control this can be an expensive method, but it’s certainly cheaper than delivering a big, expensive, system to users who find it totally unusable.

So, though I feel guilty from time to time at contradicting myself and asking for change, I know that it’s inevitable, and it’s the best way I know. So, forgive me, designers and programmers. And, after all, it’s not as if you don’t occasionally make a few tiny mistakes yourselves.

Here’s a happy user:

agility 2

Four important design principles

When you’re designing a business system for a client, you’re often wrapped up in the logic of information flows from A to B, and back again. That’s important, of course, but you’ve also got to step back and think about what a system is really for, and what will motivate its users to use it well.

system design

These are four principles I always try to bear in mind:

  • Only things that are measurable are manageable

Business systems are about control, indeed, almost as much about preventing people from doing things (except in the right way) as about enabling them. That’s because, to measure the right things with systems, you have to do the right things.

Apart from statutory considerations, business systems are about measurement so that management can exercise control. So you must be very aware of what measurements are of the greatest importance to management. Broad, reliable indicators are often more important than confusing detail. What are the priorities for the business? Stock level management, production quality, sales analysis, product gross margin? You can’t measure everything, so make sure that you understand the priorities and that they can be served by the design you put forward.

  • Information is only useful and worth preparing if it affects the decisions you make.

Once you know what you’re going to measure with a system, you’ve got make sure that those measurements (stock levels, gross margins, sales data), are clearly and economically presented.

Often people will ask you for an elaborate report containing vast arrays of irrelevant data. Usually this is because they had this report in their previous system. Always ask: What will this make you do? Or, what did you do with this in the past? How will this change your life, or the lives of others?’ Ask these questions about each data item on the page.

‘I just like to know it,’ is never a good answer. ‘Nice to have,’ simply isn’t acceptable.

Managers are wasting their time if they are looking at data that make no difference.

  • No process will work if it isn’t to the advantage of those who should execute it.

There’s no point in asking people to put data into a computer unless they get something out of it. Your measurements will be useless if they are wrong.

And it’s better to motivate with carrot rather than stick. Reward is always a better management tool than the avoidance of punishment.

When users on whom you rely for accurate information obtain no personal benefit from a system, then you won’t be able to rely on what they do. It’s no good designing a beautiful, logically perfect system if there’s no motivation driving it. You must try to find carrots, and only occasionally resort to sticks. Money often works, but it’s the crudest of levers.

Remind yourself that, if you are rewarding efficiency, economy, timeliness and accuracy, you’ve got to be able to measure performance impartially.

Only as a last resort should you punish.

  • Motivational measurements work only if they fall largely within the control of those whom they are designed to motivate

Profit drives the shareholders of a company and usually its directors, but others are driven by different goals at different levels. A director of quality cannot be ‘measured’ by profit, rather than by production quality. A director of safety in an oil refinery must never be ‘measured’ by profit. So in a well-run organisation motivation must be aligned with the goals and the scope of control of each manager. And you must make sure that measurement and reporting serve these goals.

There’s no point, for example, in rewarding a consultant for the amount of client work that he or she does, if he or she has no involvement in obtaining the work, or is allocated to client- and non-client-work without any say in the matter.

Good system design is not a game with logic and data, but with real people.

There’s nothing more unreadable than a system specification

System specifications are even more unreadable and useless than business books. I don’t mean because they are boring, which they obviously are, and often poorly written in a language that combines ordinary words with business and technical jargon. Rather, they’re unreadable and useless because they don’t serve their purpose. They fail as descriptions of systems.

The system specification occupies a sacred spot in the evolution of a software implementation project somewhere between requirements analysis and system building.

First, you find out what the customer wants, you write these requirements down and then you get the customer to confirm that you’ve understood the requirements by reading your notes and signing them.

Then you retreat to the turret of your castle and there you specify the system. It’s a kind of alchemy. You take the raw material of what the customer wants and transform it into something (potentially) marvellous using your own special knowledge, experience and skills.

And then what?

Well, at this point the customer is supposed to read (and understand) what you’ve written, and sign his or her acceptance of the design. By doing so he is often also signing away his legal right to ask for changes.

The trouble is that the customer usually has no idea what you really mean by all your alchemical formulae. He’s like someone who can’t read music being presented with the musical score of Stravinsky’s Rite of Spring. He will have no idea what it sounds like.

You have described the system using the language of the software that you know and he doesn’t, showing screenshots from the system that you know and he doesn’t, and the document is so long anyway, and so dry, that he can’t possibly know what he’s really signing up to.

Of course, there are better ways. Customers (end users particularly) should get a chance to play with a system before they sign off on a prototype (together with the document that’s supposed to describe it). There’s then a much better chance that they will know what you mean. Granted there must be some kind of document (more for your own purposes than the customer’s) that documents the design, but what the customer should be exposed to is a kind of prototype, a moving model, that you and he refine over a series of meetings.

This is the ‘agile’ approach to system implementation, a method inspired by the ‘agile development’ method used for software development. Perhaps, using methods like these, there will be fewer occasions when you end up building a monster and hearing the customer say, ‘But that isn’t what I meant at all!’