What if your project starts after the project ends?

This is going to be just a short series of entries just to log what is brewing up in my mind after seeing similar patterns in different projects.
It starts as a multimillion project, on one side there is a legacy system on another side there is that shiny (n/t) “product” they sold to the customer who was really struggling with previous XYZ product.
There was 2 years spent with migration of data and integration of the product to the customer’s system. After 6 months of integration and UAT tests, it is finally a time to turn the switch.

And now it happens, it turns out that this paper system could never work like expected. Why?

There was range of factors that made the product unusable on a customer terms via hidden architectural and implementation specifics like product is not robust at all, hard to extend to the customer requirements they came up with after going live. Those are architectural features that are hard to measure and test before going live.

So go-live is the only ultimate test that product can really have in my opinion.

And here I’m coming to the point of this entry. I believe that project not ends, but really starts with go-live and if your team/company just gives up on it at that time – this is the direct way how to loose this battle, your customer and future income.

All those paper-based requirements and products, missing qualities, all those compromises you do – sometimes there is no other choice to achieve the go-live. But count with go-live being actually a start of your real battle for the customer.

In the latest circumstances I actually joined the project as a part of a small rescue team after go-live with a totally given up customer and project. We have not rescued the project/customer yet, but the path of rescue looks like some pattern to me again – let it be the subject of the next post.