Recently in a bank a program was initiated to develop a new platform to centralize data from various sources. The program consists of three teams: business analysis (BA) team, technology development (Tech) team and architecture team.
The BA team and Tech team together collected information from business units, based on which high level business requirements were drafted. The architecture team came in and conducted proof of concept based on the high level business requirements.
In this case, without having to go through too many iterations, the architecture team made recommendation of a new tool. The solution looks great from every aspect. The decision was made to proceed with it. However, shortly after, the BA team and Tech team encountered numerous implementation challenges. They turned to the architecture team for help, but the latter already moved on to other projects because they considered their job, which was to finalize the architecture blueprint for this program, was completed. A few months passed, the program deadline was approaching, the Tech team didn’t make great progress, nor did they have smooth communication and coordination with the architecture team who believed that the implementation of their recommended tool was not done right. Finally, it came to a point where a trade-off decision had to be made to reduce the sunk cost. The teams sat down together again to evaluate an alternative. The new solution was not as elegant as the original one, but hopefully it would work.
What went wrong?
On the surface, the problem is that there are significant gaps between the proof of concept and implementation details. Naturally, not a single team considered they were accountable for the failure. The architecture team said they had great constraints that the business requirements provided by the BA team were not sufficient for the purpose of conducting proof of concept, and mistakes were made in the implementation by the Tech team; the BA team argued why the architecture team didn’t do their due diligence, including not asking for more granular business requirements if needed; the Tech team could not understand why the architecture team proposed a solution that was very difficult, if not impossible, to implement, and then just left them dry on the beach without offering further help and advice. It became a finger-pointing political game with a significant sunk cost, which would be borne by the company stockholders.
What could have been done differently to achieve a more efficient project delivery?
Business Requirements vs. Proof of Concept
The proof of concept was based on the business requirements. However, if the business requirements turned out to be too high level, but it shouldn’t really matter. For a large-scaled complex project, using water-fall approach to identify and complete all detailed business requirements before implementation would be very challenging and inefficient, if feasible at all. This is exactly the reason for conducting proof of concept.
The purpose of proof of concept was to make the stakeholders to get a feel of how the final deliverable product is like. If the result deviates from the stakeholder’s expectation, teams can re-group. Perhaps an alternative solution will be sought, or the business requirements will be enhanced or even revised, and another round of testing commences again. Eventually, the expectation from all parties for the final product is aligned.
Team Commitment
Not long after providing the final architecture, the architecture team removed themselves from the project because they did not report to the Project Manager and their commitment to the project was not made to last till the final product was successfully delivered. This is not to say that the solution from the final architecture design cannot be changed dramatically during the course due to various reasons. Regulatory timeline, unexpected high cost and implementation challenges are valid factors for change. The key is, there should be a dedicated architecture team reporting directly to the Project Manager and working closely with other project teams till the end. If the commitment by the architecture team is not just to provide a possibly implementable final architecture, but like other project teams, to contribute to the final success of the project, their attitude and behavior would have been remarkably different.