IT departments are boring. In the time of vibrant start-ups, who wants to work in a department that used to be called “Data Processing Department”? IT departments are still organized more for data processing than for anything else. Despite the hype of IT as being “strategic” there are next to none IT Managers on the board level. The title CIO is numerous, board representation is as good as nil. CIO’s are seconded to the second or third level of an organization, usually reporting to the CFO and too far removed from the business.
One major reason is that IT departments are not strategic, despite all the rhetoric about IT. And rightly so! How can a department that is mainly concerned with providing “water, heating and light,” i.e., keeping systems up and running, be strategic? Ok, it is supplying information to the whole organization so it might be more strategic then facility management. But not by much.
IT units are simply not adding enough value to their organization today. Some organizations do not expect more from their IT units, they are happy if systems are stable. More is not needed, the organizations aim to plow on without much help from IT.
But more and more organizations are disrupted and need their IT units to help them transform their businesses. Here is how to make IT units a valuable asset in a companies transformation.
Step 1: Keep the lights on
All is nothing without systems being performing, available and stable. IT should not aspire to anything higher if this sine qua non is violated. So if your companies systems are not satisfactory stable, get them in order before aspiring to anything else.
Oh yes, this big investment, the new integrated shiny system will do the trick nicely. But waiting for the big cheque to be handed over might take forever, maybe longer than many IT Managers hold on to their job.
Other strategies are asked for. IT’s performance gap might have two root causes: An obsolete application landscape or an obsolete organization. Often it is a combination of both.
The obsolete application landscape might be cured by methods discussed on the blog in November 2015:
The obsolete organization of an IT department can be cured by applying ITIL concepts, which are there to help set up IT to business needs. Having solid concepts for Application-, Infrastructure- and Project Management plus the myriads of supplementing IT service processes is a must. But do not go overboard with the concepts. As the founders of ITIL state themselves: ITIL is not prescriptive. Take the concepts you need and make them work for you. It is no bible.
Step 2: Enhance
Once the lights are consistently on, step up the game. Now that IT applications are in control and IT Service Management processes are solid in the perception of the business units (perception is reality), get some excellence going.
A. Seek excellence in Effectiveness
With IT service management you may drown in the process, approval processes, documentation, tracking, and procedures. While quite a bit of rigor is needed, a high number of IT departments drown in procedures, squashing agility, business reputation and innovation in the process. Stop at a good workable level. Common failures are:
- Multiple levels of approvals of changes
- Documentation that encourages redundancy
- Using intermediaries to relay business requests to IT developers
Do not seek excellence in administration. Seek excellence in effectiveness.
B. Go forth and Eliminate Waste
ITIL is just about qualitative best practice. It is not about quantitative efficiency. There are no recipes in ITIL how to find and eliminate waste in the IT services you are offering to your organization.
You need to eliminate that waste. First, you will need to free up resources for more value adding work. Second, you need to demonstrate to higher management that money is well invested in IT, that IT delivers higher business impacts for the buck, that the IT unit is healthy, alive and kicking.
How to identify waste? Measure.
- Macro KPI’s: Benchmark your organization’s expenditure on IT vs. competitors or industry benchmarks. Meet with other organizations IT Managers and analyze the shop they are running on a quantitative basis to learn what can be done better and what is already good. Apply Controlling to all regular expenditures on systems or applications. Identify the most costly regular items.
- Micro KPI’s: Measure ticket closure time, the number of tickets, the number of changes, the workload per developer, the backlog in efforts and days, the timelines of projects.
After that, you’re come up with an action plan and tackle item by item. But not in isolation, as certain wastes are connected to the same root cause and should be tackled with some foundational measures – e.g., IT information engineering and management by deliverables.
C. Management by Deliverables
Management by deliverables is a project management principle that calls for all project planning and monitoring to be achieved through the production of visible work products.
IT service standards such as ITIL or project management standards such as Prince2 stress procedures and activities. They provide formal frameworks that might become a”formalistic” nightmare because they lack the focus on outcomes. If an activity is not producing a tangible deliverable (a specification, a piece of code, a configuration, a concept, a test plan, tc.), it is of questionable value.
The 5 Rules of Management by Deliverables:
- All tasks must produce a deliverable, a tangible outcome of human effort such as a functional specification or a piece of code
- Set duration at typically 5 to 10 days (up to 3 weeks maximum)
- Obtain commitment from the responsible persons on the schedule
- Monitor the progress of large deliverables with intermediate analytical deliverables (technical investigation reports, outlines, draft specifications, rough notes)
- Formally inspect and accept the completed deliverable.
Thinking, planning and tracking deliverables instead of tasks has immense advantages:
- It keeps the focus on the economic value add of an activity, an antidote to over-administration
- It gives people autonomy room to manoeuvre: They decide how to come up with the deliverable. The activities needed are decided and ordered by them alone
- Deliverable orientation can be easily inserted into known, conventional waterfall, “gated” delivery models by tracking Deliverables on project management level and not activities.
Last not least, management by deliverables prepares the organization for agile methods, as those rely on deliverables and personal autonomy.
D. A System for IT
IT needs a system.
Most IT managers are aware of the need to plan and engineer application landscapes and IT system architectures consistently in domains, e.g. systems of transactions, engagement and perceptions (see Can IT departments get anything straight?).
But few IT Managers apply the same rigor of planning and engineering to their own landscape of IT applications like incident management, monitoring, demand management, approval management, knowledge DBs, user directories, development tracking, document management, project management, time keeping, collaboration platforms, meeting platforms etc. All those systems often reside in isolation from each other inside an organization.
This situation is like a work shack where all the different tools are stored in more or less order.
By not engineering the data flow between all those different tools, IT works on a workshop level and not as a professional information manufacturing operation.
Demand management, for example, relies on a specified demand from a business organization. This demand must be evaluated, approved, implemented and released. There is information and documents flowing between all the different actors in this process. Yet, there often is no single system in capturing and organizing all those information. Requests come in via mail, specifications are stored in files in sharepoint, approvals are given via mails etc. It is nearly impossible to remain on top of this very important processes without engineering this process into a single or interconnected systems.
IT needs an application landscape on its own. A landscape that allows to be in control of the production processes of IT. The results are transparency, automation and efficiency in more routine processes- thereby creating the space needed to excel in change and transformation.
The first derivation of the business needs is the application landscape of the organization.
The second derivation of the business needs is the application landscape IT uses to manage the applications demanded by the business.
Central pieces of such system landscape are provided by jira, Servicenow or can be build based on the MS Package (Sharepoint Extensions, Project Server etc.).
Step 3: Change
With step 1 and 2 in place, the internal workings, the effectiveness and efficiency of the IT department should be in order. Now it is time to help the organization.
A. Project Management
Project Management is the art of getting something new done by a collaborative work-effort over a certain length of time for a certain budget. Project Management is all about change.
ITIL already sets some standards for it, as does Prince2 but in much greater detail. There are many flavors to project management. Setting up the right kind of structures – structures that fit the organisations maturity level and allows it to grow its ability to handle change over time – is key.
Real proficiency in project management is hard to learn for organizations. Organizations are single dimensional hierarchies, where nearly everyone has a exactly one superior. With project management a second dimension is opened up, with temporary assigned team members holding two or multiple jobs/assignments, work extends in other branches of the hierarchies, cross hierarchical collaboration is needed.
Therefore project management structures are often overpowered by the hierarchy. Visible signs of the meagre role of project management inside an organization are:
- Part time dedicated resources, say one or two days a week
- Project Gate Reviews with steering group never happen or high ranking managers never bother to show up
- An expectation by the the organization that a project should deliver something but not being able to tell exactly what or be willing to participate in it to any significant extend: “Sure, we will fix it – we have outsourced the solution to a project”
Here is some advice how to establish project management capabilities in an organization:
- Start up with the easy steps of getting decent project management structures up and running
- Educate the organizations. Be a missionary. Be diplomatic, tough
- Stick to traditional project management techniques where resistance is
- Try agile methods wherever there is a pocket in the organization willing to embrace autonomy and there is enough trust to accept a variations in outcome
- Do not try going agile where the organization is not embracing autonomy and trust The immune system of the organization will reject it
Visualization is a powerful ally for any change. Visualization makes abstract things real, tangible, understandable, truthful, it shows what is important, it aligns people on a common view or goal.
I have been in organizations that do not allow any visualizations at all (except in power points) – in order to keep the office floor and offices nice, tidy and uniform. Those organizations enshrine the status quo as the way it should be – all by a policy dictated by facility management.
Visualisation is a key concept of any change: If it is to ramp up manufacturing plants, completing production of Boings or Airbus Planes, improvement projects, merger & acquisitions – you name it. It is a key point for all modern management, software development or start-up techniques.
Often visualization is interpreted to mean togo and create an interesting chart explaining an abstract concept. That is far too less. Good visualization must flow into the view of the recipients. It is not waiting to be accessed and experienced, it is there for all to see, on the floors, on bill boards, updated, importance, meetings and speeches are performed in front of the visual display in order to convey its message.
C. Embrace the Cloud
The winning strategy to develop a static and more and more outdated application core – to escape the “cycle of stuttered innovation” (as defined in Innovation-ready-IT: The way forward for IT) is to “strangle” the legacy application: To implement new functions as an extension to core based on a different platform and link it via stable API’s.
These different platform can and should be primarily cloud systems:
- Cloud systems relieve IT of its main job to “keep the lights on” and let IT move to more value add
- Business units are craving for specialized, lightweight, mobile solutions that help them now and can be tinkered by them to their needs
- There are so many cloud applications out there which offer immediate benefits, are available for immediate experimentation. More and more, this is the place for innovation
IT departments are usually reluctant to support business departments in moving to the cloud. After all, they are the gate keeper of the integrity of systems and it is IT’s job to cater for all systems. If business department are allowed to build up lots of shadow IT departments, that consistency and -god beware- the job of the IT department is ultimately threatened.
I believe that trying to suppress this storm of cloud applications means fighting a loosing battle and is suppressing innovation.
It is a fight to conserve “the way it always has been” while the world is changing. More variety is needed, more business departments have valuable IT skills on application level that can be utilized. Hell, nearly everyone is skilled in some IT skills from education or private live. IT is a part of live of everyone more and more.
IT needs to learn to live with that reality and utilize it for the best of the organization. It needs to let go from the vision to “own” all applications. It needs to evolve from a dictator of IT Systems to a Gardener. A gardener that plans the layout of IT structures, gives place to grow, nurtures and sometime cuts back plants for the sake of the organization.
How? Think of IT as the provider of…
- the overall architecture
- the core systems (system of transaction)
- and of a ever expanding catalogue of API’s that can be used inside and even outside the organization
D. Bring your own Device
As anachronistic as the notion that all systems must be owned by IT is the notion devices need to be owned by IT. People, employees, customers, partners and contractors, have very powerful devices at their disposal: Mobile phones, computers even servers. It is silly to not utilize this potential:
- It saves money for the company in purchasing and maintenance
- It is less of a hassle for everyone involved
- It blurs the lines between private and work live
Yes, every of these three points has its pro and cons. But at the heart of the issue is this:
Guys we are talking devices here. That is not the main point.
The main point is to use of information for the benefit of the company. And that aim we will come closer by allowing everyone to bring their own devices.
And you security spooks: Yes, it is an architectural challenge, but one that can be coped with: Who is doing online banking or brokering with their private devices? Raise your hand! Thank you.
E. Adoption, not Outcomes
Mature IT departments are pretty good at delivering the things they promised. After all, that is their job, they have been trained to do that for years. ITIL and Prince2 are basically frameworks for the art of delivery. It is measurable and tidy: IT has done their part.But still a lot of IT projects fail to deliver business benefits.
The problem is: Even if a change or a project is delivered by IT, business may not adopt it. The reason for lack of adoptions are manyfold:
- Ordered it, but no longer need it
- Some else wanted it, this guy has gone
- Never wanted it, but had to do something as a token
- The way IT has implemented it to the letter, but not to our intended purpose
- It is useful, if only those pesky specialist would do as i told them
- Oh yes its good, but i do not have enough time to use it properly. Give me resources
Usually IT, plans for “Post Production Support” after go-live to fix problems and provide help where needed. Usually, this effectively means that IT enters a reactive mode. The project is delivered and IT leaves the center stage for business to perform its act.
There are numerous concepts to stream line this “hands-off” process between It and business departments, both in ITIL and PRINCE2. But at the end of a project people are usually exhausted and want to move to something else. Alle recommendations are hard to implement in reality, it is only human.
So what is to be done to get better Adoption of systems? Here are some cues:
- Engage the business departments heavily from the start
- Do not relent getting business people engaged in the project, ever
- Do not relent and be very active in the post production phase: Engage
- Measure adoption qualitatively, inspect, discuss with business and act
- Change Management should be there all along to help, but esp. in the post production support phase
Finally, the propensity to adopt is a function of the companies culture. By taking on an Agile and a DevOps approach to software projects, the adoption propensity will increase immensely.
Step 4: Transform
Caution. It is no use to transform into something that is alien to the organization. It will not pay to be implementing more radical, advanced concepts into IT if the organization is not sharing the same willingness to transform. Try it as a stand-alone exercise inside IT and the immune system of the organization will come to attack you and prove you wrong.
With each step of this Manifesto IT becomes more outward looking, more engaged in the organization. Step 4 can not be undertaken to any meaningful extend, if the organization is not transforming as well.
A. Explorer, Gardener, Coach
First, change your and others management styles. Without this change at the higher hierarchical levels, all advanced methods will deliver limited results. All advanced methods rely on one thing: To release the creativity and commitment of the individual for the good of the company. This does not mean doing away with hierarchy – it is always there- but it provides much looser reins to the individual.
In fact management must consider itself as…
- A Gardener that plans, set-ups, nurtures and maintains the organization
- An explorer that is always curious to try new things and has the stamina to get it right
- A coach for the team that creates the best odds to succeed but accepts that the players must find their game on the pitch once the game started
This approach is described well by the CEO of IDEO in an HBR Article about how Leaders are able to nurture creativity in others or hear this HBR idea podcast. Beside take a look at my previous blog posts about leadership, e.g. Tired of hierarchy? Try this.
Autonomy is a central element of releasing creativity and achieving commitment. Ironically, organizations tried to handle the complex and demanding IT structures by installing ever tighter controls: Reviews, Approvals, Specifications, Change Control Boards, Transport Approvals, Release cycles etc until any initiative has been smothered by “the process”. But the way towards management of complex structures is more autonomy to the individual.
The Agile Manifesto, originating in a 2001 Meeting of software developers, provides a good view of what autonomy means to IT personell.
All forms of team based work rely on greater autonomy for its members. Autonomy is a big challenge to the hierarchy, which used to rely on command and control, on leading from the front. This changes to gardening and leading from behind. Leading from behind does not been been present at the front, but it mean trusting team members “do to it their way”.
This concept is best described in mission type tactics (“Auftragstaktik”) or in Kaizen Process improvement techniques. This is the basis for some of the most important concepts of the lean start-up movement.
Unbridled autonomy is a recipe for disaster. The solution is not to remove all controls and replace it with “Hej Joe, you do what you deem best”. Instead, there need to be three elements in place in an organization:
- Responsibility for results
Ideally, a developer who builds should be in charge to deploy and maintain the software too: You build it you run it. For IT this a 180 degree turn from the traditional distinction of IT units in “build” and “operations”. These units become one, thereby establishing the strong incentive to deliver reliable, well tested software, as there is no-one else to blame for failure.
- Architecture: Planning and Control
The “Blast radius” of failures in software deployment is to be limited by a robust application landscape architecture, that limits failures to single functions instead of the whole system going down.
- IT delivery processes, a tool chain and automation
Developers need to be empowered to push their code into production by a largely automated Tool Chain that integrates development, testing and operation. That requires a lot of investment in IT systems, in “the system for IT”, as described above.
DevOps aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably. It is a twin to agile development methods, as agile methods are limited to development and DevOps extend agile methods towards operations. With both, Agile and DevOps in place, the autonomy of individuals in IT are released.
With autonomy in place, enabled by agile Development and DevOps, Business and IT can collaborate much more easily to come up and perform much more interesting hypothesis, tests and validations.
A cycle of learning gets underway. Ultimately, this is what IT should do: Not only provide Information Systems, but deliver insights that create business Value.
The spirit of constant Experimentation and Learning in captured best in the lean start-up movement.
Experimentation is important for any company to prosper in a more and more disrupted, digital business environments. But it is not required everywhere.
There are realms within the organizations, periods within an organizations life cycle, and industries where stability and efficiency is called for. For those organizations and Situations, Autonomy, Agile and Devops may not be what is called for. Step one, to keep the Lights on, might be everything what is called for.
A golden Rule in business process engineering is to eliminate unnecessary Excellence. Agile and Devops might be useful, but are not necessary and ultimately might have a negative or insufficient cost/benefit relation.
Therefore, management needs to pick a zone and derive from that the aspirations for the IT unit. So that IT will play the right game in the right zone of operations.