Leadership requires taking risks. But technology must work reliably. How do IT leaders square these two realities?
CIOs are driving organizational strategies now more than ever. The more a CIO’s success is tied to business outcomes, the more risk they assume. Traditionally, CIOs have been responsible for KPIs like uptime and system availability to support internal productivity and operational efficiency. But suddenly—now that all industries are becoming digital—there is much more at stake.
There are dozens of definitions for “IT governance” out there. They use words like efficiency, effectiveness, alignment, control, and strategy—which are all valid terms. But the fact is, IT has only so much capacity and can get only so much done. Organizations need a mechanism for agreeing to what is (and what is not) on IT’s plate. That mechanism is IT governance.
The purpose of IT governance is to optimize IT’s workload.
Like most things, the more effort you put into governance, the more you will get out of it. However, IT stakeholders usually have their own areas of responsibility and limited capacity.
Agreeing on a mission statement is a healthy, worthwhile exercise for any organization or department. IT is no exception. The IT mission is a clear expression of the department’s self-perception and shared purpose.
As we forge ahead in the digital age, IT departments are starting to make up the majority of most organizations’ investment, operations, and risk. Thus, the term “IT is the business” has taken hold. Therefore, the further along your organization overall is on its digital journey, the more the IT mission should resemble the overall organization’s mission. In fact, taken to its logical extreme, the best practice would be to repeat the organization’s mission as IT’s mission.
Rhode Island-based Amica Insurance provides auto, home and life insurance nationwide and employs more than 3,800 people in 44 offices across the U.S.
Amica was looking to upgrade its web and mobile applications. To reach its goal, the IT team established a digital program and decided to pilot an Agile SDLC framework for rapid and iterative delivery of customer value.
The Agile implementation worked for Amica because the organization from top to bottom accepted a bit of discomfort in the short-term to give the change effort a chance. Management agreed to support decisions made on the front line. Product owners, SMEs, and developers were game to try new approaches and grew professionally. In return, they achieved a level of productivity and speed they had not seen before. Here’s how we helped.
Your company is moving to Agile from waterfall, and you want to ensure a smooth transformation that keeps projects healthy. As a scrum master working to transform a traditional waterfall SDLC process into an Agile one, I have learned a few pointers when navigating this transformation. An important concept to keep in mind during this transformation is empowerment.
One of Agile’s core tenets is the value of “individuals and interactions” over “processes and tools”. The idea is to foster a high-velocity decision making process, which hinges on open and honest communication in a co-located environment. However, implementing this change can be very difficult for team members who have previously worked on waterfall projects. You may find employees reluctant to volunteer for work, or hesitant to take on new challenges. Why is this so?
Most business cases for technology investments include “productivity gains.” Even when no formal business case is created or communicated, users, managers, and executives implicitly expect that new technology will make their lives better.
However, many organizations spend money on technology as if it were a lottery ticket—hoping they will win. We could consider technology investments to be calculated risks, but, unfortunately, that just doesn’t seem to be the case. Most investments in tech turn into mechanical implementation projects that result in more complaints than compliments.
The most common complaint about technology from the user community is that it kills productivity, exactly the KPI it aims to improve. There are two reasons:
Vendor management is an internal IT function that often has room for improvement. A maturity model is a helpful tool for evaluating the state of any given vendor relationship, and determining the overall balance of your organization’s dependency on vendors.