Will business leaders stand up and take responsibility for Digital success or failure ?

Recently came across an interesting article on “Why IT projects still fail ?” and the subject caught attention as it is still being discussed. It had references to some spectacular failures where the blame was squarely placed on the implementation partner; another one where business users at the bottom of the pyramid showed spirited resistance to the new way of working. Finally it quoted the most popular reference on IT projects with limited change in results over score of years with IT Business Alignment retaining high marks.

Reasons attributed to the dismal success record included inadequate resources, overly aggressive timelines, underestimated costs, overlooked requirements, unanticipated complications, poor governance and human mistakes such as bad code can all lead to project failure. Surprisingly a quote “the definition of success is evolving with traditional measures of scope, time, and cost no longer sufficient in today’s competitive environment. The ability of projects to deliver what they set out to do — the expected benefits — is just as important.”

Everything pointed the finger at IT; they are understaffed, overpromise, don’t know how to estimate costs or gather requirements and stick to them and finally are bad project managers. Also I am not sure about the world the respondents of this 2017 global report live in if they do not articulate the benefits in business terms. Okay, I take my words back, I do know of a few who still are unable to, but those are exceptions. Interestingly the article goes on to define formula for success without addressing the core.

So I dug a bit on the background of the author and found no evidence of having either run an IT shop or been at the receiving end. The article was an observation based on statistical evidence from various reports and the hypothesis that has lived for long: IT does not communicate, IT does not know the business, IT needs to sell the project to business, IT should prepare a business case and illustrate the benefits, IT should get the budgets sanctioned and then monitor time, cost, resources, success, failure, … really ?

Let’s for a moment shift focus from IT to the business folks; business models have undergone major upheavals and digital has been thrust upon the willing and unwilling alike. Majority of the incumbent leaders and giants have been slow to react – unwilling to accept reality brushing it off as irrelevant – and then finding someone (read IT) to blame for not delivering in (the constrained) time while the new players have eaten market share. They have treated the change like a technology project rather than technology enabled business transformation.

Success stories are all about the handful of enterprises who decided to create cross-functional teams to evaluate and respond to the upcoming opportunity. They did not hire consultants to give them a roadmap, or define waves of implementation, or hire from outside to lead the internal team; they were willing to change, explore, experiment, willing to take risks, and understood the limitations of pure technology over the collaborative success that they had co-created multiple times in the past along with IT.

The leaders do not hand off accountability, they find ways to induct others into their vision; they are always on the lookout for creating differentiation against competition. There are no IT projects, only business projects that use technology. Even mundane decisions like cloud evaluation or change in support vendors seek business impact and changed outcomes. IT responsibilities and KRAs are spelled out in business terms; this is the real world of pervasive IT today which has shed the technology skin of the past.

In such a world then why does “Why IT projects still fail ?” still find a headline and mention ? Such reports and publications continue to berate technology teams. They find it convenient to continue using the old scapegoat without looking elsewhere if the paradigm has shifted. So are these about the laggards and disconnected teams who have failed to stay current and relevant in the new normal with shrinking business and loss of customers ? This does not appear to be the universal truth but sensation sells better than reality.

Can business grow up and take responsibility for success or lack of it rather than live in a world of transferred responsibility especially when things don’t work out the way they were planned ? Can the technology teams stop being subservient and stand up to their professional achievement and pride ? Wherever the chasm still exists, can both start by acknowledging it and work towards building a sustainable bridge that will offer achievement of business objectives ? A necessary step to stay relevant internally and externally.

Finally let’s bury IT projects !

Who is ultimately responsible when a project (with IT dependency) fails to deliver ?

Business had worked with IT to select the vendor who came with fairly good references and connected well with the team during the courting period. The CIO found the choice acceptable as the project was fairly straightforward and not much could go wrong in a project that was expected to last 4 months end to end. The CEO of the young smallish development partner took interest in the project with a large enterprise that promised more business in the future should this be delivered on time, budget and functionality.

The project started well with meetings attended by IT, functional teams, and project manager from the partner extending into long sessions; the subject was discussed, debated and look at from all angles to make a better wheel than the wheel required. The scope document went through multiple iterations as the subject matter expert (SME) kept changing parts in every meeting. Keeping in mind the need to push ahead, the CIO brought back the team to focus on the business need and speed to get the product to market.

The SME regaled in story-telling and kept the audience in attention with anecdotes unrelated to the discussion, hijacking the agenda and the project timeline. By the time the project was expected to complete, the team was just about getting ready for scope sign-off. Unfortunately other projects occupied the attention of the CIO which further pushed the timelines. Business had in the meanwhile moved on discounting the impact of the project; to compound the problem, the Vendor Project Manager quit.

The team and timelines were recast with the signed off project scope and the development team got started; the first wireframes were a hit, and the UX fell flat, while the development team struggled to get the new and to them unknown technology stack to work together. Frequency of review sessions reduced as the project red flagged itself on the CIO dashboard. Startled though not surprised the CIO called for an all-hands meeting to review challenges and determine if it made sense to continue the project.

The CIO and the vendor CEO decided to keep a close watch on progress; the solution was tested by the QA team and snag list identified for launch. The first field testing threw the team into a tizzy with UI that was unacceptable to the controlled group and bugs that surfaced. Speaking to the project sponsor, the CIO pushed the vendor and the SME to define the dates by which they expected the project to close. Both agreed to close the project within the next 10 weeks which appeared reasonable to all involved.

As the time drew closer, the vendor escalated pending issues with the SME and vice versa making it an extremely trying time for everyone involved; it appeared that the project would never end while costs had also gone out of hand. It required drastic steps for the project to come back to relevance to everyone involved. So the SME was eased out of the project while all payments frozen until firm delivery dates were met with quality that was the selling point for the vendor during the initial pitch to the team.

Another month later at its anniversary the project finally saw light and was launched quietly; it delivered success to the business despite some competitors having launched similar services. Much to the surprise of many, six months after the project was forgotten, the CIO decided to conduct a post implementation review to assess learning from the project to which he also invited the vendor to capture internal and external points of view, learning and accrual of benefits identified prior to project commencement.

It would be easy to stick the blame on the SME who caused the initial delay, or for that matter on the change of vendor Project Manager; development quality and testing could be touted as one of the causes or the fact that the technology stack was a new one ! What about bad UI or UX which would have been a disaster if launched ? CIO or Business Head not giving it enough attention or as many would say lack of leadership ? Did it matter as the project delivered value and everyone was happy in the end ?

It mattered to the CIO who meticulously documented the milestones, challenges, frustrations, and put them across for the group to review, sleep over and come back with their assessment. A detached view gave everyone the perspective of individual shortcomings and collective reasons for the project delay and the predicament that everyone experienced. The Organization was richer to the learning which raised the bar for future projects and institutionalized the Post Implementation Review process.

I wrote this piece after the feedback I received to my last week's article on CEO choosing an IT Vendor

Fixed bid or Time & Material contract, which one to choose ?

The customer was known to be a tough negotiator; the partner knew it would be a long and tiring discussion going over each and every line item in the contract. They had spent almost 6 months discussing the scope, exclusions, inclusions and service level agreements. Now that the detail was out of the way, the last mountain to climb was deciding the commercial terms of engagement. Both were masters of the game and that made it an interesting setting for others to observe and learn from.

Starting point was the global RFP which had taken everyone by surprise with level of detail and articulation of expectations; none had seen such a comprehensive document clearly outlining the selection criteria and process towards the journey that would select first among equals. It was an important engagement for both customer as well as providers who had reached the penultimate stage towards closure; for the partner it was a long and hard fought battle to emerge as the better player amongst global competition.

Considering deals in the market, the contract value was not very large or the customer a big name to add as a logo; the deal was important in the goals and audacity of what it attempted to achieve. Thus interest from OEMs and partners was definitive with local and global teams from vendor organizations putting their best teams on the job to respond to the RFP and subsequent clarifications. Everyone commended the process, transparency and the professionalism shown by the team through the journey.

The solution architecture was complex yet simple in its design with integrated pieces that made up the whole. It had not been attempted before and that raised adrenalin levels akin to conquering an unscaled peak. With passing time the scope became clearer to everyone with vendors garnering global resources to stitch together the masterpiece. Tough filter criteria eliminated some of the contestants leaving behind a mix of large credible players who imbibed confidence with their brand and experience.

Between the remaining contestants two camps emerged which proposed to use Commercial-Off-the-shelf (COTS) solutions with minimal customization, or setting a foundation of COTS but with extensive customization to create comfort fit to existing processes. Both approaches created the solution demanded by the opportunity though with divergent approaches. Conventional wisdom dictated that minimal customization while a school of thought propagated adaptation to what business can use.

The two approaches demanded alternative commercial models with respective recommendations on why one is better over the other; these were fixed bid versus time and material, the first for COTS, the latter for customized solution; the company had used both approaches in the past though on smaller initiatives with mixed results, neither emerging as a preferred way of working. The current project much larger with budgets that were well-defined, thereby required a very different yardstick to arrive at any conclusion.

COTS fixed bid offered some level of certainty of outcomes, the number appeared large; it also created perception of limited flexibility by which business teams were discomforted. What if the solution delivered does not meet our requirements, what if people are unable to use it as expected, what if it did not deliver promised results ? There were many case studies on what did not work in large projects including for solutions proposed by the vendors; it thus required acceptance of associated risks.

Customized always gives the comfort with the syndrome that I know what I want and I will get it; it leads to extensible timelines and in many cases suboptimal process. Agreed that when completed it is used by everyone eventually; this methodology has been fast losing traction among savvy business and IT folks with the balance in favor of COTS and Cloud hosted for purpose apps. It may sound counterintuitive for someone attempting a project so large and complex, but there were proponents of bending the solution.

Coming back to the commercials, the customer finally decided to take the risk with a fixed bid hoping to pull it off with the bravado demonstrated by some of the team members, acknowledging that the world has moved on. They fought hard on every line item and then some wanting to create an open book costing which eventually prevailed in the interest of the marquee project. Both sides came out of the marathon negotiations feeling exhausted but with a win-win having listed out all possible risks to the project.

The project got off to a great start, did it deliver to promise ? Wait for the next year !

Transformation or Business As Usual CIO

“This is crazy but I am loving it”, so said a CIO who had taken on the mantle to transform the way his company uses IT. He had been in the role for a while and his company was one of the market leaders in their chosen industry; they needed a strong dose of really good medicine to shape up the information foundation. Business welcomed him with open arms, he showed them what was possible, he brought all of them together to the common cause; the company began the journey with multiple projects starting in parallel.

The roadmap drawn and agreed upon, the company created a healthy pipeline of initiatives that would leapfrog the reputation of the company and the CIO. His team rallied around him as they saw a future with promise of good days to come. They believed in the vision and toiled sweat and tears to shed the inertia that was the hallmark of the company. Projects rolled and went live building credibility and adding fuel to the fire of desire; the going was good and everyone loved the orchestration that created music they had not heard before.

Another CIO on the table retaliated with her wisdom of focusing on one project at a time and doing it very well with no window for error. She was a veteran herself though not the visible types but staying in the shadows of quiet achievement. Her journey was of incremental innovation staying close to business and efficiently focusing on getting it right eventually made her slow and dependable. Growing with time in familiar territory her rise was a story of “I will do what the business wants even if it is irrational and requires maintaining status quo”.

Working with a monopolistic market leader, there was no real pressure for majority of her career, the global enterprise driving strategy and direction while controlling local innovation in areas that mattered. The rest was about creating solutions that worked to digitize existing manual processes. She had toiled diligently and grew through the ranks doing a fair job of maintaining status quo. By virtue of the years in the company her understanding of the business was good and she had built empathy which helped her.

The two were a study in contrast in their approach to partnering with business and how they created value for their respective enterprises. It was a function of market dynamics as well as individual desire and capability to be a transformational leader. One demonstrated passion and a sense of urgency while the other was happy to be an order taker and wait for something to happen. The group of CIOs present took sides with many inclined towards aggression though most professed that a middle path is the best approach to staying relevant to the business.

A few years later many of us happened to meet again; reminiscences of the last discussion offered an opportunity to check how both had done. The transformation aspirant had slowed down a bit though he was still miles ahead of the conventional pace of implementing technology solutions. He had more or less delivered to promise with the organization struggling to keep pace with the fast track path they had chosen. He was satisfied with the change he had architected and the fact that his company was a much sought after customer by many IT companies.

The lady was struggling for survival, her company having been acquired, new set of expectations, new pace of change, new set of deliverables, all of which were alien to her. Her incremental approach was seen an unaligned to new business speed and the urgency to expand market share and dominance leveraging technology. She was unable to step up having lived a life of a passive though reasonably effective partner to the business. Having worked for one company all her life, she was clutching straws to save herself.

Our collective wisdom could only recommend that she seek alternative pastures before she becomes irrelevant to the company. Her shallow experience did not give her too many choices which she realized. Someone suggested to the aggressive CIO that he hire her to run the operations and business as usual which she was good at. Today most CIOs do take on multiple projects which is the need of the hour to stay relevant; it is a rare luxury to not do so and fraught with danger for the long-term. BAU does not require expensive resources.

Where are you in the continuum ?

Formula One IT

Congratulations for being the chosen one ! The business likes your solution and we are also fine with the technology, functionality and customer references. Now that we have an agreement on the price lets quickly get legalities and other formalities out of the way. The process for PO creation and other paper work will take another couple of weeks. The question is how quickly can you allot resources to our project ? I do not believe that we need 3 months to get the solution off the ground into a pilot or for that matter go-live.

Any objections to aggressive timeline expectations from the customer are brushed aside citing urgency in business need and the dynamic business environment. Software vendors sheepishly accept the modified forceful project plan which assumes turnaround of all documentation from users with no delay or for that matter existence of clean data. Idealistic as it may appear both sides approach the project with enthusiasm that is outward for the vendor who is happy to get the business. D-day arrives and the project kicks off with much fanfare.

This situation has occurred a lot more often than gets visibility; time to market expectations from commercial-off-the-shelf software implementations (leaving aside ERP type solutions) are getting shorter. Most of them offer standard process automation or functionality that is typical across companies. Thus with basic configuration and some integration the anticipation is that the solution will be up and running in no time. Reality however bites every time with outcomes that do not live up to such expectations exposing the fallacy in the approach.

Analyzing scores of such projects undertaken by many of my peers the discovery was not very surprising. The facts were largely consistent and created a picture which when played back to the CIOs made them cringe and accept it. There were reasons and there were reasons; they were not the usual that have been published by various groups who track challenged projects. In almost all cases these failed to achieve timelines as well as deliver the functionality expected and the CIO ended up with the short end of the stick.

To begin with the evaluation of available options extended to eternity with high business expectations wanting to select the perfect solution. Comparing apples with pineapples creates a situation where the end result morphs from being a custard apple to a jackfruit. Moving from one demo to another scope expands to encompass all exception conditions. Sanity prevails after some time with CIO or business CXO intervention to bring back expectations closer to reality. Elapsed time through evaluation now puts pressure to achieve results in impractical timelines.

What started as a city street drive has now converted into a formula one race ! We need to finish the journey in the fastest possible time; get your experts, put more people on the job, why does hardware delivery take so much time, put it on the cloud. Configurations cannot take that long, it should be possible to reuse expertise from other customer projects. We are not that different but we are different; what we meant is not what you have understood, you don’t know our business and we don’t have time to educate you.

Time keeps ticking with business participants unable to adhere to unworkable timelines resulting in missed milestones and angst on all sides. Reviews soon become infrequent with everyone wanting to just finish the project with redoubled effort. The cascading effect leaves everyone frustrated and wondering why they accepted the stretched targets or ever got into the project in the first place. The formula one race with no equipment, trained drivers and crew suddenly is back to being what it should have been, a street car race.

Accepting reality brings everyone back to what they should have done to begin with; plan with real assumptions, acknowledge dependencies and the need to follow a workable model with good project management practices. It is good to take time to find the right solution which needs to be given due time for deployment too. I believe that CIOs need to continuously educate business users not to apply consumer principles to enterprise software deployments. They need to push back even at the cost of being unpopular or appearing unaligned.

Sometimes they should also be ready to go to a formula one race !

Enterprise projects versus Government projects

“Did you know that the government is the largest adopter of cloud computing ?” asked a cloud service provider trying to provoke the group into a discussion on why enterprises are not embracing his solution. One amongst the group of CIOs retorted back, “Do they know what they are doing ? And with no budget pressures or ROI to demonstrate, how do you equate their reality with ours ?”. Before it became a slugfest between the vendor and the CIOs, the convener intervened; but that had me thinking about context really being different ?

Over the years I had the fortune to meet many people from many countries who headed government projects. Some of them were qualified bureaucrats, some with backgrounds similar to current CIOs or project managers, and a few with no formal IT backgrounds. Their responsibilities were comparable to the enterprise equivalents and the only differentiator in most cases was the scale of operation. The projects they worked on were in many ways similar and quite different at the same time.

G projects especially that revolve around governance are humungous by nature as they impact a very large population (number of users); the complexity varies depending on the process or function. You could draw parallel with large enterprise CRM projects or for that matter self-service application deployed by Banks or telecom service providers. On the other hand there are also conventional automation projects akin to what every CIO and enterprise does as a routine with a view to create operational efficiency.

Enterprise IT drivers and critical success factors comprise on-time, within budget, business functionality and/or benefit and nowadays usability across platforms; corporate project governance keeps everyone on their toes. I am sure that G projects too have somewhat similar drivers and accountability to internal stakeholders. Circumstantial evidence would however point to the fact that the percentage of G projects meeting the success criteria is far lower than corporate. To the taxpayer who funds these, there is limited visibility.

One project lead narrated an incident where the ministers kept changing through the project leading to significant change in scope and timelines. The said project finally went live with 100% time overrun; he did not divulge the budgetary impact. Many years later it is cited as one of the major success stories though it still remains challenged for the masses that use it. Change management is more complex with multiple stakeholders who are required to sign-off and by the time they do, a new set of stakeholders emerges.

Some may argue that an IT project is an IT project and requires the same level of discipline of execution irrespective of where it is done. It is public knowledge that almost all G projects undergo severe review and the bidding process favours the most economical; at least for the initial bid, change requests is another matter. The corporate world is unkind to this flexibility though price war is getting messy for everyone. With different contexts then is it then fair to compare an apple to a pineapple ?

Multi-year projects are passé now though most G projects are that way; maybe they now factor in their unique reality and thus allow for higher latitude than available to a CIO. Project governance, reporting and transparency is not common to all; not too long ago a high profile G CIO was shunted out as he was making many uncomfortable with his open to all reports. He took a leaf from acceptable good practices but the plans, ideas and governance were not acceptable to the well-entrenched way of working.

While we acknowledge the differences in context and realities, I believe that the comparisons are unfair to both. Corporate business entities will always be more aggressive in their approach to capture the first mover advantage or adapt technology for sustenance and survival. They seek market share, profitability, growth and much more. Most Government projects on the other hand do not have a timeline that is critical and therein lays the difference. I wonder if G projects were to be run like corporate projects what would happen !

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:

Part 1

Part 2

Agile development, elongated deployment

Exchanging notes with some old friends, reminiscences of long drawn ERP or similar projects and some quick wins took us on a rollercoaster ride. Everyone had been through a couple of implementations that stretched patience and planned deployment timelines that now seem unreasonable. In those days 5-year multi-geography deployment was acceptable; after all the first implementation/deployment had to stabilize and learning imbibed before taking the next steps. Baby steps before running you know !

I remember my first ERP implementation almost two decades back that lasted almost a year; that company was the size of today’s small medium enterprise. But in those days business agility was measured in years and not in quarters or months or for that matter weeks. A decade later I was involved in a global deployment of a large back office system; we were at the tail of the global project spread over 5 years. Since the business impact was considered nominal, no one saw any issues with the 5 year cycle.

A debate then ensued attempting to answer the question that in the current uncertain world how long is long indeed and untenable ? In the age of SCRUM and hyper time sensitivity towards every change in business process or new business idea, what is an acceptable implementation plan for a project that spans multi-countries ? How long should it take to replace an ERP system or a financial accounting system across say 50 locations, each with some variances or country specific regulations or statutory reporting ? No easy answers here, I have not come across less than 3 year plans for such deployments.

It is an acknowledged fact of IT implementations that they bring about change; when we look at large scale projects, the change is always disruptive (the level of disruption varies from positive to extreme negative). The subject matter experts from the business end up with pressure of maintaining existing operations while dividing their time to project led improvements. Setting expectations and constant communication that is the hallmark of large projects rarely finds its way into the smaller innovation projects. But can this be sustained over 3-5 years ?

What about systems that are created with urgency portrayed by the business but languish in their use ? Many times IT organizations work under undue pressure to create solutions deemed critical towards continued success or to react to competition, but they end up as shelfware. Unanimous in their reality this thread triggered reactions on or lack of sign-offs. Can the CIO in such cases cite past instances and refuse to toe the line ? Probably not, the backlash of such behaviour would be extremely negative to IT.

When cloud based solutions deploy new releases, some offer customers options to use earlier versions for a short while. Not so in the case of consumer apps; when a change occurs, everyone is impacted and learns to live with the new. Why is it that we are willing to accept the change in our personal space but abhor it in the corporate environment ? Is it because that the stakes are higher or the risk averse nature of the corporate world ?

I believe the answer is in our ability to switch off and move to another in the personal space, which is not even a dream in the enterprise. If the production planning or financial accounting were to face issues post an implementation or change/upgrade, our ability is limited to rollback and not to explore new options at that time. But I am hoping there will be a day when what applies to our personal needs will also be good for the enterprise. Then the CIO will have to work harder to stay in the same place.

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.

Communicating Success, Successfully

There is an old Hindi song “The peacock danced in the jungle, who saw it ?”; no one is the wise answer. Now what has this got to do with the CIO and the IT organization ? A lot !

IT is one of those functions whose absence is felt a lot more than its presence. Whether it is a simple email or internet access outage or the impact felt on the enterprise users when billing fails, or an invoice does not get created or printed. The ripples across the organization can be heard louder than the thunder on a wild stormy and rainy day. And what about small incremental development or changes that IT delivers everyday helping the business do some activity or task better, faster, cheaper, more efficiently ? Do these get to the eye (or ear) of the management teams ?

CIOs and IT organizations do a good job of communicating big project kick-offs with a lot of fanfare; the project plans and progress is tracked on some dashboard or report at regular frequencies. They are discussed in management review meetings and focus on timeliness or budget depending on the progress report. User and IT teams debate functionality within the review and steering committee meetings which typically see senior management participation wane as the project progresses. Other priorities take precedence and the resolution of conflicts or issues is left to the project team comprising of a few IT folks, vendor representatives and middle management users present as they are nominated to the project.

If all goes well even with some timeline or budget overrun, the project go live calls for some back patting, an email from the CXO (could be the CIO too) to announce that we are now operational with the new system. In rare cases the Post Implementation Review is conducted by the users or the CIO to validate the base case and benefit if any.

Now the IT organization apart from managing the operations also contributes continuous improvements to the small and large systems working with various internal functions and vendors (hardware, software, development partners, etc.) to address the ever changing needs driven by market forces, internal changes, or sometimes by customers. Many of these could be changes that create significant internal or external impact, but they are rarely on any report or dashboard, leave alone corporate announcements. These typically take away almost 30-40% (figures may vary by company and industry) of the total IT resources. They are deployed and forgotten, moving on to address the never ending pipeline of work.

CIOs should communicate these across levels to demonstrate the benefit, new or improved capability, cost reduction or avoidance they have enabled. To sustain the message of IT enabled sustained enterprise advantage, it is imperative that the users or the IT organization create the visibility. The beauty of the peacock with its feathers in a symmetric formation is to be cherished and enjoyed. If no one knows about it then “IT does not matter”.

IT failures ? Business' challenges

I recently read about the global annual cost of IT failures wherein the author based on certain assumptions puts the figure at US$ 6.2 trillion. It’s almost half of the US GDP number and that is indeed something to think about. Never mind the assumptions or the math behind the figures, the reality is that this humungous number is being labeled as IT failure. The Standish Group report on reasons behind the lack of success in projects with significant IT components indicates that IT contribution to unsuccessful projects is less than 10%. So in reality the number would be closer to US$ 620 billion. And that is about half the GDP of India !

Knowing a bit about IT, I would label this as a business failure to capitalize on the potential that IT could have offered to them. Why does every initiative have to result in painful change management that the IT organization has to drive ? What prevents the business users from embracing new technology solutions despite their vocalization of the requirements in some form or other ? Lots of questions, are there any answers that provide the holy grail to impact the crazy figures out there ?

My Oh I See moment happened many years back when my obstinacy to not start a project without a signature from the business leader delayed the project commencement by 11 months. And when we did complete the project within the stipulated time of 6 months, it was like water to the desert weary traveler who has even stopped believing in mirages. So don’t push hard to implement the next SCM, CRM, or whatever TLA (Three Letter Acronym) technology you believe will make the difference, because it will not if no one uses it.

Non Disclosure Agreements

In not so distant a past, I had an interesting set of meetings with four of the top 10 global IT vendors and consultants who were bidding for a large engagement. Without exception, each party wanted the deal badly enough, considering the scope of work and the market expansion it may create. However, at the end of the evaluation process, I was feeling really nervous, not about the project, but about client confidentiality and what it means.

In the early part of the century after the recession brought about by dot-burst and 9/11, the IT industry had a lot going well for them. Many traditional industries started outsourcing and offshoring, and in one case, an inadvertent mention of a client name in a small newspaper column resulted in a written apology from the vendor CEO to the client PMO and VMO. It also resulted in a reduction in future business prospects.

Fast forward to the present, where vendors do not put in the customer name in presentations, but the words and context gives away the customer to anyone who can use a bit of market intelligence. This is obviously to protect the customer identity. So you may get referred to as “Top 3 FMCG company in India”, “Global 5 retailer” or “Large merchant banker in UK”. The case study that follows almost gives away the name, but still leaves a little room for guess work.

Going back to the incident, all the above mentioned safeguards were present, and guess what! Without exception, each presenter mentioned the customer names, stating that it was confidential. Talk about various non disclosure agreements that lawyers may have spent months preparing! Or warnings given by the CIO, PM or the business head!

Are NDAs worth even the paper they are printed on ? And in India, they are indeed printed on non-judicial stamp paper. When I asked some of them on this “slip”, there were no convincing answers. I’m not sure if there are any measures that you can take to address this situation.
Have you seen similar behavior? How do you protect your and your company’s interest in such a scenario? I would be very skeptical in doing business with such vendors, especially if it was something that brings competitive advantage in the mid-term.

This post was written for TechTarget.In and can also be seen at http://itknowledgeexchange.techtarget.com/Oh-I-See/