Every new project brings on new challenges and experiences. Successful projects tend to become a good reference; for me personally, many of my best business relationships have been formed while part of an effective project team.
But the projects that maybe give the greatest learning experience are those that fail. This is a story of a failed LS Retail project (yes, these do exist!).
The project
The project began like many others. The customer attended some demos, saw our latest technology and finally decided to implement a state-of-the art retail and hospitality solution. All of the preliminary work took time, and when the contract was finally signed, there were only a few weeks left until the grand opening date.
From the outside, this was a small project: a few dozen terminals, little or no customization required; in total, the scope of the project was just a few hundred hours.
In retrospective, the project was bound to fail; however, for some reason none of us participating in the project foresaw this.
The mistakes
During this project, we made all the common mistakes:
- The requirements were too vague, and responsibilities were not clearly divided between customer and vendor. We thought the contract was clear, but the customer did not read the details the same way as we did.
- The scope kept on changing as new needs arose — and there was no formal channel to deal with scope changes.
- The timeline was very short, and as the customer’s store was still under construction up to the last minute, the focus of the customer was very much elsewhere. This meant that the setup was not properly verified.
- The project team was probably staffed incorrectly, and key decision-makers were involved too late. The project did have high-level attention from the customer, but everyone was simply too busy with other things to properly focus on an IT project.
- The architecture was complex, with a cloud solution combined with a store server. Although this was probably necessary, it did not make the implementation easier.
- The master data was supposed to come from outer space – or in this case, from a parent company. Of course, the data quality was not as good as expected. Predictable – but still problematic.
- The customer wanted a state-of-the art solution with almost all the service features one can imagine. And of course, the solution should offer detailed inventory control (including assembly products) from day one, as well as automated management reporting, integrations with 3rd party system, etc.
- As the vendor, we wanted to implement our latest technology; unfortunately, some of it had not gone through proper testing.
Now, imagine: all of these issues – and a project that was supposed to go live over the course of just a few weeks, in a store that was still being built.
But that’s not all – we made another mistake, probably the biggest one yet. Our mistake was that everyone forgot the “why” of the project.
The why
Why are we doing this project? What are the real needs of the organization (customer)? This is, unfortunately, a question we never asked. Had we done so, the project would probably have been at least a moderate success.
In this case, the organization’s real needs were quite simple: providing good customer service, and having adequate reporting features within a few weeks from signing the contract. Nothing more, nothing less. Everything else that the customer asked for, and we tried to deliver, were simply unnecessary frills considering the resources we had.
The lessons
Failure is a great teacher – at the same time, nobody wants to fail more often than necessary.
How do we avoid making the same mistakes again? Here are six lessons I learned from this experience:
- Clearly define and control the scope of the project. Documentation, checklists and project management help a lot. Try to avoid scope creep.
- Risk management is a must. Identify the main risks, discuss them openly with the customer and suggest possible mitigations.
- Think lean. Are we trying to implement unnecessarily complex systems and processes? Less is often more.
- Staff the project correctly, with high-level attention and low-level commitment. Identify key players that need to participate, and make sure they are available.
- Make sure to ask the why question – what are the real needs of the customer? The why question is critical, especially in a project constrained by time and other resources.
- Any IT solution should exist only to support the relevant business. Don’t implement IT for the sake of IT. A good IT solution can surely be a competitive advantage as such, but first and foremost it needs to support the company in serving its customers and doing its business more effectively. Anything else may bring on some unpleasant results.
And remember – there is no such thing as an automatic washing machine.
Article written by Stefan Georgsson
Development manager