All Posts in Policies and Procedures

|In: Leadership|Last Updated:

Business executives constantly pressure IT to do more with less, often because they figure anything they don’t understand must be wasting money.

To be fair, it’s a rare IT organization that can’t find some savings someplace. In fact, that had better be true, for this simple reason: In an IT organization that’s had every last dime of waste squeezed out, it’s a sure bet every IT leader’s sole, intense focus is squeezing out every dime of waste. That’s unhealthy. The holy trinity of business is quicker/cheaper/better, and if an IT leader exerts every last erg on cheaper, quicker and better aren’t going to get any attention. Not to mention little details like articulating and implementing an actual strategy.

The good news about the bad news is this: There are situations in which quicker and better do result in cheaper. In many IT organizations, one of those situations is application support.

Application support consists of four major activities: Integration, development, enhancement, and maintenance. Integration is what you do when you implement a commercial application, development is building a system from scratch, enhancement is extending the functionality of an existing application, and maintenance consists of changes you have to make because you have no choice — either because something doesn’t work right or because the rules, such as tax codes, have changed.

Many CIOs, when asked to list their most important processes, put application development at the top of the heap. These same CIOs, when asked for their core architectural principles, include “buy when we can and build when we have to” among the most important.

Pick one.

Which is to say, an important but unrecognized priority for many IT organizations is to implement a formal application integration methodology, rather than try to force the square peg of integration into the round hole of application development. If you aren’t persuaded they’re different, consider:

  • When you develop an application in-house, you can leverage existing data structures, and if you’re very good you can leverage business logic as well. And, you develop it to fit existing platform standards. When you integrate a package, you either re-write some of its code to point at existing data structures, re-write legacy code to point at the new application’s data structures, or (most likely) implement some mechanism or other to synchronize the data that’s redundant between the new application and those already in production. As for the redundant business logic, you document it and live with it.
  • When you develop an application in-house, you can design new business processes from scratch tailored to the business and write the application to implement the new processes. Or, you can document processes that already exist and work well, and write code to support them. With a purchased application you either customize it to support the processes you’ve designed or documented, or you adapt the business to the out-of-the-box processes the new application was designed to support.
  • When you build an application from scratch, you control the architecture. When you buy one, you’re stuck with … ahem, that is, you’re the beneficiary of the architectural decisions built into the application. This goes well beyond platform choices to the heart of the application design philosophy: If the application’s designers started with a data-driven relational design coupled with an n-tier client/server application structure, your own preference for a services oriented architecture is either irrelevant or overrides features, functionality, and other minor concerns.Which is to say, no matter how much you may like dual overhead cams, if the car you buy uses pushrods, you get pushrods.

“Yeah, yeah, yeah,” I can hear you say. “I’m convinced. But how does this help me do more with less?”

The answer is, it can’t. On the other hand, it’s a pretty sure bet that if you don’t have a well-developed set of methodologies for selecting, configuring and integrating commercial packages, you’re doing less with more.

And if you stop doing less with more, it’s going to look like the exact same thing.

Comments

|In: Leadership|Last Updated:

Squeeze a wet sponge and water will come out. Squeeze it again, harder, and you’ll get more water. Try to dry a sponge this way and you’ll get pretty frustrated. No matter how hard you squeeze, it will still end up damp. You can’t get all the water out, but you can damage the sponge.

Squeeze a flabby organization and cost will come out. Squeeze it again and you’ll find more efficiencies. No matter how hard and how often you squeeze, you’ll always see more waste. But like the sponge, when you squeeze an organization too hard you damage it.

That’s where the analogy breaks down: Damage a sponge and you can buy another for a quarter or so. Damage your organization and you’ll spend far more than you ever dreamed of saving to put it back in order.

So in your ongoing quest to “do more with less,” be careful. Organizations are easy to break, and very hard to fix.

Thus far, our quest to do more with less has looked at opportunities for improving alignment with the business. It’s the most painless place to look, but far from the only one. IT’s core processes, for example, often have tremendous potential for cost savings.

Take IT’s delivery management processes: Program management, initiative management, and project management. I’ve seen companies that could cut 20% of their total IT budget without any adverse effects because of bad delivery management. Here’s how: Development and integration projects account for 20% of their IT budgets, more or less, and they never successfully complete projects. If they eliminated the projects altogether, they’d save the money and deliver the same number of project deliverables as before — zero.

Not that this is the right answer. But take a hard look at your delivery management. Many CIOs have a high enough failure rate that by improving these processes they could cut their budgets a modest amount and still deliver more results than they do today. Here are some good places to look for improvement:

  • Do you recognize the difference between programs, initiatives and projects? Programs are indefinite in time and scope, and are chartered to achieve strategic change. They are composed of initiatives, each of which is also indefinite in time and scope, and are chartered to achieve a specific business result or outcome. Initiatives are broken down into a collection of projects, each of which has a clearly-defined schedule (which should rarely exceed six months and never exceed nine), scope and finite list of specific deliverables.

    Assemble all project deliverables within an initiative and you achieve the desired business outcome. Assemble the business outcomes from all initiatives and the program is complete, having delivered the planned strategic change.

    Organize large-scale change this way and it has a chance of success. Charter one big project and it’s guaranteed to fail, because at the time you charter the big project, you don’t even know how success should be defined.

  • Does every change effort have a business sponsor? A real business sponsor, that is — someone with the authority to provide budget and staff, and a personal stake in the results? Kill the ones that don’t. If a business sponsor leaves the company, kill everything he or she had been sponsoring, unless a new sponsor volunteers.If it isn’t clear: Without a sponsor, even projects that succeed will fail, creating deliverables nobody will ever use.
  • Does the culture in IT support good project management? Does the culture in the business support good project management? If not, you need to change the culture, because without a culture that’s receptive to good project management, even the best project managers must fail. They have no chance: Too much of what a project manager has to do involves leadership by persuasion rather than authority, and without a culture that encourages good project management, too few people can be persuaded.
  • Can successful project managers progress in a project management career? Or is the reward for successfully managing a project a promotion out of project management to line management? If you promote your successful project managers to other roles, you guarantee all projects will be led by unproven project managers. The result is predictable.
  • And finally … do you know how to launch projects, so everyone knows the effort has started and everyone knows what the project is supposed to achieve? Even more important, do you know how to finish a project — to declare victory and leave the field of battle?It’s astounding how often bad project completion rates stem from nobody being willing to announce, “We’re done now. Everything else will be delivered in subsequent projects or releases.”

Delivery management is more difficult than operational management for the simple reason that it’s harder to change something than it is to keep it the same.

Don’t make it harder than it has to be.

Comments