Implementing an ERP - is it really like building a house?

We love a good analogy in the IT industry. When trying to explain a concept, instead of explaining it in a clear, coherent way, we often choose to take the route of metaphor, to help you understand us!
 

‘OK, imagine a software implementation is like building a house…’ we will say, ‘so we need an agreed design, an architect to decipher the complex points...’ and so the analogy goes on, right until the ‘and finally we’ll do the snagging’.

This analogy starts early, when the customer says ‘So why can’t you give me a fixed price to implement the system? If I built a house they’d give me a fixed price.’ If putting in an ERP solution is like building a house, then what can we learn from that analogy? Plus, aren’t all software vendors cowboys?!


Let’s start by answering that last point. No, not all software vendors are cowboys! In fact, in my experience the vast majority of software vendors are very well intentioned people working hard to help customers in projects that are, for many reasons, challenging. This is also true of my personal experience of the building industry… Both industries have their share of cowboys, and both have their share of well-meaning but inexperienced and poor executers of their trade.

In my experience of building projects, often a ‘price’ (i.e. a costed and agreed quote) rarely ends up as the ‘real price’ and the amount left in my wallet at the end of the project has always been substantially less than anticipated. I am sure many people have had a similar experience with IT projects, so really, aren’t the difficulties in building houses and building an IT solution actually quite similar after all?


Let’s start with the ‘why can’t you give me a fixed price’ for the IT solution. I am asked this at least once a month and often after the customer has given me and our sales team an Excel sheet of 100 textual comments and talked for a few hours.


So while a builder may indeed eventually provide a price, the elements are the same for both projects:


There are a bunch of definable fixed things we know. E.g. The builder may be using a ‘Potterne kit timber framed house’ and therefore knows the cost of this. The software people can tick the relevant modules on the price list of the software and add the number of users to get a software value.


There are a bunch of things that we know exist but don’t have the specific detail. e.g. the specific kitchen, the exact door type and door handles for each room and the precise bathroom fittings are often left as allowances. The software people will be able to suggest a number of days training that they have allowed for, but humans are funny things and as variable as door furniture. Some will need more training, others less. In these cases the cost will vary above or below the 'allowance’ once the final decisions are made (which is often late into the project).


There are elements of complete unknowns. The building client may be thinking about adding a garage but at the start of the project unsure of the size and as yet without permission. IT customers will often have ‘possible integration to a third party warehouse’ that they haven’t yet chosen or may be opening a company in Brazil later in the year, and these elements can only be given an order of magnitude.


There are unforeseen elements: Your other half suddenly decides it is imperative to have oak skirting boards and an oak conservatory, or you find an old Roman fort when digging the foundations. The Finance team decided they really wanted to have OCR recognition for invoices and expenses, or the WIFI in the warehouse doesn’t reach all the aisles so handhelds don’t work.


In both cases the ability to estimate ‘the project’ is predicated on how much is known, how much is ‘we know we need this, but we don’t have enough detail’ and the final ‘wow, we never knew we would need that, but we do!’


To quote Donald Rumsfeld, at least partially, ‘We have known knowns, we have known unknowns and we have unknown unknowns.’


As with any service provider, the costs are largely time related and the accuracy on pricing a job heavily depends on how much we know. The more we know, the more accurate the price.


Of course if we go back to the very basics at the beginning of our project, before we get any price from our builder friend, he will want professionals to be paid to produce architectural drawings precisely stating where all walls will be, what materials will be used and where all the windows will be. The architect in turn will need to pass on the cost of the structural engineer who has worked out the precise width and length of the RSJ beam supporting the upper floor and the steel that supports the roof in the kitchen.


In software terms these architects will similarly need to design which major structures of the application set will be deployed to support the recurring billing process. Should the service management contract process be deployed or will the light recurring invoice process suffice? Should we use Dynamics NAV’s built-in CRM module, or use the generic Microsoft Dynamics CRM?

the more we know, the more accurate the price

The more we can create ‘known knowns’ the easier it is to estimate and the more accurate that estimate is.


BUT, and here is a big BUT. Not all costs are in the project. As our builder is plastering room after room, the owner of the house is busy buying Farrow and Ball paint. The builder has only estimated for completion to an undecorated state as he knows the client has a friend who’s a decorator. Of course the friend isn’t under the builder’s control and can’t start for a month, but the builder needs to get the first part of decorating done so he can fix the skirting boards. The decorating friend will still need paying but this wasn’t in the estimate from the builder or in the client’s Project Costs, so there’s our budget growing a little more.


Just talking about the customer side, often in a building, the project manager is you. And have you noticed how many building project TV programs have huge projects where the clients say ‘we are going to project manage this ourselves’? ‘Have you done this before?’ says TV presenter, ‘No. First time’ they respond!


It’s frighteningly similar in software projects don’t you think?


We often engage in conversations that go something like, ‘don’t include data migration, we’ll do that ourselves’ and ‘we have a guy in the business who does some report development, so he’ll do the reporting we need.’ Both are excellent ideas and just like the decorator friend are not a problem as long as the project delivery team are not held up by resources outside of their control. And while you may not be paying a partner to do this work, don’t forget to include their cost, as it’s not in the estimate.


As it’s very common for the customer project manager to be running their first significant project.


Be wary, software projects are complex, they involve people and technology, nearly as dangerous as children and animals to the untrained! It is very common for a customer project manager to be running this as their first significant project but someone who doesn’t know what they are doing can be more of a hindrance than a help. I would never try and get involved in building work, it’s not what I do!


To finish our analogy and to see where ‘the money went’: we now have a newly remodelled house, and ‘someone’ has purchased an 80” LCD TV for his new study. (Now a beautiful shade of Farrow and Ball). Someone’s wife, as is right and proper, decided to involve the wider team in decision making, leading to the eldest child’s bedroom being repainted three times as they could only visualize what it would look like ‘when they saw it’ and the youngest child is now regretting the decision to have a portal for a window as they didn’t think about the lack of light that would be coming in. This can of course only now be rectified at great expense.


Oh and of course your mother-in-law got her say in too, and the late decision to replace the shower in the guest bathroom with a roll top bath could be a significant, unbudgeted expense. Finally, the Client Project Manager is still buying unbudgeted curtains for each room (can’t use those old ones), leading to the need for dozens of new matching cushions and a final change of mind on the installed kitchen worktops.


I suspect I need not replay the analogy of the software project?


To end on a note of encouragement. On every building project I have been involved in (yes there is a little of my own story here!) and the majority of building projects watched on TV (quite a few), they all end up something like our example. While they may be challenging, and involving not an inconsiderable amount of stress and effort, these projects can provide huge benefit, enjoyment and that ‘why didn’t we do this earlier’ feeling!


In summary, there are lots of similarities in many large projects that involve the moving elements of people, emotions, timescales, business and personal demands and sometimes nonaligned or ill-defined goals. An important point to consider is to choose your service provider wisely, maintain trust in those delivering/receiving, keep open and honest communications, and keep a big list of all the things to do! All successful projects are the end result of a giant to-do list, with the important ones completed at the end. 

Read more