MAKI NG TH E CAS E FOR
SOFTWAR E MANAG E M E NT
By Paul Conte Picante SoftwareFORWARD
MAKING THE CASE FOR "MAKING THE CASE"
aking the case for investing in software management infrastructure -Msystems you need to manage your IT department - is difficult. It'soften met with skepticism or downright hostility, with questions like these: "Why do you need this now??""How will this make IT more productive?" Or worse yet: "All you people in IT know how to do is spend money!"To make the case effectively, you need, first and foremost, a clear viewof your company's business priorities. How can you know what level ofresource is appropriate - or if a project is even worth doing - if you can'tquantify its benefit or express it in terms management will comprehend?How can you know how much to spend on solutions like changemanagement, testing software or high availability, if you don't know howmuch application downtime costs your company? Or the true cost (companywide) of a software bug? Or what competitive conditions are driving yourcompany's priorities? Or what the cost of a missed deadline might be?To form sound judgments about what improvements are appropriateand what level of resource and priorities to apply, you need to understandyour business. And, if you want to be assured that your judgment is in syncwith management's, you need to establish avenues of communication thatare permanent and effective.The business applications you manage represent the accumulation ofthousands of policy decisions made over many years - from what prices tocharge and how to handle refunds to IRS reporting requirements. And youknow as well as anyone: these policies are constantly in flux. Software iscritically important stuff! It shouldn't be that hard to convincemanagement that it needs to be managed gingerly and that, to do it well,you need software tools. Building a successful case requires careful thoughtand planning. It's not easy.But we're here to help!As a continuation of our "Software Development Survival Guide"whitepaper series, we asked Paul Conte, a well-known industry expert, towrite about how an IT manager might approach the question of how tobuild a persuasive case for improving his or her software managementinfrastructure. In our view, Paul outdid himself with one of the best paperswe have ever seen on the subject. We know that you will find thiswhitepaper - packed full of practical advice - an invaluable aid toimproving how your IT department functions by improving your softwaremanagement practices. It also holds the keys for more effectivelyintegrating your efforts with business goals. As a result, you will elevate IT'sprofessional standards - and stature - in your company.Corporate management focuses primarily on accomplishing things thatmeet revenue goals. IT, on the other hand, is perceived as a backroomoperation - a necessary but cumbersome corporate appendage that, inmanagement's view, impedes progress; warranting attention only whenscreens go blank. We all know this grossly underrates the value of IT, butwe are often at a loss as to how to go about convincing people of how vitalthe assets we manage are, or of the risks if something goes wrong.FORWARD
We often compound the low esteem in which we are held, by appearingsluggish and unresponsive. Why? Because things break most often whenthey are changed. The natural consequence of this is a preoccupation withstability that inhibits change rather than promotes it. The sad truth is thatwithout a well-engineered system for managing change, fear sets in. ITbecomes preoccupied with maintaining a stable environment instead of adynamic one.We have all felt this effect. Think a minute about that majorenhancement that has been deferred for months or years because it requiresa database change or affects many system artifacts - the exact number ofwhich might even be a mystery! Without solid software managementpractices and systems to back them up, failure or delay is the likely outcomeevery time you make a software change. Today, software is just too complexand important to be managed by the seat of your pants. A history of failure,with the concomitant stresses it creates within the IT organization, youruser community, and among managers, slows down software developmentand defers any change that is the least bit risky or complex. Progress slows toa crawl and priorities are set perversely, by levels of complexity and personalschedules rather than by busi... [download for more]
