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