Financial Management and Reporting tool replacement
A critical tool replacement has been left for so long that the legacy system no longer has support and current versions of browsers cannot be used to access it. The project budget is tight and the schedule is even tighter. All the earmarks of a project ready to fail.
The backdrop
The client has put themselves in a difficult situation where a critical system is on the brink of collapse. They have found a replacement tool and the vendor has recommended an implementation partner who is highly experienced in delivering the technical solution. We all sit down to review the plan. The schedule is tight and counts on everything going right. Management have set unrealistic targets and no one is able to convince them otherwise. Good sense tells us all to walk away but we have salaries to pay and the market is tough. What the hell, let's give it a go.
Our role
We are hired in as solution developers. Our role is to work on the client side to make the deployment happen. In practice this means everything from requirement validation to project managing integrations and specifying reports. Communications and training is thrown in as well as helping support the data migration. Fortunately an off-shore partner is allocated to handle testing of the solution and another off-shore partner will code the integrations.
Key challenges
The project team has been put together by the client from a multitude of vendors. The experience level of the people varies greatly and most of them have not worked together before. Apart from the tight schedule, the project has a high degree of complexity and is heavily under resourced. All these factors create added risk for the team being able to deliver the needed high output.
The master data is wide in scope and multi layered. It requires a lot of preparation and validation. The off-shore testing team turns out to be a big disapointment.They require detailed oversight and instruction and the results are questionable. There is little interest from them to learn the system.
Quality is not what it should be and this has a hit on the confidence the Key users have in the work that is being done. Senior Management still have their head in the sand and push the project forwward at full speed. We are regretting that we ever got involved but it's too late now, we need to salvage this. Our hard earned reputation and professional integrity is on the line.
Success factors
Believe it or not the project actually succeeded. But it was not without two project members going on long term sick leave and another one quitting. The first success factor was percerverence. Every waking hour was spent solving the most critical issues. When we fixed something we fixed it properly until we were 100% sure it was not a problem anymore.
We communicated very openly and honestly about the problems and worked closely with the key users who were validating the system. This high level of trust and cooperation meant we earned back their confidence with blood sweat and tears.
Conclusion
Wisdom sometimes is knowing when to walk away. We probably should not have taken on the project but sometimes the biggest mistakes teach you the most. This project ended well but it could have easily not. We got very lucky with the Implementation partner. They were highly skilled, flexible and dedicated to make it work. The client side project resources were also very competent and committed but unfortunately were let down by the unrealistic and inflexible demands of their senior management.
Rule number one is to be realistic in the planning because reality will happen anyway. We went live pretty close to schedule but we used a lot more time after go-live to get the quality up to where it needed to be. Our key users were patient and understanding but it is not always that way.
