February 07, 2011, 12:58 PM — IT organizations of all sizes struggle with automating their own internal processes, such as incident management, change management and project portfolio management. It's funny, but this is in part because they don't do for themselves what they do for others. An IT project team would never try to buy or design a system requested by a business unit without first defining the project and then thoroughly researching it.
Unfortunately, when an internal IT system is needed, some IT managers (typically not the CIO) push immediately to search for a software product. While they understand the need to estimate project costs and ongoing operating costs, they want to skip steps such as thorough assessment of needs and risks, requirements definition and benefits estimation. They seem to believe they are entitled to circumvent their own process. Beware if at the start of an internal project you hear justifications such as "We are IT professionals and know what we are doing," "Incident management is easy -- just install ITIL-compliant software," and "Since it's only an internal system, the extra work wouldn't get any recognition outside IT. We need to invest our resources where they are visible to our customers or executive management."
But there are many reasons for IT to not exempt itself from its own rules and instead to follow its established applications delivery process (ADP) standards when acquiring new internal systems. First is that IT serves as a role model for non-IT departments. It is hard to ask others to adhere to our standards and methodologies if we do not demonstrate that those standards are important enough and useful enough to follow ourselves.
In truth, very few people get excited about writing a business case, monitoring project quality or quantifying business benefits. But these foundational steps substantially improve the likelihood that the new system will be successfully delivered on time, on budget and with high quality. Following the complete ADP forces the project team to research and analyze the situation thoroughly. Otherwise, it is far too easy to overlook something that could have adverse effects or subtly change operational processes. Inevitably, the ADP helps the project team choose a better software product or a better approach to an in-house system, discover effective ways to improve existing processes, and find ways to accommodate the new system to the organization's culture.
Equally important, following the standard ADP helps build corporate consensus for the way the new system will operate. The phases involving requirements definition and initial evaluation offer an opportunity for all the departments that will use the new system to offer suggestions. Even if their ideas are not incorporated in the final implementation, simply offering potential critics the opportunity to have their ideas considered helps with consensus building and improves post-delivery cooperation. And even critics often have good ideas to improve the new system.
Finally, the ADP's initial requirements, scope and benefits definition form the foundation for eventually determining the value of the new system. Given the financial pressures on IT, it's always good to be able to demonstrate tangible results.
Don't allow your IT organization to circumvent the ADP, or you'll likely pay for it later. Every step you skip leaves the project open to vulnerabilities you would never have consciously accepted. The discipline of an ADP is not merely bureaucratic overhead for everybody else. It is a sound business practice that helps your IT organization and your enterprise achieve maximum benefits from their investment in new IT systems.
Bart Perkins is managing partner at Louisville, Ky.-based Leverage Partners Inc., which helps organizations invest well in IT. Contact him at BartPerkins@LeveragePartners.com .
Read more about management and careers in Computerworld's Management and Careers Topic Center.
