CIO Handbook: Software Development & Maintenance

Whether your team uses Waterfall or Agile methodologies, software development and maintenance may be the IT function that is most visible to the business.

Current State

I am continuously surprised by the state of software development in IT organizations ranging from mid-sized companies to the Fortune 500. My unscientific estimate, based on clients that have requested our services and hundreds (maybe thousands) of discussions with CIOs across the country, is that easily 80% are struggling with their Agile transformation. I have a theory about why that is and will share it later in this article. Bottom line here is that the struggle with the shift to Agile, and possibly the misuse of Agile, is distracting CIO attention away from creating value for the business.

What’s with the Image?

The image at the top of the article illustrates a key difference between Waterfall and Agile. In Waterfall, the scope of a project is fixed and the time and budget will vary. One of the beauties of Agile is that we can fix the time and budget, like the concrete walls of the aqueduct, and so only the scope of an initiative may change.

These differences underscore the whole reason that Agile even exists. It’s all about economics.

Let’s explore…

The Financial Basis of Software Development Methodologies

In the early days of computing, hardware was understandably expensive, just like most innovations before they hit critical mass. The engineers that learned to write software were comparatively cheap and programs were not very complex. Over time hardware costs were coming down and the software engineers were becoming more expensive as software became more elaborate. Remember Moore’s Law? By the mid-1970’s the lines crossed and we needed a way to manage software development costs.

The answer was Structured Analysis and Design. We realized that we could give a wild estimate of time and costs at project inception but the goal posts kept moving as we proceeded with execution. So it became more economical to do a feasibility analysis, based on high level requirements, and report our time and cost estimates. Management decided whether or not to proceed. Then we did detailed requirements, refined our estimates, and went through another approval. That process continued through general design and then detailed design. By time we were ready for programming, we spent a small fraction of the budget and our time and cost estimates were pretty reliable. And, prior to programming, we had four opportunities to cancel a project and avoid costs.

But then a very interesting observation was made. We were developing complex systems over long periods of time, only to learn that the business requirements had evolved to the point that our beautifully designed system was obsolete by time we finished. And countless initiatives were queued up waiting for our attention.

The business world outgrew the economics of structured analysis and design. We needed a new methodology with a better value proposition.

And along came Agile

I have no desire to explain Agile from a software development team’s point of view. The purpose of the CIO Handbook is to look at the world from the CIO’s perspective and in the context of the IT Value Journey.

The beauty of Agile methodologies includes:

• the ability to adhere to time and budget estimates by prioritizing features and being ruthless about work swapping,
• the ability to hold business colleagues accountable through the tracking of scope changes with easy to understand reports like the burn-up chart,
• the ability to end a project when enough value is derived, saving countless sums of money, and
• the ability to move on to new initiatives sooner due to, well, all of the above.

It’s beyond the scope of this article to detail these four points. If you want to discuss any or all in detail with me, or if you’d like us to write more about them, just email Emily at Emily@WolffStrategy.com and we’ll follow up.

I will show an illustrative story, though.

Agile Transformation in Action

I was serving as CIO and SVP of Corporate Strategy for a company that had severe shiny object syndrome. Few initiatives got done, year after year, because something more important always came up. And those didn’t get done either. If this sounds familiar, send me a note and we can share a few laughs.

During our Agile transformation, we continued meeting regularly with the IT Steering Committee, a group very prone to shiny object syndrome.

One day, my team came up with the idea of building a Gantt chart of our projects using writable, magnetic strips stuck to the huge whiteboard in the board room. We could then show what was on our plate and discuss progress. The steering committee loved that display.

And then it happened. The VP of Sales started ranting about an amazing new project he just had to have. So I thought for a moment, pointed to one of the magnetic strips, and explained that the team he needed was working on that particular project.

So I pulled down the magnetic strip, tore it at the point in time where the team was that week, put the completed piece back on the board, and dropped the rest of the project on the floor. Yes, there were gasps.

The VP of sales said he still needed that project that I so rudely destroyed. So I asked him if he needed all of the remaining features. He thought for a moment and said that if we did the next three sprints, he would have enough features to derive a lot of value, and then we could start his new project.

In that moment, our brief collaboration saved the company hundreds of thousands of dollars in what would likely be unused software, and accelerated the start of what proved to be a very valuable project.

That was a key turning point in our Agile transformation.

Here’s why.

Agile is a Little About Process and A Lot About Culture

At the senior level of the company, a room full of leaders gained an appreciation for the economic value of Agile software development. They learned that their partnership with IT would lead to cost savings and new revenue opportunities.

Gone were the days of throwing things over the wall and then pointing fingers at IT when projects were late and over budget, even though the scope creep was usually massive. Instead, we partnered to prioritize features, estimate the value proposition associated with features or groups of features, reduce scope to deliver maximum ROI, swap out features to accommodate scope changes so time and budget remained rigid (i.e. predictable), and put an end to costly shiny object syndrome.

Once the leadership team experienced and understood the economics of Agile, their direct reports and their respective teams came quickly on board. And we grew the top and bottom lines of the business.

You see, the Agile process is actually easy. It’s the cultural change across the enterprise that makes or breaks your Agile transformation. And culture doesn’t change because IT wants to shake up our long standing way of doing software projects. Culture changes because the entire business understands, from the top down, the economic value IT is enabling through Agile.

Apologies in Advance to the Agile Coaches Out There

I have worked with some amazing Agile coaches from fantastic consulting firms. If you’re a CIO or IT Leader, please let me know if you’ve experienced the observation I’m about to share. Most of these folks are “teaching IT how to do Agile” and are not spending nearly enough time working with business leaders to evolve the culture of the company to enable the benefits of Agile.

Measuring the Value of Software Development and Maintenance

This is the most difficult measurement for most IT organizations but is also one that can drive the most improvements and value.

I like to measure four components of software development and maintenance:

• Percent of projects completed on time, within scope, and on budget
• Cost per story point or function point
• Timing of error detection
• Reliability

I’ll explain each of these briefly.

Percent of projects completed on time, within scope and on budget should be the easiest metric. Generally, we look at only IT Steering Committee approved projects, if you have a steering committee. Sometimes, we look at projects included in the strategic plan, if there is an enterprise strategic plan. Find the boundaries that make the most sense for your organization.

If the scope changes along with a budget override approval and timeframe adjustment, you may want to count that as OK. If a scope changes or timeframe is compressed or budget decreased without a corresponding change to the other two sides of the iron triangle, then that project should not penalize IT.

See where this is going? Measuring time, scope and budget forces you to communicate and negotiate with your business counterparts. It pushes accountability onto the rest of the business. IT can’t just be a black hole. Oh, and it forces IT to continuously improve in scoping, requirements gathering and project management.

Next is cost per story point or function point, depending on your software development methodology.

If you’re using Agile, you should know how many story points are delivered with each sprint and who works on them. Add it all up for the year. Include project management time, quality assurance and testing, change control and whatever other processes you may utilize. Divide total cost by number of story points delivered, and you have your cost per story point.

Measuring cost per story point will force you to continuously monitor and improve velocity estimates. It will also encourage IT and the rest of the business to do a better job of prioritizing features and eliminating features that are likely to return low value.

Timing of error detection is a great measure. How many bugs are we finding in unit testing, integration testing, regression testing, or – heaven forbid – after a feature is in production? The later in the lifecycle a bug is detected, the more expensive it is to remediate.

Measuring the timing of error detection delivers a couple of important benefits. First, it objectively shows IT where to improve. Second, IT can show the improvement, in terms of software quality and cost, to the rest of the business.

Finally, let’s discuss software reliability. Measure the reliability of your in-house developed software based on downtime per month. If you’re able to translate that into lost employee productivity, that’s even better. Also measure the time IT spends on break/fix versus strategic development. That’s also a measure of software reliability.

These four measures enable the CIO to communicate the value the Software team is delivering. They also enable you to measure the ROI of software projects.

Project ROI

Let’s start at budget season. The strategy is done and we’re putting together budgets across the company. IT-intensive projects are generally in the capital budget. If that’s not the case in your organization, let’s talk. That’s outside the scope of this article.

Because a project is in the capital budget, that means Accounting needs to know when the project or product goes into service and how much was spent on it. They will amortize the cost over several years. Hold that thought while we shift to the return side of the ROI equation.

Never, ever initiate a project without a business commitment to the value the project will deliver. In other words, the return on investment. If that doesn’t already happen, speak with your CFO. He or she will, almost guaranteed, support the concept.

Now you can prioritize software development work based on the expected ROI. Estimate the IT effort and compare with the expected return. Remember the discussion about cost per story point? When you collect features during budget time, you need to get granular enough to estimate story points, without getting too far into the weeds. Save that for sprint planning. And by measuring, and comparing the actuals, you’ll get better at estimating every year.

So, we have the business owner or executive sponsor estimating the value to be derived from investing IT assets in a project. And we can measure how much it cost IT to deliver that project. Now the fun begins.

Remember those Accounting meetings? You should be meeting quarterly with Accounting. They’re going to want to know how much we spent that quarter in building the asset or executing the project. And they’ll want to know what went live so they can start amortizing that cost.

Whisper in Accounting’s ear, or speak with the CFO, and suggest that we also hold the business owner or executive sponsor accountable for the return on that investment. Now we can show that we invested X dollars of IT resources and got Y dollars of revenue and/or cost savings this year. We can continue to measure that for the number of years that we amortize that asset.

These measures have to be a key focus for the CIO.

Coming Up

The final four articles in the CIO Handbook series will discuss the following topics:

1. Measuring the Value of IT
2. Spirit of Continuous Improvement
3. Unwavering Culture of Teamwork
4. Frequent, Targeted Communication

If you’d like the complete CIO Handbook series in a single PDF document, or if you’ve been following this series and would like to see additional topics covered, please send a note to Emily at Emily@WolffStrategy.com and we’ll follow up accordingly.

 I’ve really enjoyed speaking with several of our readers. As always, if you want to know more, or just can’t wait for the next articles, email Emily at Emily@WolffStrategy.com and she’ll be happy to schedule a call with me.

Larry Wolff is the founder & CEO of Wolff Strategy Partners, a boutique consulting firm specializing in Enterprise Strategy Management and Digital Transformation. Larry has served as CEO, COO, CIO, CTO, chief digital officer, and management consultant for public, private, international, and emerging growth companies. His specialties include corporate and IT strategic planning, technology led business transformation, business and IT turnarounds, merger integration and large-scale project rescues. His methodologies span industries and scale to companies of all sizes.

LWolff@WolffStrategy.com         https://WolffStrategy.com