Fixed Price and Agility

I’ve come to love ‘agile’ systems implementation methods, and they are rightly fashionable in the nerdy circles in which I move.

But when I was trained on business software implementation methods many decades ago, I was told that it had to go like this:

find out what the customer wants, and write it all down,
get his sign-off on the requirements document,
design the system, and write it all down,
get his sign-off on the system specification,
build the system,
get his sign-off on the system,
and so on.

It didn’t work well. In the first step you might get it nearly 95% right, though there was still a danger that the customer didn’t know what he wanted until he’d seen what he might get.

But the second step was usually the dangerous one. If you’d gained the customer’s trust by the time you’d put the specification in front of him, he’d usually sign it off, even if he had no idea what it meant. System specifications are usually written in an inhuman language using the terminology of the target system. Crucially, they convey nothing at all about what it might be like actually to use a system.

The system build would often happen somewhere far away in a software laboratory, to which, of course, the customer would usually be denied access.

And then the last step didn’t happen, because when he saw what you’d built he wasn’t usually very happy.

agilecascade

This was the old-fashioned ‘cascade’ method and it’s rightly out of fashion. The ‘agile’ method involves more frequent meetings, discussions and demonstrations, so that the customer sees what you’ve understood, what you’ve designed, and what you’ve built and can quickly tell you if you’ve got it wrong before it’s too expensive to change course. When you’re implementing highly configurable software systems such as our time@work, expense@work or forms@work products, or Infor’s SunSystems, prototyping is relatively easy and this method is perfect.

At systems@work we’re doing a big implementation project for a fund services provider. It involves expenses, vendor invoice management, billing, timesheets and lots of workflow and reporting, and all the accounting that goes with all the transactions that are implied. Yesterday we conducted an important prototyping session, and I’m happy to say that it went well. There are a few things that we must change, but there are no fundamental misunderstandings.

But what about the agile method when a project is a fixed price one? Isn’t it potentially a recipe for disaster, in that changes of course are unpredictable and there’s no single moment when you can pin down the project scope in a system specification and treat all subsequent changes as separately chargeable?

This is not an easy question to answer. Wise and experienced project managers will build in a large ‘contingency’ component and perhaps put more emphasis on getting the requirements document right (even this stage of the project can involve proof-of-concept prototype demonstrations). But if you allow changes at later stages it’s hard to charge extra for them.

There is no perfect method. I would only say that if you believe the old ‘cascade’ method is a better one for large fixed price projects you are probably deluding yourself. You may be able more easily to define what’s out of scope, but it will be no easier to obtain the customer’s agreement that he should pay for all the ‘mistakes’ and scope creep, whether they are demonstrably his fault or yours.

If it can go wrong, it WILL go wrong

You can never predict how customers will use computer systems, but one thing is certain, everything that can happen, will happen, whether you like it or not.

My company, systems@work, is the author of specialist software for expense management, and for the management of professional services organisations. Ours are highly configurable systems that can be used for a very wide variety of purposes. Even the terminology can be modified by the customer to suit the customer’s needs – one organisation’s ‘project’ is another’s ‘engagement’ or ‘case’, and yet another’s ‘investment fund’. Timesheets, attendance forms, expense forms, purchasing forms, absence request forms, planning, invoicing and reporting – these are some of the system’s possibilities, but each of our customers will set these up and use them in different ways. There is no right way to use our software, and however they set it up and use it, our customers must expect it to work.

Some years ago a few of our customers asked us to develop a new feature. Especially because end users might be scattered across the globe, they needed their administrators and first-line support staff to be able to log in ‘as if’ they are another end-user. And no, such end-users wouldn’t do any updates, they’d just be looking at the system as if through the eyes of the user they are trying to help, and yes, they wanted the end user to stay logged in whilst the administrator did his or her diagnosis, so both users could look at the same screen together.

So, we provided a highly restricted option called ‘Identity Switch’ that enables one end user, the administrator, we supposed, temporarily to log in as another.

Having two end users logged in to a system is uncomfortable. In our system, as in many, there are all sorts of temporary tables and sets of records that are identified by the end user’s name, and if two users are updating the same set at the same time you can create logical chaos. For that reason, we make it impossible for two users to login at the same time with the same user credentials. If they attempt it, the system says no.

Except, of course, for the administrator or support employee using the new Identity Switch function. We assume they will be careful, conscientious and that they understand the dangers of using Identity Switch to do updates in the system on behalf of the other user.

But you can never predict what users can do, and if there’s something you don’t want them to do you must prevent it, not merely advise them against it. Even if it’s more coding work up front, it will save you time later.

Over the last few months we’ve received a small flurry of reports of a few links between records getting lost. It worried us, of course, and we spent many days investigating how it might have happened, finally discovering that it happened when Identity Switch was used. It turned out that Identity Switch was used for purposes way beyond those we had anticipated, not in exceptional circumstances, as we had recommended, but as part of the normal business process.

‘We warned you,’ we might say.

But what would be the point? We’ve still got to spend hours and hours diagnosing and repairing the problem.

There is no moral high ground to occupy if you’re a software developer. You can try to occupy it, but you’ll obtain no advantage. You simply cannot tell your users how your software ‘should’ be used, especially if you’re trumpeting its configurability. If it can go wrong, it will go wrong. If it can be ‘misused’ it will be.

In reality, there’s no such thing as ‘misuse’. If there’s something you don’t want your users to do, you must stop them doing it, not merely advise against it.

We’re working on it!

Clouds – Nimbus, 9, or Cuckoo?

I am distrustful of bandwagons, and rarely board them as they rattle noisily by. It’s not that I’m against enthusiasm, or novelty, it’s just that bandwagons are often driven with irrational exuberance, and very often they crash. I prefer the slower vehicles that come along behind. They set out in the same direction, but with more care and circumspection, and they reach their destination more reliably.

bandwagon

I remember the bandwagon of the Dotcom boom – and the bust that followed it. Whilst there’s no doubt that the internet changed our lives, I’d rather call it accelerated evolution than revolution. Its victims were more often its most ardent supporters, hell bent on delightful ideas that lacked even a modicum of commercial good sense or realism, than the ancien regime.

The advent of the internet was evolution. It simply extended what we already had, and what we already did as business IT consultants. It didn’t, despite the fears of some, invalidate what we already knew. Business systems nestle as comfortably in the internet as they previously did in their more confined circumstances. The basic problems of system integration, of manufacturing, retail, services, accounting, distribution, CRM, and the rest, are of the same type as before, as complex as ever and we, who understand them, are as valuable as ever.

During the feverish years of the dotcom boom one of my colleagues told me that if we weren’t immediately reborn as ‘Dot LLP’ (instead of LLP Group) we’d be annihilated within six months. I laughed. We didn’t, and we’re still going strong. We learned some of the new dotcom tricks, and we go on learning.

thecloud

The Cloud, I fear, is currently another bandwagon. We won’t be boarding it with too much haste, even if its direction is the right one. We’ll be waiting for the slower train that won’t go off the rails.

The Cloud is an excellent idea. It comes in many forms. As those who tout it say, it allows businesses, even software authors such as we are (systems@work) to concentrate on what we do best. The business of managing IT infrastructure, handling communications, backups, performance, security, and so on, isn’t the business that most of us are in. It’s not our field of battle, so better to leave it to the experts. No need to employ specialists if others can do the job at a competitive price and relieve us of unproductive anxiety. We must concentrate on our core business activities.

All of that is true, and if we could all dump our systems onto rented hardware at reasonable cost, why not? Sometimes it’s possible and the right thing to do.

But that’s not exactly what the Cloud is meant to be. Certainly not all it’s meant to be. It’s not just a matter of hosting the particular collection of business software that we’ve amassed and integrated, it’s also about using a standard piece of software in a ‘multi-tenanted’ environment – one size, one copy suits all. And if we use this piece of software for accounting, this piece of software for distribution, and that piece of software for manufacturing, it may be about using multiple standard pieces of software in a number of different Clouds. It’s about business software becoming a commodity that can be accesses as easily as water through a tap.

Many business worry about the security of their data. But these issues of security are solvable, even if many companies are reluctant to let the ‘professionals’ look after their data. The fact is that data are vulnerable wherever they’re located, whether in-house or hosted, and the issues of security can be solved or not as easily in one environment as the other.

It is the issue of ‘standard software’ and ‘integration’ that don’t yet fit perfectly well within the Cloud. Sometimes, if the purpose of a piece of software is such that it can stand alone and if it’s used without alteration (even if configured for a particular company’s purposes) the Cloud can be a good place to put it, but if standard software has been modified, or extended, or is integrated in complex ways with other pieces of software, and other databases, then making this work with a Cloud-based solution will be difficult, and with a ‘pure’ multi-tenant Cloud based solution (one copy of the software serving everyone) it will be well-nigh impossible. Ensuring the consistency and coherence of systems and databases that are in multiple environments that you do not fully control will be difficult.

As time goes by, new techniques for integration may make this task easier, but we we’re not yet at that destination.

So, I am cautious about Cloud-based offerings in the world of business IT. They may work for some, but for many they aren’t yet the right solution. What seems initially like a good idea founders when a business needs something special from a standard software offering, or some special way of interfacing systems, and many businesses find themselves trapped by the choice they’ve made if it’s located in the Cloud. They’ve exchanged one limitation – the anxiety of running their own infrastructure – for another – the anxiety that comes from being limited by someone else’s standard software and infrastructure.

Whilst the provision and management of infrastructure isn’t usually the basis of a company’s competitive edge, the business software on it, often is.

As a software author (systems@work) we’re cautious. We offer configured systems in a hosted environment, and this suits customers who don’t need any software modifications and who don’t need interfaces between Cloud-based and non-Cloud systems, or who need only simple ones. And we offer on-premise installation and full-blown integrations when they’re needed.

But for now, the Cloud isn’t always the answer and we won’t be betting the business on it.

Developing a Software Package – Sometimes the Nightmare Ends

I’ve posted two articles on what you need to think about if you’ve decided to develop a business software package. You might have a fantastically good idea, but developing, marketing, selling and supporting a package isn’t as easy as you might suppose. There’s far more to worry about than logical design.

The Nightmare

The Nightmare Continues

Have you thought about quality?

If you’re building parameterized software then it’s going to be capable of millions upon millions of permutations. Have you any idea how you’re going to test a sufficient number of these? Or even the most commonly used ones? The more that your package can do, the more ways it can go wrong. The quality level that you aim for is a matter of choice. Perfection is impossible, and near-perfection possibly unaffordable.

Have you thought about documentation?

You’ll need help text (and the capability of multi language help text), reference manuals, installation manuals, user manuals, training manuals, demonstration manuals, and so on. Your customers and resellers expect this (though don’t bother printing them). Electronic versions that can be accessed through a browser will do quite well enough.

How much of the product should you finish before you market it?

Your vision must be complete before you start, with an outline design for everything you intend to develop. You’ll want to sell your package as soon as you can, to make back your investment, but If you sell too soon, you’ll get diverted from your vision, and most dangerously, you’ll find yourself in obscure alleyways of customer-specific code. But if you sell too late, you’ll have used up all your money.

And have you thought of how you’re going to take your package to the market?

If you’re not yourself in possession of an international company, then if you’re going to sell beyond your domestic market you’re going to need distributors and resellers. You’ve got to see things through their eyes. How can they make money from your product? What will be their upfront investment, and their ongoing cost of sales? Is the balance between service revenues and licence fees the right one for them? Can they learn enough about the product quickly enough to be able to present the product and then implement it?

You need to think of the marketing material they’ll need, the return on investment arguments they’ll use, the contracts, the multi-lingual support service, the case studies, the training, the guidelines you’ll give on implementation duration and costs, and so on. If they can’t make money, then there’s no way you will.

And your pricing model has to be one that can, in theory, and even after discounts, return a profit.

But whatever you do, don’t try to set up a reseller network until you’ve won some deals yourself. When recruiting resellers, just as when selling to customers, references are everything.

How are you going to win your first customers?

Whether your first customer is your own or a reseller’s be aware you’re not going to make any money from the first few deals. Your first customers won’t buy your package, however unique, unless you give them a special deal and extraordinary service. It’s hard to sell without references. You have to ‘buy’ the first deals.

And have you thought about how you’re going to keep your development team happy during the long development period?

If you do lose a developer, is his code sufficiently well documented that another can take his place and maintain his code?

Have you designed a feedback mechanism so that your customers’ wishes are reflected in subsequent versions of your package?

If you don’t listen to your customers’ needs, they’ll soon stop paying for maintenance.

Have you made a prudent investment plan to take you from concept to sales?

If you can’t afford the long-term investment that package software requires – the employment, travel, technical and marketing costs that will take you to your goal – then don’t even think of beginning.

My company, systems@work, set out to develop software for professional services (and expense and forms management) more than a decade ago. Did we ask ourselves all these questions when we began?

Some of them, certainly, but by no means all. time@work is a ‘best of breed’ package for services organizations from accountants, engineers and lawyers, to architects, consultants and charity workers. It’s now used by more than 250 companies from Tokyo to Sydney, from London to New York.

If we’d known there were so many questions, we might never have started. During the first few years there were certainly times when we were close to giving up. But if there are two questions we certainly should have asked ourselves more aggressively, they are ‘How are you going to win your first customers?’, and ‘How are you going to take your package to the market?’

We’re securely profitable now, and my anxieties, if any, are operational ones rather than existential ones.

So, if you have a dream and you can answer these questions positively, and if you’ve got nerves of steel, then good luck. After all, someone has to write these packages.

Conferen.ces and Canap.es

There’s one fixture in the software reseller’s calendar that can’t yet be handled remotely – the software conference. We can sell, install, and implement software without leaving the comfort and sobriety of our offices or homes, but once a year we must stir ourselves to press the flesh, down the drinks, and endure the evangelism of our software partners at the annual software jamboree. It’s a festival of PowerPoint presentations, Keynote addresses, teas, coffees, drinks, chit-chat, and endless, seemingly limitless, canapés.

I’ve just returned from Inforum EMEA (Europe, Middle East and Africa), an event attended by customers and resellers of the dozens of software packages that Infor has acquired over the last decade or so. It’s a chance for Infor to present it’s ‘roadmap’ and its vision of the future of business software. And before I carp, let me say that it was useful, and encouraging.

In days of yore, gatherings such as these involved the demonstration of software, but today, the senior Infor executives who present to us breathe a freer air, unpolluted by detail, by bugs, functional shortfalls, misunderstandings, and the nitty-gritty of integrating business software. Indeed, their presentations, and vision, are sometimes unpolluted by the software itself and you wonder, from time to time, what they’re talking about. These days all you get to see is pictures on PowerPoint, and very often pictures of what the software systems will look like, rather than how they look now. Presenters used to talk about what the software does. Now the talk is high-altitude marketing speak, and you long to put up a hand and ask, ‘Yes, but what does it actually do?’

This year there’s been lots of talk about the Cloud, just like last year. If you gave me a Euro for every time I heard the word I’d be a rich man. It’s been a cloudburst of Cloud, and, indeed, why not? At least I know what the Cloud is all about. It’s a place of immense safety but unknown location where you can put your software so that organisations all over the world can use it without installing it on their own premises. I like the idea, on the whole. It gives software authors and resellers more control over what’s going on, saves money for customers and allows them to concentrate on what they do best. But of course it’s not quite as simple as it sounds. How do you modify the software or integrate it tightly and safely with other Cloud systems or your own software?

‘Cloud’ is an acceptable word. Indeed it’s a nice metaphor. So I don’t cringe every time I hear the word, as I do when I hear ‘architected’, or ‘methodology’ (I stick to the word ‘method’, but I fear I am alone in that). Neologisms abound at a software conference, and many are coined there. It’s all part of forging a new world, however incomprehensible.

There’s also a new fashion for putting full stops in the middle of software names or methods. There’s Ming.le, which isn’t new, and now local.ly. Try pronouncing the dot. The former is a splendid ‘platform’ for presenting data and providing workflow on dashboards and mobile devices, but I didn’t understand what the latter is, and I’m not sure the speaker did. It’s something like a global catalogue of statutory requirements.

I’ve attended so many of these conferences that I’ve developed the following code of conduct, all essential guidelines for survival:

Don’t attend too many presentations (I attended only two). They’re often mind numbingly dull, and you’ll get the gist of them simply by asking others. (For the very same reason, I never wear a watch. You can always ask someone else what the time is.) If you’ve missed too many, then sidle up to someone and pretend you’ve been in the audience. Ask some carefully general questions such as ‘What did you make of the roadmap they’ve just presented?’ You’ll be safe with a word like ‘roadmap’. But be aware that you may be talking to someone who wasn’t there either, and you’ll end up having an entertaining conversation about nothing at all, both of you bluffing.
I preached the other day on the Death of the Business Card. But I make an exception for software conferences and you must have plenty of them to hand.
Wear your identification label, even if you don’t like feeling like a parcel. You know how awful it is when you meet someone you know and don’t know the name. Find a way of casting an eye at someone’s label (for that reason wear your glasses) without appearing to be assessing the circumference of their stomach.
Don’t drink at lunchtime. Don’t eat too many canapés.
Make time for some extra-curricula activities. Visit a gallery, or a museum, a church, a temple, a synagogue or a mosque (even if not for religious purposes). Do some shopping. Do something naughty if you’ve got the time and still possess the energy. You’ll return with new impetus to the fray, and possibly with something interesting to say.
Don’t go to the conference dinners unless they’re sit-down affairs. There’s nothing more dispiriting than yet more canapés, and more stand-up chit-chat after a whole day of the same.
Above all don’t drink too much at the bar, and don’t stay up too late. You’ll be sorry. But I know you’ll ignore this, as I do, even after years of regretful mornings.

Developing a Software Package – The Nightmare Continued

Last week I wrote some notes on what you need to think about before you start designing and developing a business software package (see Developing a Software Package). I suggested you shouldn’t even consider it if you’re of a timid or risk averse disposition. You’ll need more courage, more determination, more time and money than you ever imagined. You’ll need a thick skin, impervious to the disappointment and impatience of customers, colleagues and managers. It’s all much harder than you think.

I asked three questions:

Who are your customers?
Who are your competitors?
How are you going to make it simple enough but flexible enough to fit a broad range of customer needs?

Here are a few more:

Have you thought of the linguistic, national and currency issues?

If you’re ambitious and you see yourself selling to an international market, then think of what this means before you’ve written much code. The cost of trying to get this right at any later stage is terminal. So if you aim to provide multi-language capability, make sure your technology supports UNICODE (double-byte representation) at the database and software level. Find a Japanese friend to prove this aspect really works. Make sure you can handle transactions in more than one currency. In fact, think in terms of representing every transaction in your system in at least four currencies simultaneously (transaction currency, local currency, reporting currency, customer/supplier currency). And don’t forget to build sufficient flexibility to cover all the idiosyncratic national tax reporting issues you can think of.

Have you thought about technology?

In this area, don’t try to be too clever. Make sure you choose uncontroversial but up-to-date technology. Be cloud ready and design the software so that it can run in multi-tenant mode (one copy of the software serving multiple clients safely and securely). You can’t go far wrong MS-SQL, IIS, Internet Explorer/Chrome/Firefox/Safari and Windows. Don’t, whatever you do, let your programmers seduce you into using something ‘better’. Don’t be on the leading edge, hitching your wagon to some promising technology that might fail to win market share. Your customers don’t want to be pioneers. Be just that little bit behind.

How important is technical perfection?

It’s a cliché, but in software development, as elsewhere, ‘perfection is the enemy of the good’. If you aim to do things perfectly it’s going to take far too long, and you’ll always fail. So be aware of that when you’re starting. Set yourself guidelines. Have the good sense to know when something’s good enough.

Have you thought about how you’ll manage the technical aspects of licensing?

If your package is modular, and you’ve priced it accordingly, then you’ll need a mechanism for restricting access to components of the system, even if your installation program installs the entire software suite and database. And you’ll need a way of limiting a license period, so that you’ve got some way of making your customer pay you.

Have you thought about the techniques you’ll use for installation and upgrade?

Installation has to be fool proof. Don’t depend on your software falling into the hands of IT specialists. It has to be consumer proof too. Don’t depend on the user having to download additional components from Microsoft or other vendors to make it work. They won’t read the manuals, they won’t understand the error messages and they won’t do it.

Version control is also essential. So is easy upgrade. You’ve got to provide new functionality and bug fixes with easy installation and guaranteed forward compatibility.

Some final thoughts next week….

Mutual Frustration – Why do IT systems users wait so long for features that already exist?

I attended a conference recently where, by chance, I met someone who’s using the expense management system that I design – expense@work. It’s always a little alarming when you meet a real user since you must expect them to be honest, and there are no better judges of what you’ve done. This one was direct:

‘I hate it,’ he said, with the kind of mock fury that told me that he knew he was exaggerating and didn’t really want me to go away and kill myself.

‘Why?’ I asked.

‘Well, it’s so out of date. I can’t attach images to my expense claims, and I can’t use it on a mobile device,’ and so on.

‘But you can,’ I said. ‘We’ve had those features for years.’

‘Then why haven’t we got them?’

‘I don’t know.’

It’s so frustrating, but this happens time and time again. And not only with our own software. We also sell and implement a financial system, SunSystems, and again, we often have to deal with users who want features that we have, but who aren’t getting them.

This is actually a widespread problem in system implementation and the end result seems to be unnecessary reputational damage for the software author.

Why does it happen and how can it be avoided?

It happens because system implementation is a lengthy, expensive and risky business and end users don’t often determine what’s on the list of features that they’re going to get. Sponsors and project managers on the client’s side have a highly controlled, and usually narrow, list of objectives, and their criteria of success won’t usually include the implementation of features that are merely ‘nice to have’ but not necessary.

That’s why ‘nice features’ don’t make the list during an initial implementation, but it doesn’t explain why nice new features don’t get implemented later as soon as they become available.

The problem is that once a system is implemented, the policy becomes ‘if it ain’t broke, don’t fix it’, so new versions with ever more up-to-date features, don’t get implemented either. And this is eminently sensible, because upgrades take time, often go wrong (for a while at least), and cost money. Upgrade projects are sometimes almost as large, expensive and risky as initial implementation projects, even if the software automates many aspects of the upgrade (such as updates to the database).

Software authors want their software to be liked by their end users. End users want ‘nice’ features. The obstacle lies between the two, in the conservatism of the client’s project managers and IT department.

Sadly, I can’t see what’s wrong with this. ‘Conservatism’ is a very sensible policy with business systems. The tragedy is that result is frustration on one side and unhappiness on the other. is there anything we can do about it?

I ask this question without knowing the answer. I wish I could find a way to deliver new features in software without risk or disturbance. But this is difficult. Business software isn’t like a desktop productivity tool. The problem is that what you do in one corner of the system can have unintended consequences in another corner. And when a system is implemented for a client it’s often integrated with lots of other systems, so a change in one corner of our part of the whole, can disturb a corner in another part that isn’t within our control, as authors of just one part, at all.

To some extent this problem is solved in ‘cloud’ or ‘hosted’ solutions, because authors then control the version that an end-user uses, and can introduce and publicise new features without obstruction from intervening project managers.

But ‘cloud’ and ‘hosted’ solutions aren’t always suitable when it comes to complex business software, especially when the software must be integrated with a client’s own systems. When there is deep integration, conservatism rules, and must do so.

And yet, it’s so frustrating to meet end-users and to have to repeat time and time again,’But our software CAN DO THAT!’

Any ideas?

Adam Bager

Occasional thoughts on IT, Business and Other Matters

Tag Archives: business software