Monday, October 01, 2012

Requirement gathering, the saga ends

A heated debate ensued between the two project managers, from the development vendor and the customer respectively on change in scope of the project. This was not a late stage discussion or changes requested during UAT; in fact the project was just a week old with the Requirement Specifications still being formulated. The key user who was also the subject matter expert sat through the charade wondering where she should step in. With no resolution visible, they all decided to go to the CIO for arbitration.

It was supposed to be a quick win project that typically delivers what everyone refers to as low hanging fruits. The project brief was a working model on a spread sheet of the solution to be developed. So it was assumed that the solution should be easy to create and scale up. The timelines and costs were agreed to and the vendor team arrived on site to finalize the project scope and integration points. So what could be the reason for the conflict ? If something is working, how can requirement change ?

The CIO heard the point of view from each stakeholder, the user, IT project manager, and the vendor. For the user, she had clarified how the model worked and what was expected from the system that the spread sheet was unable to deliver; the IT project manager stressed upon the integration to various masters and the scalability expected of the solution; and the vendor project manager completed with a complaint that some of this was not in the original scope that was outlined prior to commencement.

So what was the issue asked the CIO ? Wasn’t the current discussion to clearly define the functionality expected from the system ? Where is the conflict in the integration definitions ? Does expansion of the concept and explaining in detail qualify as scope enhancement ? They had an advantage over a standard software development model that a working prototype was available. There was a discomforting silence for a while until they all decided to go back and close the discussion amicably.

So when I bumped into the CIO many months later, I enquired about his story from our last meeting. He mentioned that it had gone live but did face challenges in the initial days. This was discovered during deployment that the system needed elaboration.  The functionality was evident common sense but missing from the system (I shall not get into the details here which my CIO friend explained to me to my surprise). He quizzed the team for the missing parts of the whole; the user said it was obvious, the PM agreed, the vendor did not.

It is not in the system since you did not ask for it. Technically correct but does not solve the problem. So now that the system is accepted, deployed and support phase over, this is a Change Request and will have to be managed as such. The ineffectiveness of any argument was evident and the only recourse was to give in to the demand in the interest of the project and the business. That vendor has not been welcome to new initiatives since then; even the support has been moved to other partners.

My friend the CIO had no recourse ! Do we ? With the outsourcing trends taking the direction that they have, everything has to be now explicitly stated and included as a part of the Requirement Document. If you do not have an internal team of business savvy IT team members actively involved through the cycle such outcomes are quite likely. Invest in your team, keep them actively involved in the project and not just to manage at a high level. Keep a watchful eye open. Assumptions hurt; try “ass u me”.

This is hopefully the last post in this series. If you would like to see the earlier ones, they are linked below:

No comments:

Post a Comment