Predefined, is it?
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 spreadsheet 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.

State it explicitly
“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”.

Later in the evening, as the discussion continued over drinks, with rising ‘spirits’, the voices became louder, the emotions hotter, and the language looser. It so transpired that all of them had a few common service providers and solution vendors; stories exchanged may stay in the room but the lessons may be shared.

Implementation hassles

Most companies have common groups created with IT and business participants to explore, evaluate, and decide on solutions. These heterogeneous groups are typically led by the CIO or a senior IT leader who orchestrates the process. The process is similar across companies, with one or more of the following steps involving RFI, RFP, Demo/POC, business case, budget approval, negotiation, and commencement of the project. A few vendors in their excitement sometimes try to take shortcuts which almost always result in unpleasantness for everyone.

But the more interesting phenomenon occurs when solutions don’t really meet the functionality requirements by a reasonable margin, but the sales person, in his desire to meet monthly/ quarterly—or whatever—sales target, pushes ahead with the desperation of a man clutching straws to save himself from drowning. Everything then seems possible with a tweak, a small code change, customization, bolt-on systems, or some to be released fix in the next version or patch.

Stick to best practices

The resulting tragedy of errors, omissions, round pegs in square holes and heartburn caused to the IT and business teams is imminently avoidable by following the process the way it should be, the urgency on the part of the sales person and his/ her manager ensuring that targets do not override good business practices. It is not okay to withhold information or bend the process to fit the tools, neither it is acceptable for the CIO to allow leeway in the due diligence process. Even with rigor practiced, it is probable that some critical elements may remain uncovered. The business and IT teams will have to manage such exceptions (not a rule).

The luxury of time always eludes us in such activities; many a time deferred decisions put pressure on delivery of milestones, thereby compromising quality or extended time lines and sliding targets to fix issues that could have been avoided with collaboration from both sides. Good practice is a result of everyone being on the same side of the table; a skillful CIO should and will recognize the body language when the problem is being twisted to fit the solution.