This project was doomed to failure.
- Client involvement was minimal. There was no clear requirements definition, the client only appointed a business unit manager as single point of contact. But this manager had many other things to do, more important to her than “taking care of the system”. There was no infrastructure to support the system in production.
- Requirements were complex: the system to build was a customized ERP incorporating the client’s business processes and rules – which were very different from what commonly exists. This ERP should manage contracting and offering, clients and prospects relationships, invoicing and payments, stock and inventory, bar sales, accounting statements and much more. And it had to be used in a multi-tenant model, various geographically distributed business units using it independently.
- There was no room for late or low quality delivery. Not without reason (see above) a previous attempt to build the same system went wrong and the client had already lost patience.
Despite of this, the project was a great success. It has been developed on budget and now runs smoothly 24×7.
And probably the most interesting: it has been developed by a single developer. Working half-time.
I could write about the details of the process used, but processes should be implemented for a reason. And there is two fundamental rationales less frequently mentioned.
- Manage your client’s expectations. Or, in other words: client confidence through contractor accountability. We repeatedly delivered what we promised thanks to an incremental development approach based on the agile principles. And we were very, very careful with requirements and change management. Be prepared: you will someday have to gently prove to the client that he is the responsible for some problems or delays.
- Manage your software architecture. We were really intransigent about architecture coherence and code quality. This is a sine qua non condition for the development to continue at a constant pace. The system was too big to live with a technical debt. One key there is probably: maintain the design clean enough to allow for constant refactoring.
Of course, there would be a lot more to say. Do not hesitate to leave questions or comments