Getting from Software Projects and Maintenance to Agile Programs

There is significant discussion in CIO circles on moving more IT spend out of the maintenance and into either enhancement work, new product development, innovation, or even R&D. As I’ve explored this issue, there are a number of causes of high maintenance worth exploring:

1)    The product requires technologists to respond to customer issues, address service level deficiencies, investigate root causes to issues, manually ‘fix’ things in the database, investigate security concerns, respond to performance issues, and other activities that require significant effort or expertise. This may be because the product was poorly built up front, or its usage outgrew the intended design/architecture.

2)    Complex and/or outdated architectures can also lead to costly maintenance. If you’re running a proprietary database on a VAX, you can bet the maintenance costs will outweigh costs of running this same database on modern architectures.

3)    Similarly, outdated application architectures or integrations with third party products/systems can lead to high maintenance costs. Related to this are third party issues, let’s face it, if you’re system integrated with a poorly managed third party system, then your maintenance costs will be higher.

I have a couple of conceptually simple solutions to these issues and will present one in this post..

Funding Models and Terminology Issues

Traditionally, IT projects are funded as investments. Once the project completes (and if it completes) the technology effectively moves to a “day 2” maintenance model to allow for “minor” enhancement work. We can debate what constitute “minor” and what level of funding is needed for day 2 models – which is the heart of the issue – but its sole is in the terminology.

No to Maintenance, Yes to Agile Programs

Maintenance has a lot of negative connotations.It covers a lot of territory in terms of scope (see maintenance causes above) but also it implies minimal activity. My car needs some basic maintenance every 7500 miles and it's not an ongoing exercise. Maintenance also doesn't account for business driven changes where they are driven by functionality, performance needs, or competitive needs. In simple terms, "maintenance" is an 'old' model that doesn't work in today's fast paced competitive landscape.

So how can we turn this around. I'm not going to be too scientific here and guessing others have a more detailed methodology, but here it goes:
  • Year 1 of a project delivers one or more product phases at cost $X.
  • Fund year two no less than 40% of $X and more depending on business need
  • Fund year three no less than 30% of $X and more depending on business need
  • Assess a rebuild/port/platform integration in year four at no less than 80% of $X
  • Total cost over four years: no less than 2.5 * $X.
  • Governance should be applied when the business can't adequately fund products according to a defined model. (Another post?)

Basic hypothesis: A professional software shop charges customers approximately 20% of license costs as maintenance. An in house team is not likely to be efficient, so I doubled this for year two. If the business has few demands/needs on this project in year three, then the minimum can go down as the "team" (more on this later) becomes more efficient. But in year four, given the pace of technology and changes in customer needs, assume that the product needs rework. Since this product largely has a working model, the rework should be a fraction of the original investment unless new needs are also factored in.

Why is this important and how to implement
  • As IT organizations, we get into the maintenance death spiral on products because we under-invest in them on an ongoing basis. This model presents a more holistic TCO for the technology/product.
  • Don't want to fund it this way and leaning Buy before Build? Remember, vendors should be able to provide some economies, but only if they scale and have an operational model for whatever customizations they support. (Another post?). Guess what - many don't!
  • This funding model leads to leveraging teams. Development teams get efficient by leveraging platforms and process, not by executing on individual projects. So instead of ramping up a team to build, then putting the asset into maintenance, we now can model an ongoing team that can take development into years two, three, four.
  • Although the number of teams and their size will vary year to year, this is a continuous program. As a continuous program, I would simply apply an agile development process and call it an ongoing agile program. Why? Call it marketing. Call it better IT/Business alignment. But the scope of agile delivery is greater than just maintenrance activities and it provides significantly higher business value.... 
 Now that we've 'solved' the funding for this type of program....


  1. Anonymous7:27 PM


    Great Post and thought provoking. Very innovative idea to get out of the maintenance spiral.

    Question - Some applications need pure technology/ infrastructure upgrades and these are not driven by changes in business demands but purely driven by technological changes like introduction of newer technology platform or new version of DB. Would you also consider them as Agile development projects? (Very similar to what you describe in year 4 but just driven by technology).


  2. Changing the 80/20 norm for maintenance/innovation is largely dependent on the rate of new product development, and number and complexity of products. New products have several stages in their life cycle - market introduction, growth, maturity, market saturation, and market decline. If we choose to have a high velocity of new product development because of the state of our product suite, we have to be mindful (obviously) of the 80 / 20 ratio, and how we can affect it. This implies that as CXOs, we can drive the ratio by (1) fostering product innovation through creative and cost-effective product development strategies (20 + y), and (2) reinforcing the need to continually drive product maintenance costs downwards by improving efficiencies (80 - x). We have to do both, not one or the other.


Comments on this blog are moderated and we do not accept comments that have links to other websites.


About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld,, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.