In innovation, you aim to introduce something new; make changes in anything established. You could go right or could go wrong. Of course you do all preparations necessary to go right every time, but if you don’t, you take the lessons learned and be better next time.
Romeo Siquijor is a good friend and compatriot. He now heads Information Security in CEMEX in Mexico while I found my way to Houston after several stints in different countries. We both started as young IT managers in the Philippines. Our offices were adjacent. The thing I remember most was Romeo repeatedly telling his IT Operations team that “failure is not an option” — like it was their mantra. I did not disagree with him, but it was not the same message I would tell my team.
I headed the IT Business Processes group at that time. My department’s task was to enable and support IT solutions. For us, the mandate was to find new ways to do things, to innovate, and to test new tools with potential application to our business processes. Of course, I wanted my team to succeed but on the other hand, I did not want to have the fear of failure limit their quest for new things. I believe that sometimes the cost of finding innovation is failure – finding out what does not work on your way to finding out what does.
While working with our commercial department, we implemented a sales automation tool using handheld devices. Unfortunately, it did not fly when we piloted the project and we failed. We did not get the buy in because the tool was not user-friendly and robust. The sales managers simply did not use it. We explored another innovation we called mobile selling. Romeo helped design a simple technical architecture to run it. At the time, in 2003, text messaging or SMS was already big in the Philippines. It was a phenomenon and the use of it quickly became part of our culture. Our goal was to incorporate the use of texting to our sales process. We developed a tool that would allow our customers to request orders using SMS and they did just that. In just a few months, 60% of our sales orders were coming from our mobile channel. We were open to exploiting the best technology at that time by applying it to our sales process but we were not sure how our customers will react. We were willing to fail and so we took a risk and gave it our best shot.
When mobile selling was already operating, it became a mission critical application. The system was hosted by the IT infrastructure that my friend Romeo manages. In that perspective, I loved it when he told folks “failure is not an option.” I did not want any service interruptions to impact my mission critical applications. Romeo values productivity, availability and reliability. He wanted no failure and no surprises. He wanted things done yesterday, done better, faster and cheaper today.
My goal is to show you two different perspectives from two different functions in IT. “Failure is not an option” is a good mindset for day-to-day IT service delivery. Although, I would argue that this does not apply to areas whose mandate is to innovate. In innovation, you aim to introduce something new; make changes in anything established. You could go right or could go wrong. Of course you do all preparations necessary to go right every time, but if you don’t, you take the lessons learned and be better next time.
Agile methodology is particularly advantageous if you are selling an idea or innovation or if you need a proof of concept, a pilot implementation and early wins before you get the approval for the complete project.
Are you used to doing large-scale IT projects that require enormous investment of time and money? Normally, these projects are the ones that aim to deliver a “complete” business application package. IT managers start with the determination of project scope and feasibility, creation of a business case, blue printing, project planning, execution and delivery. Depending on scope and scale, such a project (from start to finish) could take months to complete and require a lot of resources.
How do you manage such large-scale projects? Typically, IT managers resort to the traditional sequential method. In this method, you determine all the business requirements in the beginning, agree to sign off with the business and move on to a lengthy development cycle. This traditional approach is characterized by work wherein each stage occurs in linear order and lasts a longer period. What’s the risk of such a method? At the end of a project, a team might have built the business application package it agreed to build and deploy. However, in the time it took to develop, test, fine-tune and deploy, business realities may have changed so dramatically that the product becomes irrelevant. In this case, the business has invested time and money to create a product that no one wants. Isn’t it possible to ensure that the end product is still relevant before it was actually finished? Isn’t it possible to divide the scale into smaller scope and deliver one product (smaller but value creating) at a time?
With the pressures of a limited budget and demand from internal customers for the immediate delivery of innovative solutions, one approach stands out– Agile Methodology. With Agile Methodology, you have a shorter delivery cycle and focus on delivering a “minimum value product”– the minimum scope that delivers the first set of products, functionality and value. You are not expected to deliver a complete solution with a host of value components. Agile development provides opportunities to assess the direction of an initiative throughout a defined roadmap. This is achieved through a smaller project cycle or iterations, at the end of which teams must present a minimum viable product.
The advantage of the Agile approach is the quicker visibility of results. This is particularly advantageous if you are selling an idea or innovation or if you need a proof of concept, a pilot implementation and early wins before you get the approval for the complete project. Also, you don’t have to request a huge amount of investment up front. You create, deliver and sell one value creation at a time. The challenge is to find the minimum scope that could deliver the first set of value and focus your efforts on delivering this first. Implement, test, evaluate and then move on to the next quick and responsive development cycle.
The industry sector that I work in has been badly hit by financial problems in the past couple of years. Obviously that affected IT funding especially on projects in a huge way, impacting our capabilities to deliver the same innovative outcomes from previous years. But the challenge for IT manager is managing the demand from the business partners who continue to request new IT solutions for their business. A lot of them obviously focuses now on innovation addressing how to win in this tough financial times, like profitability, process efficiency, and differentiation in customer experience.
It used to be easier to sell a huge multi-process, multi-business line and multi-year projects, for as long as you can prove the business value of your initiative– not anymore. What we do is sell an idea in a form a roadmap and focus on delivering the first minimum viable product– that’s when truly embraced agile methodology to project delivery.
Agile Methodology does not only apply to IT projects. It could apply to any other project with a large scope that potentially can be divided into small iterations of delivery. Some examples that I can think of are infrastructure projects and product development.