Showing posts with label software evaluation. Show all posts
Showing posts with label software evaluation. Show all posts

Monday, November 21, 2016

When buying software, buy shallow, buy deep, but buy anyway !

Case 1: He got a call from head of manufacturing to quickly meet to evaluate their solution; surprised, the sales head rushed to the meeting taking the next flight available. The caller represented a large enterprise that had invested in much IT and this was a new opportunity; the solution was used by other industries, but not this one. The solution was niche with limited competition, the sales head knew that competition had not yet got a whiff of this; he landed in front of the team that included staff from IT and operations.

The discussion unfolded with the articulation of the need and the business case around it. They acknowledged that the solution had traction in other industries, but they believed that as a pioneer much value could be captured if the project succeeded. Appreciating the forward thinking, technical resources were allotted to the customer to sketch out the detailed use case. Within identified constraints, the solution fit well though partially fulfilling the business case, the team pushed the vendor to provide a solution architecture.

Back and forth they went refining the solution, steps that exposed the superficial thought that conjured up the project; as the urgency died down and the timeline continued to shift, the sales head lost patience, getting the short end of the stick on sales conversion of a purported hot prospect that had consumed significant time, effort and sales budget. The functional teams much wiser through the discussions had begun to like the specific solution; they however were unable to push the timeline for decision making.

Months passed by, the aspirational go-live date came and went, the evaluation data exposed the shallow approach taken in their ignorance and lack of understanding of the complexity. They realized that they needed to revisit their assumptions, recast the timelines and budget to get it right first time. The smattering of smaller vendors who had engaged earlier had blinkered view of the elephant and solutions offered to address limited parts; unwilling to let go, the ally vendor demonstrated patience as the months stretched into a year.

Case 2: In a high growth industry, the company was beginning to feel the pinch with lower than benchmark profitability. They were growing faster than the industry and at times had to refuse business as they could not hire fast enough or deliver service to customer satisfaction. They knew that technology could help their business and thus started evaluating local and global solutions. The business head after meeting a few vendors was confused by the choices, so a cross-functional team was put together.

The team diligently evaluated options and as a starting point put in a part that appeared to be a low hanging fruit. The solution worked as designed but people ignored it citing operational hurdles. It was quickly parked in the technology orphanage and a consultant was approached to help in determining the best way to solve the problem. She recommended reassembling the cross-functional team to document processes, optimize and define the to-be process against which the solutions can be benchmarked.

Supported by the COO, the team worked to create the document which was reviewed along with IT to formulate the RFP. The Group CIO put his hat in the ring offering to run the process with his trusted lieutenant who at best was better than average.  The team would meet every fortnight to review progress made, tweak expectations and proclaim complexity larger than anticipated. The detailing of processes continued for the time period in which the consultant had proposed to complete the implementation !

As they approached the anniversary of project initiation, the team had evaluated multiple local and global solutions; the IT Head hired early in the evaluation had defocused from this critical project, now spend his hours in creating incremental technology solutions akin to Band-Aid. The business head wanting the best shot at the project continued to support the team which continued to refine the spreadsheet ad infinitum. The consultant occasionally followed up and realized that a decision was a moving target now.

In both cases different factors contributed to inaction or no decision in the timeline that mattered to the company and the business. The first did not know what and how, the second procrastinated on the decision refining their requirements, solution design, and future, in an ever changing world. Both had different drivers and contexts, both ended up disadvantaged, the first losing the pioneering opportunity, the latter experiencing slowing growth and profitability. After a while it really did not matter if they finally got it right.

It was a collective leadership failure !

Monday, May 30, 2011

Don't turn my problem into your solution

It was an interesting meeting of a few CIOs with the debate revolving around IT Governance. From all types of models being discussed, the common subject of woes shifted to Business Intelligence. All the CIOs present had large investments in BI with varied degrees of success, some more than the others. Everyone acknowledged the presence of multiple tools and technologies with no single vendor’s ability to address the wide spectrum of needs. It was evident that their respective enterprises had reached a level of maturity in adoption of IT that would be the envy of many larger and smaller companies.

Later in the evening, the discussion continued over drinks and with rising spirits, the voices also 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 stayed in the room but the lessons can be shared.

Most companies have common groups created with IT and Business participants to explore evaluate and decide on solutions. These heterogeneous groups are typically lead by the CIO or another 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 and budget approval, negotiation and commencement of project. A few vendors in their excitement sometimes try to take shortcuts which almost always results in unpleasantness for everyone.

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

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 practised it is probable that some critical elements may remain uncovered. The Business IT teams will have to manage such exceptions (not a rule).

The luxury of time always eludes us in such activities; many a times deferred decisions put pressure on delivery of milestones thereby compromising quality or extended timelines 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 skilful CIO should and will recognize the body language when the problem is being twisted to fit the solution.