There we were halfway through the workshop with the IT leadership team and our attention shifted to the team’s project delivery performance. The insight from the executive was very clear. They saw the IT team as the department of no! It didn’t matter how good an idea it was IT would find a way to make sure it didn’t get done. If through some cosmic miracle anything did get done then it was seen as being too little too late. Slow in the extreme and often what was done had significant issues when delivered.
“Let’s have a look at some of the metrics” I suggested. It took about 250 days to deliver the average project. While these projects were often delivered on budget (70%), they were late 2/3rds of the time. “These metrics do support that you are slow to deliver, nearly 9 months on average. Do we know why?” The conversation stopped and no answers were offered.
The next statistic, the number of active projects, told the story. The team had over 100 active projects. “You have over 100 active projects yet your total team is how many? 80 maybe?” The team quickly corrected me, the actual answer was 75. “So that’s more than 1 project per team member and let’s remember most of our team also have operational responsibilities to fulfil. Let’s face it, you probably only have 20 or 30 people at most dedicated to projects. No wonder it takes so long to deliver a project, each person is doing 3 or 4 projects in parallel. In trying to do everything you end up being perceived as doing nothing.”
The retort was heartfelt and immediate “it’s not our fault” they exclaimed in unison. The CIO continued on behalf of the group. “The problem is that the executive committee approves projects based upon the requests from the business. If the project looks like it’s a good idea they say yes. So what are we meant to do? We can’t just ignore the decisions of the committee and it’s not our job to say no to the business.”
The conversation continued.
“OK, so what do you do to make it easy for the executive team to prioritise?” Blank looks. “Well, you need the executive to prioritise right?” I receive nods of acknowledgement. “Well, how realistic is it to expect the executive to effectively prioritise 100 projects? To do this effectively the executive would need to understand each project in detail and then be able to compare them to each other. How long would that take? Ages, and even if they had the time, which they don’t, do we really believe that the executive will have the detailed knowledge available to make great calls?” The crowd became a bit fidgety.
“I reckon you need to help them here. In fact, as the paid IT experts I reckon it’s your job. You need to evaluate the portfolio, match the requests to available resources (people / skills and money are the main but not only resources to consider) and present a well researched rationale and executable portfolio for them to consider.”
This scenario, or ones very similar to it play out all the time in large organisations. IT is perceived as being unresponsive and slow to deliver, and it’s true, they are. On the other hand IT often feel victimised as what they have been asked to do is in many instances impractical. Both views are right and governance doesn’t work. So what to do?
I believe the answer to getting governance to work properly for organisations is to reinterpret the classic governance RASCI to being RAFCI (if you are unfamiliar with RASCI and similar frameworks look here). The difference? Replacing the classic IT role of Support for the governance process to be Facilitate the governance process. Playing with words? Yes, but for a reason. To often IT teams see their support role in governance as being passive, that is, they do what they have been asked to do. The result, some variation of the above, governance that doesn’t work. If you want IT governance that works IT need to actively facilitate the process. It’s nearly impossible to facilitate passively and as the facilitator your role is to ensure an effective process, not to assume responsibility for decisions. In other words, you need to make it easy for the executive team to prioritise.
So how do you facilitate governance? In the end it comes back to collaborative conversations across the business. Collaborative conversations that you lead – when I say lead I mean facilitate rather than drive and decide. Consider the following process for structuring your conversation:
- Understand individual priorities by department / team across the business
- Compile all priorities into one list of all requests
- Match requests to available resources and create a proposed portfolio including likely timing for executing the requests (now, next, later)
- Socialise the proposal to key influencers and adjust as needed based on their feedback
- Present the proposal highlighting any conflicts and tradeoffs.
- Record and action decisions.
- Execute based on the agreed decisions.
- Repeat the process and update accordingly.
This looks like a fairly simple process and it is, however it takes time and it requires a focus on conversations and understanding and reflecting both individual and organisational needs. Done well the process works. Better yet the socialisation process almost always resolves timing conflicts without need for escalation to the overall governance body. I have used this process for years and in doing this I have only had 1 major priority conflict that couldn’t be resolved with peer to peer discussion. In the end I escalated this to the executive team for resolution. With all parties around the table and the trade-offs made clear it took 5 minutes to agree a decision.
So, how do you facilitate your governance process? Is there an alternative to “walking the halls” and constantly discussing with your colleagues?