systems@work App – A New Version

Share

Learning how to develop and manage Apps has been a difficult and essential experience for our development team at systems@work. ‘Mobile’ is the buzzword these days, even if last week it was ‘Cloud’.

We recognised three or more years ago that we needed to develop an App for our largely browser-based ERP software – time@work for Professional Services Management, expense@work for Expense Management, and forms@work for forms workflow management. In some ways it’s not easy for traditional ERP developers and consultants such as we are to learn the new tricks of the App world, but if you’re in the business of packaged ERP software you’ve got to keep up with technology and be near the leading edge, if not quite at the edge itself. Just as the browser revolution demanded that we think in a different way both technically and in terms of user experience, so the App imposes new demands. Apps must be even easier to use, indeed almost a joy, manipulable with a single finger or thumb. But making the complex seem easy is always a challenge with complex business applications.

The tradition with Apps is always keep it simple, or, rather keep it looking simple and easy to use.  Specialist terminology must be avoided, and functions must be intuitive and easy to use. The space you have to work with is small, but nothing must look cramped. Obviously there’s no point in crying RTFM when users complain that they don’t know what to do next. If your Granny can’t use it, you’ve probably failed the keep it simple rule.

granny

But ERP systems are complex, and our systems@work software is highly configurable. It’s all about forms – forms for expenses, forms for absence requests, forms for recording time on projects, forms for stock movements, forms for this and that. You can configure a form to do any number of things, offering different fields with different lists of items, calculations with different rules, and so on. You can also attach photos and record voice memos and use forms in any number of different languages. You can also set up any number of form types and control who sees which ones.

All the lists, labels, definitions and rules that form types need are held by our system in a central database. So we have to make everything work with a single App, an App that can read and download these rules and interpret them on your mobile device. Moreover we need to make this download work swiftly. You can’t keep Granny waiting.

Apps must also work whether you’re online or offline. Actually, that’s not a necessity, but given that the rules that govern forms must be downloaded to the simple database that sits inside your mobile, then why not? Some of our users have been clamouring for years for a way to enter their expenses offline whilst flying, for subsequent upload in the Arrivals Hall. So it was part of our plans to produce an App that could be used offline as well as online.

We set ourselves these objectives:

  • Our App must be easy to use
  • Our App must look good
  • Our App must work with any configuration of our software
  • Our App must work offline and online
  • Our App must be fast in terms of upload of data and synchronisation

iPhone technology is very different from the Microsoft technology we were used to, and we had a difficult choice, either to find an iOS expert and teach him or her how our system works, or retrain one of our programmers on iOS technology. We chose the latter but had recourse to App expertise when we needed it. Even so, it took nearly 18 months to develop the first version of our App, together with all the server-side web services we need to serve it.

Take up is gradual but accelerating, and yesterday we released Version 2.0, taking account of immediate feedback from our users. We’ve improved usability, extended the use of the App to include form authorisation, and improved graphics. In the coming weeks we’ll release an Android version, and in the coming months a Windows Mobile version.

APPV2

There’s also one more challenge that ERP software authors face – how to manage the release of App versions. The problem is that ‘delivery’ is uncontrolled. Release an App to the App Store and everyone gets it almost immediately. It’s got to work first time for every Client who’s already using it irrespective of their configuration, and without a chance to run in test mode. This also implies that each new version must be compatible with prior versions of the core software. We’re still thinking about how to do that in the best possible way.

Blingless in Sofia

There are large parts of the world where many of those of moderate wealth, and all of those of great wealth, have acquired their possessions questionably. In such places bling abounds. If there are ‘expensive’ restaurants for business visitors or tourists they tend to be decorated brightly, opulently and ostentatiously, with the undiscerning, and undeserving, rich in mind. They are peopled by fat-bellied, swarthy gangsters, shouting into their mobile phones, blowing cigarette smoke with arrogant abandon and largely ignoring their blonde and leggy molls, who look on vacantly, even anxiously, uncertain of their tenure.

Such was Sofia some fifteen years ago, and such is Moscow still, and probably Almaty. If you weren’t wearing Gucci, or Versace, and weren’t dripping with ill-gotten gold, you were consigned to a table in a dimly lit corner of the restaurant, to be served, eventually, by reluctant waiters, and glanced at with sneering pity by more profligate and better-tipping oligarchs.

I feel a great nostalgia for such times. There was an edge to travel in the newly free democracies of Central and Eastern Europe that has been lost to normality. It was an adventure. Now it is merely a pleasure.

I’m in Sofia for two nights on the first leg of a four-country tour of LLP Group’s offices in Bulgaria, Romania, Hungary and Slovakia, before returning to my home city of Prague, and then on to the UK for Christmas with my mother. I’m travelling not on a Santa-style sledge, drawn by flying reindeer decked out in our company’s colours, but by low-cost airlines, which take me through two additional capitals, Belgrade and Berlin. If time permits I might also make a detour to Vienna on Sunday, since I have designs on Demel, the great Viennese café and cake shop, who make the best stollen and gingerbread in the world. I need stocking fillers for Christmas.

The purpose of my tour is unambitious and largely gastronomic. I take my colleagues out to lunch or dinner. I bestow Christmas goodwill, and listen to their woes and joys. Yesterday I took my Bulgarian colleagues to my favourite place in Sofia, the entirely bling-less Made in Home, a restaurant that is the antithesis of gangsterism, ostentation and tastelessness. The blingy rich wouldn’t even be seen dead there, though, aware of it or not, they’re far more likely to be seen dead at the places they do frequent. Its décor comes from grandmothers’ attics, bizarrely juxtaposed with original modern paintings and prints. Its chairs are a mismatched collection from the last ten decades, and your table may well have been made from a door. It’s cosy, friendly, inexpensive, and peopled by people of all kinds, none of them eager for display, and the food is absolutely excellent. It is the kind of place you might find in New York, London, Tel Aviv, or Paris, but that’s not to suggest it’s bland.

sofia1

We booked a table for 12.30 and although we set out from the office at 12.15 we were lucky to arrive before losing our table. Traffic in Sofia is appalling, made worse by breakdowns (see my colleague Stoyan removing an overheated car from our path) and by road works. Sofia, one of my favourite cities in Eastern Europe, is still being remade.

sofia3

sofia2

We enjoyed an excellent lunch, choosing from a menu that included Bulgarian as well as ‘international’ dishes. The emphasis is on vegetables, but you can also eat fish and meat. It was so good I returned, alone, for dinner, and ate the zucchini patties with yoghurt all over again.

 

FPPs – Mitigating Some of the Risks

Share

I’ve written two sets of notes on the risks of Fixed Price Projects in the world of ERP implementations. My own experience at LLP Group has taught me that the more thought and definition you invest in a project before it’s started, the lower the risk for both you and your client. This is true irrespective of whether you are undertaking a fixed price or a time and materials project.

See

FPP – A Frightening Acronym

FPP – Estimating Fixed Price Projects

Although you would hope never to have to refer to it once a project has begun, the contractual paperwork and the project scope and definition that it refers to or contains, are of vital importance in establishing an understanding between you and your client. If you don’t encapsulate your thoughts, ideas and discoveries in these you might as well not have bothered. Protection is essential both for you and your client, and the best protection is a clear understanding precisely documented.

contracts.jpg

Contracting and Scoping

When you enter into an FPP agreement with a client inaccuracy is the devil, ambiguity is the killer, imprecision is the plague. There should NEVER be a list of tasks that includes completely unqualified items such as:

  •  8 Management Reports
  • Assistance with Data Import from legacy systems
  • Support during Go Live
  • Documentation
  • Etc

What’s wrong with these? They are open ended. What sort of reports? (And what is a report, anyway?) How much assistance with Data Import, and what legacy systems, and how many times? How long is Go Live?

So, an FPP must be well-scoped with dozens of pages of definitions and clarifications, and descriptions of what the client will get. And if all of this is done with a client who understands the FPP game, that both sides need protection from undue risk, this is perfectly possible. We should do it even if we don’t get paid for it. Ten days given for nothing before the project begins saves hundreds lost later. And if you do it well, you also have a chance to impress the client with your understanding.

These are some typical areas of risk:

  • Data Import/Transfer from Legacy Systems
  • Reports
  • Training
  • Documentation
  • Interfaces
  • G0-Live Support
  • Delays
  • Accuracy
  • Payment Terms
  • Get-Out Options

Let’s look at some of these:

Data Import/Transfer from Legacy Systems

This needs to be qualified:

You must list the systems from which data will be imported and the data items

You must quantify the data – how many records?

You must make it clear that you assume that the data are ‘clean’ (i.e will not fail repeatedly on import because they don’t conform to the requirements of the new system)

You must specify the format in which data are to be provided and make it clear that you are not responsible for and estimating for the job of exporting the data from these legacy system

Your scoping document and contract should include a clause such as this:

‘Our obligations under this agreement include the importing by us of data into NEW SYSTEM. To reduce the risk of an open-ended obligation to spend an unlimited time on this task, we assume that:

  • These data can be provided by you to us in text-file or Excel formats as specified by us and at the time specified in the agreed project plan, or if delayed, as notified to us with at least two days’ notice
  • These data are ‘clean’ in the sense that they conform to the parameters of NEW SYSTEM and do not need repeated correction and reimport (we assume that import will succeed by the second attempt)
  • You confirm the correctness of the data in NEW SYSTEM in writing before any dependent tasks in the project commence
  • Volumes do not exceed nnnnnn records from system x, nnnnnn records from system y, etc

 

We reserve the right to charge for any additional time incurred during the process of data import if any of these conditions is not met.’

 

Next time I’ll look at some more areas of risk that need careful mitigation.

Outcooking Julie

Blogs about food are often tiresome or mouth-watering and sometimes even both. None has been celebrated more than Julia Powell’s. She set out to cook all 524 recipes in Julia Child’s Mastering the Art of French Cooking in 365 days whilst breaking up with her boyfriend, and without gaining weight. The blog became a book and then a film starring Meryl Streep and Amy Adams – Julie and Julia. It’s a wonderful film, with Meryl Streep at her absolute best. I’ve watched it at least three times. One of its few serious points is that ‘if it tastes good, it’s got butter in it,‘ a truth that, unfortunately, keeps the cardiologists in work.

JulieJulia

Mastering the Art of French Cooking is actually a difficult cookery book by today’s standards – dense and almost academic in its thoroughness and technical detail. It’s severe rather than encouraging. There’s none of the joshing and personal anecdote that are typical of today’s lighter guides, where food is not always the centre of attention, and where photographs occupy more than half the space.

To my mind, 524 recipes in 365 days is only moderately impressive. It’s only just over 1.5 recipes per day, which is not spectacular, though I suppose it’s hard to keep going day after day for an entire year, and do the shopping and washing up as well. By contrast, I work in bursts, and am more of binge cook than long haul. My big binge of the year coincides with my partner’s birthday. This year I cooked 19 dishes in 48 hours (about 15 hours of cooking all told). We invite about 50 guests for a combination birthday/Christmas party.

food

I cooked:

  • Lasagne (Elizabeth David’s recipe from Italian Food – a Bolognese sauce with a pinch of cloves, a white sauce with a hint of nutmeg.)
  • Parmigiana di Melanzane (form the famous staple of Italian cooking – The Silver Spoon).
  • Fish Curry (own invention – white fish, coconut milk, onion, butter, curry powder, coriander, lime juice)
  • Beans with chorizo in tomato sauce
  • Paprika Chicken with sour cream
  • Cauliflower cheese (more nutmeg, mustard in the sauce, topped with breadcrumbs mixed with grated parmesan and browned)
  • 36 Cumberland Sausages from Marks and Spencer
  • Fennel baked with honey, white wine, chicken stock and mustard seeds (got this one of the internet a couple of months ago – easy and delicious)
  • Crispy Chicken from Jamie Oliver’s Dinners (chicken legs, tomatoes, chick peas, masses of garlic, and basil in a very hot oven)
  • Potato salad with spring onions and mayo
  • Waldorf Salad (chicken, celery, walnuts and apple)
  • Green salad
  • Beetroot baked with honey, coriander, garlic and balsamic vinegar, cooled and served with goat cheese
  • Caprese Salad
  • Paella from Pru Leith’s Cookery Bible (Chicken thighs, onion, rice, crab meat, prawns, mussels, chopped tomato, saffron)
  • Stuffed mushroom (leeks, tomato, white wine, blue cheese)
  • Grilled courgettes with Parmesan
  • Eton mess (cream, meringue, raspberries, blueberries, strawberries)
  • Strudel (caramelised apple, lemon peel, lemon juice, dates, currents, honey, cashew nuts, ground cloves and cinnamon)

All of the above required some effort, if not great skill. Otherwise it was a matter of opening bags of crisps, tortilla chips, and jars of dips.

Most of these dishes had been consumed by the time the final guest left at 8.30 the next morning.

Apply in plenty of time for next year’s party. I can’t cook for more than 50.

 

Just Three Days After Two Days to Go

Share

Yesterday we finally released Version 5 of time@work (expense@work and forms@work to follow shortly), just three days after we were only two days from completion. As I wrote on Monday, estimating and predicting in the area of software development is immensely difficult (Two Days to Go).

At systems@work we develop specialist software for professional services management, expense management and workflow. Our software is used all over the world.

PSWV5

Version 5 includes many improvements, though, inevitably, not as many as were on my list when we began our development work a year ago, and some improvements weren’t on my list at all. Priorities inevitably change from one month to another in response to the demands of customers and potential customers.

With every new release we must make advances on at least four ‘fronts’:

  • The ‘functional’ front. Every new release must be more capable than its predecessor.

We’ve made the calculation algorithm more powerful by enabling parallel sequences of calculations.

We’ve made it possible for invoices to be emailed directly to clients in Word, Excel or PDF format.

We’ve enabled drilldown ‘sub-reports’ from timesheets and forms.

And more.

  • The ‘technical’ front. Every new release must work with the latest operating systems, browsers, and devices.

We’ve added time capture to the capabilities of our App.

We’re shortly releasing an Android version of the App.

We’ve made some processes faster, such as invoicing and data import.

We’ve provided invoicing and data import capability in the browser. This means that end-users of time@work can now do everything in a browser:

Timesheets – submission and authorisation

Expenses – submission, authorisation and review

Forms – submission, authorisation and review

Approvals

Invoicing

Planning/Budgeting

Skills Matrix

Reporting

Data Import

Data Export

We’re therefore ever more ‘cloud’ ready.

We’re investing in ‘mobility’ by providing more options through our iPhone and Android Apps.

  • The ‘graphical’ front. We have to keep up to date with graphical fashion.

In this respect, we’ve still got some work to do. I have many faults, but one of them is certainly to think that in the end what matters most is what software DOES. I do believe that, and I probably don’t give enough weight to graphical considerations. But over the last months I’ve heard too many comments that our software is looking old fashioned, so over the next two months we’re going to modify the browser interface radically to bring it up to date.

  • The ‘usability’ front. We have to make our software ever easier to use.

We’ve made it possible to work with forms in ‘page’ mode as well as in ‘grid’ mode.

We’ve made it possible for end-users to import data into forms from Excel spreadsheets. This means that expenses, for example, can be entered into a spreadsheet offline and then uploaded.

We’ve added search capability and two-column lookups in the App.

But in this area , also, there is more to do. We’ll be looking at improvements in Planning and the provision of responsiveness in search tools so that searches are conducted as characters are typed.

I have a list of hundreds of suggestions from customers and colleagues, and I have lots of ideas of my own. Plenty of work to do!

FPP – Estimating Fixed Price Projects

Share

I posted a blog a few days ago on Fixed Price Projects (FPP – A Frightening Acronym). FPPs frighten me because part of LLP Group (a part I’m happy to have sold) worked with the wonderfully open-ended Microsoft Dynamics business software products. We sold, scoped, estimated, and executed such projects poorly, to the extent that we made no margin at all, sometimes on hundreds of days of consulting, even whilst satisfying our customers. Our consultants and developers were no doubt excellent, but our sales processes and project management skills were insufficiently sophisticated and cautious.

Because of this I’m wary of FPPs, even if I know that they can be done well, can be controlled and can be profitable. To that end, I try to make sure that everyone in the company is aware of the risks and how they might be mitigated.

My last notes were about the Sales process. Here are some thoughts about Estimating.

estimating

Estimating

Estimating is a process that must involve both the sales and the consulting/development team.

It’s a time-consuming business. But FPPs get off to a bad start if we calculate estimates poorly on the basis of incompletely understood requirements, and half-baked solutions. Even ten free days up front might save hundreds of days later.

Of course, it’s the sales team that has to sell the project and who, in conjunction with management, must decide on price (for a defined scope), but our sales and management team MUST listen to what the consultants have to say. If they say they must know more about the client’s requirements, then the sales team must provide them with more. Never be tempted to think ‘Well, if I add another five days or so, that’s bound to be enough’. It isn’t.

And ALWAYS add contingency to your estimate. (And then more.)

In the end it is a commercial issue as to whether you knowingly ‘sell’ fewer days than you know that you need to execute the project. Whether that is commercially wise or foolish has nothing at all to do with the deadly sin of starting a project with inaccurate estimates of how much time the project will actually take you.

What if your estimate is insanely too low, and you discover that once you’ve started the project?

Well, it’s important when creating an estimate to make your assumptions explicit. This isn’t a slippery way of avoiding commitment, a trick that you’re playing on the customer. No, it’s an honest statement of the basis for your estimate. If it turns out that there are material facts that you’re unaware of, then you’ll be glad to be able to go back to the customer and ask for more time. And make sure that you make it clear that it isn’t your fault that you didn’t ask. You need to include a statement like this one in your proposal:

This estimate is based on materials provided by the customer and discussions with [named individuals]. Whilst we have built a certain level of contingency into our estimates to deal with the unexpected, the following assumptions are material, in that if they are incorrect our estimates may be materially wrong in either direction. These assumptions are [examples]:

  • In valuing your inventory you use only one method of valuation, weighted average valuation in local currency in conformity with statutory tax regulations
  • In valuing your inventory you value it only in one currency
  • You have no need for lot tracking of purchased, intermediate or final products
  • Etc’

 

And very importantly…

  • Your staff are motivated and committed to the process of implementation and will provide timely support as required
  • Your staff will be available for the time that we have estimated is required of them’

 

If possible you should build the estimation process as a first step of the project itself, or present this as a project stage where estimates and assumptions are confirmed. If necessary, give some free days to this, since your risk is greatly reduced by it, and you have a chance to demonstrate competence.

But if you do this it is also important that you build into your contracts an escape clause.so that both parties can terminate the contract or renegotiate it if the estimates or assumptions turn out to be incorrect.

In the Gift of the Gatsbys

Just outside the Government’s headquarters in Chisinau, capital city of Moldova, there’s a billboard advertising a ballet based on The Great Gatsby. No irony is intended, I think, but it struck me as spookily appropriate that Scott-Fitzgerald’s great American tragedy should find a home in Chisinau.

Gatsby

The Great Gatsby is set in the 1920s in New York and Long Island during the early years of Prohibition. Gatsby, an enormously wealthy businessman and war veteran, is young, urbane, generous, extravagant, philanthropic, and charming, the aloof centre of a mad whirl of cocktail parties, decadence and soulless excess, the man everyone wants to know or be. He’s the embodiment of the American Dream, a rich and powerful man who has come from nowhere to possess nearly everything. Of course, somewhere not far behind or beneath this tasteful façade lurks bootlegging, violence and organised crime, but the surface, at his vast Long Island mansion, is unruffled. He is a man to look up to, to be grateful to, and to respect.

At the outset of the novel Gatsby is in love with Daisy Buchanan, an apparently unattainable married woman, with whom, years earlier, he had had an affair. As the story develops their affair is rekindled, and when Daisy accidentally knocks down and kills her husband Tom’s mistress, Gatsby takes the blame and is then stalked and shot by the woman’s husband. One senses that, in the end, he’s almost grateful for annihilation. It puts an end to the ennui, as well as the heartache for a woman he can’t fully possess.

Cut to Moldova in 2015. so like 1920s New York. In Moldova, one of the new, liberated, capitalist democracies that have emerged from the ruins of the Soviet empire, everything is now possible , that is, as long as you possess sufficient courage, ambition, ruthlessness and intelligence, and as long as you’re not too morally squeamish. You can rise high in the ranks of government and society, however you might have made your fortune, and whomever you’ve exploited, as long as you’re disbursing the right favours at the right time and in the right places.

Take Ilan Shor, a young Moldovan businessman who’s recently admitted giving Vlad Filat, the country’s former Prime Minister a million dollars in bribes. He’s off the hook, I believe, in return for  the hooking of the bigger fish, and, as Mayor of Orhei, he’s become, in any case, invulnerable  (It is an inexplicable feature of many of Europe’s new democracies that politicians are immune from prosecution. )

He’s not as fascinating as Gatsby, but he’s probably equally as much ‘image’ as Gatsby, rather than reality. In Orhei Ilan Shor is loved by his constituents, not for his alleged criminal daring, but for the greatness of his heart and his unselfish concern for his constituents, above all for the largesse he’s bestowed on the region. It’s alleged that he won the election with 62% of the vote at least partly because of gifts of basic household commodities distributed to impoverished voters (see The Great Moldovan Bank Robbery). Never mind that the money and gifts he’s giving away might never have been rightly his own, his people still love him, as if he’s really a man of simple generosity, not of inordinate and immoral greed.

How splendid it would be if the tycoons and political leaders who dominate Moldovan society were to fall from grace. They needn’t fall as gracefully, as tragically and sympathetically as the balletic Gatsby in the image above. But I do not suggest they should be shot. Rather, they deserve a fair trail and several decades in jail if they’re finally convicted.

Right and Left

I’ve just got to the end of Allan Massie’s wonderfully readable series of four crime novels, all set in German-occupied Bordeaux between 1940 and 1944. They’re a very palatable kind of history lesson, and as gripping and complex as any crime fiction must also be. Crime, though, is merely incidental to them. Above all they’re an exploration of the moral complexities of compromise, the public compromise with Hitler’s Germany of both the Occupied Zone and the Free Zone of Vichy France, and the private compromise that each character must make in leading his or her professional or private life.

vichy

It’s impossible to imagine equivalent novels set in the morally less complex and undivided Britain of the same period, at least once the temptations of appeasement were put aside. The choice was simple: ‘We shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets‘ and so on. To all intents and purposes, after May 1940, everyone in Britain was on the same side.

France was different. Vichy France was a chance for reactionary forces, unhappy with Republican France, to remake at least part of the country as an authoritarian Catholic nation. And for the Communists the Resistance was an obvious breeding ground. As history, these novels reveal an extremist passion in French politics that was and is (agreeably) absent from British political life, where in the twentieth century there hasn’t been any real danger of dictatorship, neither of the right, nor of the left.

Many of Massie’s characters choose the Right and join the milice to fight the Resistance, or the Volunteer Legion against Bolshevism to fight with Hitler’s armies on the Eastern Front. Others choose the Left, joining the communists who made up a large part of the Resistance, and who were only just outmanoeuvred by De Gaulle after the liberation of France in 1944. Both commit ideologically motivated crimes of great cruelty and ruthlessness against their fellow Frenchmen and women, both during the War, and in acts of retribution, after the liberation of 1944. French society had and has more cause for division than British society ever had.

The Right and Left live on in France, as we have seen this weekend, with the National Front more successful in regional elections than anyone could have expected. Marie Le Pen stands far further to the right than the UK’s Nigel Farage, and represents a brand of intolerance that wouldn’t, I think, catch on in the UK.

Allan Massie’s four novels are peopled with a well-imagined cast of selfish aristocrats, Germans (some of them good and honourable ones), reactionaries, Jews, communists, gays, spies, prostitutes, collaborators or many kinds, and policemen, most notably Inspector Lannes, the troubled mid-ranking investigator who, together with his ideologically divided children, is at the centre of events.

Death in Bordeaux

Dark Summer in Bordeaux

Cold Winter in Bordeaux

End Games in Bordseaux

I’ve always been fond of Allan Massie’s writing, not least because he favourably reviewed the acting of an old friend of mine who appeared at the Edinburgh Festival in the late 1970s, and never, as it happens, on the stage again. All of Massie’s novels are instructive, thoughtful, lively, and readable in a good old-fashioned way. There’s nothing alarming or experimental about his technique to deter you, and although he’s a Scottish unionist Tory, he’s clearly a conservative with a socially liberal conscience. His novels are ‘moral’ novels, exploring the complexities of human loyalty, both public and private, and all varieties of human need. I began with his accounts of the lives of the early Roman Emperors, and continued with his three twinkly and mischievous novels set in the Dark Ages. Read them all. They are effortlessly enjoyable but never trivial.

Countdown – Two Days to Go

Share

Building software isn’t necessarily more difficult than building a building or a tunnel. You don’t get wet, or get mud on your boots. You don’t work with dangerous machinery or risk falling from a high place. You don’t need a hard hat to write software, you just need a chair, a warm place, a mug of tea and a computer.

building site

You would think that there are fewer unpredictable things in the logical space in which we software developers work (barring the malfunction of other pieces of software that form part of the system – equivalent, I suppose, to malfunctions in materials that form part of a building). It’s not an exploration of unknown conditions, either. You don’t unexpectedly discover that a logical turn takes you into more difficult ‘logical’ space, whereas the digging of a tunnel might take you into muds of different textures and load-bearing capability.

Assuming that requirements don’t change, there should be nothing unexpected when you’re programming, and nothing should get in your way.

So, why is it so difficult to finish software systems on time?

Perhaps the answer lies in the fact that whereas a building is conceived fully before construction starts – its outline, its height, its weight, and all its components and how they’re to be put together – the details of a software system are ‘worked out’ as it’s developed. A full description of it would be the system itself. Perhaps it’s like the development of a mathematical proof. The destination, the theorem, may be known in advance, but the tortuous path towards it has yet to be described. The full description is the solution.

We’re just two days away, we hope, from releasing a new version of time@work. We’re late, of course. We should have been two days away some weeks ago (perhaps months, if I’m really honest). But I’m not complaining. This is the way development goes. We’ve moved the goalposts a little, we’ve found some things more difficult than we’d expected. We’ve reversed out of wrong turnings when the ‘final’ version of a new feature wasn’t as easy to understand and use as we’d imagined. We’ve sometimes not anticipated that a change in one part of the system would cause logical problems in others. Who can eliminate such issues from the software development process?

It happens every time. Even after years, our estimates are sometimes wildly inaccurate. I hesitate to abandon estimation, since in software development you must choose between priorities, and knowing how long something will take and therefore how much it will cost is an important component of that judgement. I’m still not ready to shrug my shoulder and go down the route of ‘It will take as long as it takes.’

But it’s wonderful to be just two days away (or three, or four, perhaps) from Version 5. It’s been a year since we produced a major new release, and this one contains some exciting new features. I’ll list them when we get there in a few days time but for the moment we’re doing final assembly and a bit of cleaning up.

  • We need a revised demonstration database to issue with the new version. Not only must all the data be updated from 2014 to 2015, but changes have to be made to illustrate the new possibilities in the software.
  • We need to update the system help text with text from the new complete reference guide to the product.
  • We need to make some final graphical adjustments (consistent fonts, colours, styles, new login screens).
  • We need to fix some final bugs.
  • We need to  run a ‘release check’ across the entire product to test as many functions as possible in as many permutations as time allows (testing all of them would take longer than the lifetime of our solar system).

We do this with a series of iterations of the product. The problem is that this means we’re tilting at a moving target. I received a new iteration on Friday and worked on it over the weekend. Everything that wasn’t working before worked, but one thing that worked in the previous iteration didn’t work in this one.

Perhaps just one more iteration, today or tomorrow, and we’ll be ready to release on Wednesday. Fingers crossed.

FPP – A Frightening Acronym

Share

There’s nothing more frightening in the world of consulting, especially IT consulting, than the Fixed Price Project (FPP). We avoid them if we can.

Customers, on the other hand, love them, or the idea of them. And they often set out on their software procurement path with the conviction that it’s their best option. But for both parties, supplier and customer, the result of a poorly scoped FPP can be disastrous, with the customer rueful that he didn’t describe his requirements precisely enough, and the supplier digging in his heels and delivering only what has been precisely contracted. Even if additions to scope are carefully managed using Change Request Procedures the final result will come at a cost to the customer that is far higher than anticipated.

FPP

The problem is that knowing precisely what is needed in advance is difficult for the customer, and understanding precisely what the customer requires is difficult for the supplier. If the project is a large one, and will bring radical change to an organisation, you really need to do a scoping project before the real project begins, but most customers are reluctant to approach FPPs that way.

LLP Group and systems@work regularly undertake FPPs but always cautiously. Generally we work with software that is configured rather than adapted at source code level, and this helps, since the configurable options are constrained. When a software package allows unlimited possibilities through source code change and extension, the dangers are huge.

We’ve tracked the difference between estimates and actuals for FPPs over several years using our time@work professional services management product, and the results are not entirely as I would wish them to be, though there’s a gradual improvement. In recent times we’ve end up doing about 25% more days’ consulting than initially estimated.

FPP Trends

These are some notes I’ve written for our sales and project-management teams on risk avoidance:

Notes on Fixed Price Projects

Fixed Price Projects (hereafter FPPs) often end tragically, with actual consulting and development days greatly exceeding estimates. They can result in bitter argument with the customer, who may believe you have promised him everything for nothing.

The key to happy FPPs lies in intelligent selling, intelligent estimating, intelligent scoping and contracting, and good commercial project management. The key to the avoidance of bitterness is good management of client expectations.

If client expectations are not managed well, these are the possible outcomes:

  • In a minority of cases, a profitable project delivered on time and on budget, and a happy customer (who doesn’t know how lucky he is)
  • More often, a deeply unprofitable project and an adversarial client, or,
  • Worse still, legal action

If client expectations are managed well, then a good outcome might be within your grasp:

  • A profitable project (even with all necessary extensions) and a reasonable and satisfied client

Selling

Managing client expectations starts during the selling process, when you must help the client to understand how things look from our perspective:

  • That FPPs are a risk for us, unless we know clearly what he expects, in advance
  • That FPPs depend as much on his contribution to the project as on ours
  • That, in return for the risk we take, we must impose reasonable constraints on what can be expected and what can be delivered
  • That both we and the client benefit from an appropriately constrained project, in terms of delivering benefits on time

Often the client thinks it’s obvious what he wants and needs and he’ll say things such as:

  • We just need what everyone needs. Nothing special. It’s obvious.
  • You’ve done all this before. It’s what you do. You know what we need.
  • I want what that other client has.

In the face of such confidence it’s difficult to demur and say, ‘Well, actually, I need to know more. I need to ask you some questions.’ The temptation is to say ‘Yes, I can do that.’

But never say ‘Yes, we can do that’ unless you know precisely what the client means by ‘that’ and you can make reasonable estimates as to how long it will take us to do it. You’ve got to make the client understand that our profession has its established ways of doing things, that this involves questions, discussions, presentations, analysis, imagination, design, and so on..

It’s even possible that by insisting on our processes, and through seeking a detailed understanding of what the client wants, by showing that you can describe it well, and appreciate the benefits it will confer, you are also establishing your own skills in his eyes. ‘Yes, we can do that’ tells the client nothing about your own skills and understanding. Don’t forget that saying ‘That can’t be done at reasonable cost’, or ‘We don’t think you should do that’ can impress the client even more, if done well!

The process of selling an FPP has to be even more disciplined than the process of selling a time and materials project. Time spent describing the client’s needs, outlining a solution, demonstrating your understanding and wisdom, even if this time is commercially non-recoverable, is time well spent, especially if it’s accompanied repeatedly by assertions and explanations that the client will get ‘that’ and only ‘that’, unless changes are requested and estimated separately during the course of the project.

And it’s important that until there is a clear description of the client’s requirements and a proposed solution, nothing should be said about price. And, even more painfully, nothing should be said about price until our consulting team (and that means at least one good consultant and a services manager) have given you some idea of how long the project will take. Regardless of how many days you’re going to sell, you must know accurately how long it’s going to take.

So, to summarise, an FPP price proposal must be preceded by:

  • Your establishing the consulting process in the client’s mind
  • A detailed description of the client’s requirements
  • An outline of the solution you propose
  • An estimate of consulting and development days signed off by a senior consultant and a services manager, with material assumptions clearly documented
  • Confidence that the client understands the FPP game

In fact, client expectations are at the heart of the entire process from selling to delivery. There must be a continuous and seamless process, beginning with sales, that aims to establish optimal client expectations:

These include:

  • That in return for taking on the risk of an FPP we expect that the client will meet reciprocal obligations:
    • Accurate descriptions of requirements
    • Timely and accurate delivery of data and clarifications
    • Cooperative and positive behaviour
  • That with the best will in the world, we, and they, will make mistakes
  • That client staff must expect disruption and in some cases a heavy commitment of time to the project
  • That software is fallible and that bugs may need to be corrected before go-live or worked around
  • That software development is notoriously difficult and that perfection is expensive
  • That our fee rates are reasonable, based on the utilisation we expect, our investment in training, the relatively high salaries that consultants command, realisation that is lower than 100%, management costs, and overheads

 

If all of these things are clear during the sales process, then there’s a chance that we and our customer will end up satisfied.

Next time, some notes on Estimation.