Showing posts with label IT failures. Show all posts
Showing posts with label IT failures. Show all posts

Monday, November 30, 2015

IT project success are Business success too, learning from disasters – Part 3

With the CEO’s ratification the challenged implementation was turned around by the CIO along with the business teams; the project eventually delivered more than the original expectation becoming a first in the industry. The big name consultant wisely stayed mum on the episode and focused on discussing other projects they were involved in; the CIO stayed understated in his success letting the Sales team talk about stories from the field. The CEO raised the question, what has been the learning in the turnaround and success ?

The question appeared to be thrown across the room to no one in particular though the individuals who had to fend the query knew that they were in the spotlight. In adversity most find it difficult to provide the facts as they occur; it requires enormous courage to accept that something did not go as planned. Irrespective of the cause, acknowledging and individually or collectively owning up to an unsatisfactory decision is not normal human behavior. People can write reams on what contributed to success, so the ask required brave confessions.

Ensuing silence appeared to stretch time making seconds appear like hours; everyone was glaring at their shoes and hoped the other would start ! Seeing no movement, the CIO stood up to speak, he was waved to by the Sales Head to sit down. Slowly he rose from his chair, looked around the room and nodded to the CEO that he shall apprise the group of the journey that had created lots of heartburn, frayed tempers, and accusations before eventual success. The aggregation of facts, observations and learning took everyone by surprise.

Failures are orphans who no one wants to adopt; people attempt to make them stick onto others shying away from their direct or indirect contribution by the way of their actions or inaction. The position within the organization hierarchy does not matter, everyone hates to acknowledge their contribution to the outcomes. At times failure to act or raise the flag when we see something that does not appear to be in harmony has a cascading effect on the team which accepts suboptimal solutions with a view that it is not my problem.

Disconnect from reality and inability to see from others frame of reference while imposing our views by virtue of rank, position or loudness of voice, leads to reluctant participation by the team despite the gut feel that wants to protest. We take a frivolous stand or approach to some of the mundane detail when presented, wanting to surf at 30,000 ft. thereby not providing the benefit of experience or holistic view that could improve the end result. Patching bad process or automating it hurtles us towards disaster quicker and we blame the technology !

When the downward spiral begins and there is no hope for nirvana, we find scapegoats, which 
typically end up being the meek or the geeks since both are unable to find a voice. We hasten the judgement and move on from the bad news; we rarely want to get to root cause analysis, institutionalized learning. Introspection and internal team review is a scarce phenomenon in the corporate work which does not take failures lightly. Fail fast sounds good in case studies and management books, we don’t like it when it happens in our teams.

I am thankful to our CEO to have raised the question and provide the opportunity to bring out the learning in our project – what rather than who. We all know how we contributed to what happened. Everything that I said happened in this case of our Sales system. We started with flawed assumptions and bad design, we skipped due diligence, we did not connect consistently with the process on the ground. And when the system failed to deliver, we found a scapegoat in the vendor knowing fully well they cannot retaliate.

Our CIO did not flinch during the predicament he faced, he demonstrated maturity that we should learn from, and I thank him for holding it together. I would also like to meet the vendor and thank his team for standing through thick and thin and keeping the faith. Let’s apply the lessons across the company and ensure that we do not falter in any venture, project, collaboration, or cause, by remaining alert to such behavior. I give freedom to every member of the team to challenge constructively to create better outcomes for ourselves.

The management team gave him a standing ovation; he had spoken from the heart which connected with everyone. He had said what everyone wanted to but were hesitant; he personified what they wanted to be.

Links to Part 1 and Part 2

Monday, November 23, 2015

IT project success are Business success too, turning around failures – Part 2

No one expected the CIO to stand up to the big name Consultant and other CXOs who wanted to fire the IT vendor for a disastrous outcome; but he did and also raised some relevant points which do not get asked in such situations. The project started with flawed process design which was pushed through by the Consulting Company; which Consultant should be fired ? The business head and the business project lead accepted the large forms that found no traction with the field staff; which business lead or head should pay the penalty ?

There was an uneasy silence which demanded answers from the assembled group of leaders; the Senior Vice President of Sales and President of the business were shocked beyond words. How dare anyone raise a finger in their direction ? Had the CIO crossed the boundaries of acceptable behavior ? IT was and is expected to translate business requirements into a system that the business can use. They can suggest improvements to process but are not expected to challenge business supremacy in an open forum. All heads turned towards the CEO.

The CEO faced a dilemma, he could chastise the CIO for his remarks and enforce a decision to revoke the earlier development contract and give the reins to the Consulting Company to deliver what they had designed and promised. His other choice could have been to give the development partner another opportunity to redeem themselves, after all it was a business project and there was some merit in what the CIO said. He was tech savvy and aware that success would have had business and the Consultant patting each other’s back; the vendor was a convenient scapegoat.

Without defending the business, Consultant or the CIO, as a matter of fact he asked the CIO, “As a business leader, what do you recommend as the course of action” ? The CIO had been hired to change IT performance and improve levels of engagement with the globally spread business; the CIO had high pedigree and was a prize catch. The CEO did not ask others since they had proclaimed their verdict and delivered the judgement; the trail in absentia had unanimously declared the defendant guilty. The CEO knew his team and was a fair man.

The CIO outlined the plan to salvage the situation with meticulously charted steps, actions, roles and responsibilities across the project team. He sought absolute control over the process and metrics with a tight deadline to deliver the desired functionality in phases. He had done his groundwork with the field staff and the vendor to understand what would practically work within the operating environment and constraints in which they lived. He had also reviewed the technology stack to assess if the vendor had put in the best effort possible.

It appeared to be the best way forward without shedding any blood, answering the uncomfortable questions, or disgrace anyone. A compromise for the business who would have loved to hang the CIO and the vendor, they reluctantly accepted the verdict from the CEO who accepted the plan. The CIO on his part volunteered to forego his variable pay should the project not deliver as he had promised, which satiated the team as an acceptable bargain. The CIO wagered for other CXOs present to match the stakes, which none did.

Leadership is about many traits, some of them being – to lead from the front, walk the talk, take risks, and take your team along in adverse situations. The IT vendor was apprehensive of the solution and also experienced adrenalin rush at the dangerous move. He conceded control to the CIO who put his more than two decades of experience behind the project, driving the team in high energy mode for the next four weeks. The sales team matched the rigor with the development team frequenting the field to collaboratively engage with their customers.

Success cannot be denied to the possessed and the driven; the CIO and the project team were razor focused on the outcomes. The solution emerged from the shadows and made the grade step by step across layers and geographies; news of success floated in from all quarters across the entire user workforce. They loved the simplicity and the ease of use which was defined with their inputs casting aside the complexity imposed by global best practice models proposed earlier; they had a first in the industry and everyone loved it.

In the next management meeting the CEO asked the group the learning in the unprecedented success !

And that is another story for next time !

Link to Part 1

Monday, November 16, 2015

IT project success are Business success too, what about failures ?

It was pronounced a total disaster by the Sales Head in the management meeting; the teams were unable to use the solution that was launched with much fanfare and back slapping just a few months back. Usage reports indicated compliance of less than 20% from across the ranks with multiple reasons fighting for top position. Other CXOs backed the Sales Head in their vociferous chant about IT inability to meet business requirements. Everyone joined hands to blame the development vendor, unanimously agreeing that they should be fired.

The project was the culmination of work done by big name management consulting company along with the sales and marketing teams working in a cross functional team. The new CIO had joined the project mid-way through and followed the process to its conclusion. The project was handed over to an existing partner who had created the earlier version of the solution much against the wishes of the big name consulting partner who wanted to build the solution albeit at a budget 10 times larger than the incumbent software company.

Sales team had been using version 1.0 for some time with basic functionality and low cost device, a good starting point for the company. The IT team and the vendor worked hard to deploy the new system raising usage to 70% with some potholes and an uneven ride. The data captured served the initial purpose and the teams wanted to move up the value chain in customer engagement and market data capture. The Consultants engaged in other work with the Sales team coerced their way into the project to add value to the new process.

As the new specifications emerged the CIO was wary of the unwieldy system that emerged from the stables of management consulting. His views were brushed aside with pompousness that only big consultants know how to pull off, which they did especially when they did not get to build the system. They defined the Project governance and reporting with all the “best practices” that have never been collectively used putting significant overhead on the development team with challenged timelines that they had no choice but to accept.

The vendor CEO took the CIO into confidence wanting to abdicate but was cajoled into staying with a promise to make amends in the future. He knew that the Consultant would find many reasons to plot their downfall and the project had limited chance of success. Reluctantly he accepted putting his best team to work and treat the project as a learning of better coding standards, governance, and project management; he was painfully aware that declining the project would have shut the doors at this customer forever for his small company.

Struggling through the process, burning the team, the vendor delivered to the unreasonable timeline; the pilot was deployed with a small team who rejected the system as cumbersome and unusable. Sales highlighted many impractical processes which had been introduced by the Consultant despite protests. The vendor took the big list in his stride and worked to deliver knowing well that the cause was already lost but not giving up hope. On the other side the IT team attempted to manage perceptions while business winced at the lost opportunity.

The quarterly management meeting is when things came to a boil and blew the lid; fire the vendor appeared to be an appropriate redemption to the cause. The consultant fueled the fire with “If we had done it, the project would have worked” and “I told you so …” remarks. The business teams were not interested in the blame game, they wanted the project to work; they stressed a simpler process which can be easily executed on the field; they were not interested in the far-fetched analytics proposed by the Consultant.

Not accepting the fait accompli, the CIO stood up requesting permission to speak: The project started with flawed process design which was pushed through by the Consulting Company; which Consultant should be fired ? The business head and the business project lead accepted the large forms that found no traction with the field staff; which business lead or head should pay the penalty ? If we can decide on this, I will definitely fire not just the IT vendor, but also people from my team responsible for the fiasco; we all are responsible for where we are !

On hearing the episode, I wanted to nominate the CIO for all the possible leadership awards; may his breed multiply !

PS: Curious what happened in the end ? Wait for the next episode.

Monday, November 23, 2009

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.