Is the Role of CIOCTO Stops after Delivering the Project?

Glory Nelson, SVP-IT, SpiceJet Limited | Friday, 06 October 2017, 08:38 IST

Certainly Not. The real success lies in seeing the usage of the application/ system that is being delivered to the Business. The biggest task is not completing the project but ensuring that it is being used for the intended purpose.

I am sure most of you would have gone through the same pain of bringing in the change when a new product/process is being implemented. Some of the challenges could be common across different technology and domain. As a technology leader, it is important to plan for this or consider this aspect while planning for a project.

"The time spent during this phase helps business to give the clear requirement and also helps the IT team to see the problem as business users"

I wanted to talk about two major implementations which we did last year as part of the business transformation. Both the projects are aimed at reducing the manual work that is being done by different departments and to bring near real-time visibility. The first project was done using traditional waterfall model. The requirement was given by the Project owner (Note not the business owner) to the development partner. Since it was planned in a traditional way, when the product was delivered, the acceptance from the business was negative.

Some of the key reasons why the adoption was very low:

• Lack of collaboration with various business teams

• No visibility of Progress

• Lack of emphasis on User experience

• Environmental Change Management

It was very painful and lengthy process to fix all the issues after the product was delivered as the effort that goes into architectural change was huge. Above all the trust from business is completely lost on IT team to deliver any projects. After this, my primary aim is to regain the trust and show that projects can be delivered with good quality and also as per the business requirement.

To achieve this, I have brought in few changes to the development methodology. The strategy was to utilize the learnings gathered from the first project and involve Business right from the beginning and more frequently so that they suffer fewer surprises, their feedback is incorporated at early stages and cost of rework is reduced. Another key component of our new strategy was to emphasize more and more expected output resulting in Product vision and Sprint Goals. Ample time was spent initially with business to understand their problem statement and the purpose of the project. Basis this, the Product vision was crafted along with the business so that everyone working on the project can see the bigger picture and is able to work towards the common vision, precisely aligned to the Business objective. The time spent during this phase helps business to give the clear requirement and also helps the IT team to see the problem as business users. This is one of the critical success factors of any project. This will enable IT team to deliver the right solution which can be termed as business transformation.

Once the requirements are complete, the other issue (Lack of Emphasis on user experience) was addressed by creating clickable designs so that business team was able to visualize the product and provided early feedback thereby reduction the rework effort during testing. This phase also helps the teams to collaborate to produce the finest friendly designs.

Then the project was moved into an agile mode with regular standups and 2 weeks sprint delivery. The teams working on this project were provided enough orientation about this model which helped them to work together with collaboration and adoption. As mentioned earlier as well, we involved the Business owner to provide the sprint goal to the development team, which is aligned to the Product Vision. This provided the necessary visibility to business. Since business is also involved in the demo, it gives them sense of ownership as their inputs are taken into consideration during the demo. As per the business priority, the subsequent sprints were planned and the Business approves/ rejects the demo after verifying whether the sprint goal provided by them in the planning meeting has met. The next another important question that would arise is how to manage the change that keeps coming up during the demo. Training and continuous interaction help business to prioritize what is required as this project was on FP.

The project was implemented successfully. Since this was developed along with business by providing them regular visibility and implementing the changes suggested.. The adoption was very good. Within a couple of weeks, the adoption rate was increased to 80% and it was close to 100% within 4 weeks of implementation.

My role as a CIO doesn’t stop after delivering the project, I had put the right mechanism and appropriate controls in place to check the effective utilization of the same with respect to its intended usage to the end users. So we have designed (a) an internal system of periodic compliance check (b) along with the measurable KPIs and (c) periodic reviews of the projects with the Leadership team, which acts as an Early Warning System for us to take timely preventive actions before the risks get translated into issues.

What works for our organization may work for your organization as it was just the simple change we as leaders brought in and it made various teams to work in a more collaborative and transparent way towards one common goal. We are now planning to scale this model to the entire organization.

Don't Miss ( 1-5 of 25 )