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.

The Story Teller CIO

Last week I was at a CIO conference with 80 odd CIOs representing junior and senior CIOs across verticals. Amongst other sessions, fun and networking, some vendor sales pitches, the big draw was a small contest run by the organizers titled “My success story”. It was more than elevator pitch but less than a full presentation with each CIO allotted six minutes to talk about their learning on value creation, innovation, strategy, transformation, BITA, leadership lessons or anything else.

The breadth of options provided enough latitude to the participants to choose anything they would like to talk about, the idea being that success has no one formula but everyone achieves success in their own way. The participants had to send in their briefs in advance with a panel shortlisting six CIOs. Given the average work experience being over 20 years, the audience anticipation level was quite high. Selection of winners was based on an audience vote.

The second (I will come back to the first) one got off the ground talking about leadership and teamwork stressing on the qualities the CIO needs to imbibe. He acknowledged team contribution but stressed that the CIO makes the difference. The key message a good team with a bad leader will fail where a bad team with a good leader has a better chance of success. Ahem. A credible start with a weak finish sans examples did not get him many votes.

The next set of CIOs took a different approach. They struggled to create the magic moment and talk about their winning formula; everyone knew that all the speakers had achieved reasonable success in their long and illustrious careers. So where was the disconnect ? These CIO leaders presented specific project success stories, a point technology solution in the recent or distant past that they were proud of.

Few were almost like a vendor sponsored case studies. Slide after slide talked about technology and benefits accrued from the projects. Can the implementation of unified communication or video surveillance or for that matter business process management even if they contributed to savings or productivity enhancements, be classified as great success ? The stories faltered to bring out leadership aspects of the individuals and portrayed them as good IT CIOs falling short of the benchmark business CIO. They failed to capitalize the opportunity.

So let me come back to the first speaker with no slides or presentation; the CIO spoke with a conviction that had the audience in attention. He spoke about a journey through the years graduating from IT Manager a long time back to the title of the CIO. He discussed many milestones crafted with the help of the teams, not just IT teams, but business and vendors too. He provoked the audience with questions. The extract below based on my notes from his speech is given below.

Over the years I decided to let go, the team was given responsibilities that helped them grow; in their initial years they needed handholding, or feedback, or just a bouncing board to help them understand how they are doing. Not all initiatives succeeded, the team took the learning and shared across to fail faster. This approach has seeded many leaders who are today successful CIOs in many companies across the globe. I can count more than a dozen such team mates who worked with me who have been able to also pass this learning within their own teams thereby multiplying the talent pool.

Success is always a result of teamwork; the leader needs to give the team freedom to take decisions. When they succeed credit goes to them, when they do not, the leader takes the responsibility for lack of success. Such teams rarely need to be reminded of what matters, they rarely let the leader down. My legacy today lives with most of such team members who are shining bright.

No guesses for who won the contest. Maybe everyone is doing this; however, we need to be better story tellers.