Agility is Not a Budget Line Item

The last year has proven to be tumultuous for many companies and especially enterprise IT organizations. Interestingly, the challenges are not too different from what has existed for some time; a combination of delayed projects, failed attempts at introducing change and cost cutting pressure. These ongoing challenges have forced many of these organizations to put the brakes on when it comes to spending in areas that carry big names such as “enterprise agility” or “transformation.”

The added pressure of  defining “innovation” has meant that some companies are masking the requirements under more commonly accepted spending areas like digital and mobile, all for the sake of being assured funding will happen. Yet, the requirement to dramatically improve the end-to-end flow of the organization still exists and regardless of what names we assign to programs in order to gain funding, we will still need to fix the real problem of how we prioritize value in the business.

Would you agree that too much emphasis exists on labels such as agile, lean, transformation and so forth? Unfortunately, agility is not a budget line item that gets defined and allocated during the annual budgeting rounds. People struggle with defining what it means for them and their organization and ultimately barriers exist to change. If we can’t allocate a number to agility then how else do we get it started apart from introducing tools and methodologies? One way is to get the decision makers and key influencers in the organization to talk openly about the views they have on topics like change and agility. To use a common quip, recognition is the first step to recovery.

So what are some of the common challenges preventing a more deliberate approach to change and that impact agility becoming more prominent in the funding discussion?

  • Prioritization is still a problem
    • The interesting thing is that most people perceive the prioritization problem to be a resource problem; i.e., we don’t have enough people. This is often compounded by their suppliers telling them it’s a resource problem, for obvious reasons. It is, however, more often a structural problem and political challenge within the organization.
  • Capability and competency is a challenge
    • Organizations recognize the need to invest in their people and bring them up to speed on modern ways of working
    • There also appears to be a shift toward doing more work internally – the long-term dependence on large suppliers combined with problematic outcomes is causing many organizations to work with highly skilled niche players who bring core competencies, but can also work alongside their staff to mentor and pass on skills
    • The reality of single-skilled people in siloed organizations is causing problems. Organizations are struggling with how to leverage learning across the wider organization and how to best invest in this is becoming increasingly difficult. In the world of agile, for example, learning how to best apply practices has been limited to short-term classes that don’t yield learning that sticks. With the introduction of work-based learning in the agile space, this changes the landscape and solves this problem for companies and individuals.
  • Organizations are moving away from ‘big project’ mentality
    • There appears to be little to no appetite for massive big program investments. While the interest to deliver software projects incrementally has been in play for some time and has proven effective, the same interest now exists in understanding how to deliver change incrementally across the wider organization.
    • The common pain point here is how do you make incremental change when trying to do system replacements. How do you know and define the appetite for change and do it in a manner that keeps people motivated and engaged and not overwhelmed. There is a real desire to learn how to do this within many organization but for many, years of doing things a particular way prevent them from going forward.

You will likely have other challenges that are equally as prominent to your specific situation so these three are really to get the conversation stirring. It is these types of challenges that have made it harder for companies to be courageous on doing a wider transformation, especially where the application of new thinking makes sense. As it relates to enterprise agility or agile transformation, the trepidation and hesitation often relates to these three areas:

  1. Funding model
    • The overall approach to funding, budget allocation and IT being seen as a cost center.
    • The annual funding cycle drives the exact opposite behavior than an agile approach needs; i.e., it looks for certainty.
    • The funding approach appears to be the sacred cow in most organizations.
  2. Change is still a big word
    1. A general apathy toward change still exists – this apathy is often driven by the fear of disrupting things too much; again, the appetite for change is what is not often defined
    2. A concern in some organizations that change is being driven from, or perceived to be driven from, the IT department. The general view is that IT departments do need to change, but are there to serve the business. In several cases the business does believe they need to change to support IT.
  3. Resource Management
    1. Balancing the cost/investment of staff from both a permanent and contractor/supplier perspective is still a challenge. For example, the inability to view spend on full-time staff as ‘actual spend’ is a common area of neglect.
    2. Organizations need, at the very least, to look at the opportunity cost of their FTE spend and then identify where the real gaps in competency and skills exist. From there, it becomes a productive exercise in determining how to best fill those gaps with outside skills and/or learning.

Let’s bottom-line this discussion. Enterprise agility is an outcome not a budget line item. That said, to get to that outcome, companies can take specific actions that can be funded like any other program effort, yet with very different results.

Contributions to this article were made by my colleague, Brian Hanly

 

This entry was posted in Agile Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>