Conversations oneffectiveit management


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Conversations oneffectiveit management

  1. 1. Computer Aid, Inc. presentsConversations onEffective ITManagement
  2. 2. WelcomeEffective IT Management:A Bridge Over Troubled WatersEvery task we undertake and every project respect to IT projects, the experience of the result of human nature: people don’twe initiate encounters some degree of risk. the project manager, the maturity of the like to think about, discuss, or expendSuccessful managers identify and evaluate management processes, the completeness much effort on risk mitigation. Projectrisks in order to determine if the risks of the requirements, and the cooperation teams focus their attention on risks thatshould be accepted or mitigated. The risk of business executives are examples of risks impact schedules (“Will we meet ourassessment process should measure the that cannot be mathematically calculated. deadline?”) rather than the future impactprobability (likelihood) of the risk occur- of undetected errors. In the world of How do we measure the potential impact?rence and the resulting impact or severity software maintenance, where business Most failures occur as a partial failure, i.e., of the occurrence. impact is more immediate, the focus is on a single defect, often a single line of code. containment and recovery after a failure Calculating the probabil- How do you measure the “failure” of a rather than prevention. ity of a risk is difficult line of code, when its impact on business especially when there is depends on precisely which line of code Risk assessment is both an art and a little historical data. With has failed? It can be argued the time lag science. The science requires a defined between occurrence and detection results process to consistently evaluate, measure, in the greatest impact. and mitigate risk. The art involves apply- ing subjective values and experience to the This release of Conversations on Effective various components under evaluation. IT Management includes interviews with subject matter experts from the academic The interviews in this report discuss the and business world who discuss risk and value of communicating uncertainties and the processes involved in evaluating and evaluating the probability of failure in the measuring it. Many of the issues are software development life cycle.ii Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  3. 3. Contents 01 Tim Lister Changing Your View of Risk A great risk manager is one who not only watches the risk at hand but also searches through consultation with others for new risks likely to appear as the project’s environment changes. 03 Dr. Victor Basili A Question of Measurement The Goal Question Metric (GQM) paradigm is the most popular way to measure a model. The idea is to build an “experience factory” that will let you predict and optimize everything you’ve got. 05 Dr. Robert Charette No Time to Waste When you’re looking at risk management, there are two things you need to do. First, you need to prioritize your risks. Second, you need to mobilize [your solution] against them. 09 Dr. Robert Charette Why Software Fails As our society comes to rely on IT systems that are ever larger, insight is needed into what may go wrong and what can be done to eliminate or mitigate the risk. 15 Tony Salvaggio IT Risk Management An insightful perspective that deals with how organizations address IT Risk Management on individual projects as well as throughout the global enterprise.Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT iii
  4. 4. A CONVERSATION WITH: Tim Lister Changing Your ViewTim Lister is a principal of theAtlantic Systems Guild, Inc. He ispresently involved in assisting organi-zations with IT risk management and of Riskin tailoring methodologies and select-ing tools for software developmentgroups to increase project productiv-ity and product reliability.Mr. Lister is also a Fellow of theCutter Business Technology Council,a member of the Leadership Groupof Cutter Consortium’s Enterprise A great risk manager is one who not only watches the riskRisk Management & Governance at hand but also searches through consultation with oth-practice, and a Senior Consultant ers for new risks likely to appear as the project’s environ-with Cutter’s BusinessIT Strategies, ment changes.Agile Software Development & Proj-ect Management, and Sourcing and Extracted from an interview more often than not you have to fightVendor Relationships Practices. conducted by Michael Milutis early problems rather than late ones.Mr. Lister and Tom DeMarco are A classic early problem occurs when a CAI: How would you actually define looming deadline looks tight and youcoauthors of Peopleware: Productive risk management and its key compo- nents? may need to hire more people to make it.Projects and Teams and the risk man- Getting people early and integrating themagement book Waltzing with Bears: TIM LISTER: Risk management is the pro- into the project can help you enormously,Managing Risk on Software Projects. cess of unearthing both uncertainty and whereas waiting too long to hire andThey are also authors of the popular risk in projects. It asks what the unwanted train additional people is often wastefulAchieving Best of Class seminar as possible consequences of an event or a and useless. Risk management is about decision are. The essence of risk manage- understanding when to make decisions. Itwell as the course and video sequence ment software is to help us decide whether involves a conversation among all of theControlling Software Projects: to deal with problems before they appear stakeholders – the technical people, theManagement, Measurement, and or to wait till they clearly emerge and then sponsors, the users, the managers aboutEstimation. deal with them as problem management. the best time to make decisions. At risk I’ve been in software all my life, so I may time, we ask the question of whether to be biased, but I think software particularly spend some money to lower the prob- lends itself to risk management because ability of a problem or how to lower the1 CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  5. 5. cost should the problem occur, or some and pay for it later if we judge there is no ing real risk management. A small minor-combination thereof. advantage in tackling it now. ity do it very well. There are also some who say they do it, but what they do isRisk management assumes that careful Another aspect of evaluation is judging identify risk and go back to businessstudy of a plan will result in someone the probability of a risk becoming a prob- as usual. They may have a littlespotting a potential problem. Risk lem. Are we looking at a one in a thou- step early in their processmanagement says, “Let’s identify and sand or a 50/50 risk? And then there’s cost that says, “Identify risk,understand the risks early, determine their evaluation. If the risk hits, what’s it going evaluate risk,” butroot causes, and decide whether it makes to cost us in terms of manpower, delay there is nogood business sense to spend money on schedule, money? In the prioritization evidencebefore or when the problem hits.” There is component, we ask what are the most theyno way to identify all the risks at the start important risks in terms of probabilityof a large project and manage them down. and cost. Finally, there is the strategizingA great risk manager is one who not only component where we ask such questionswatches the risk at hand but also searches as the following: When do we make thethrough consultation with others for call? What are our options here? Hownew risks likely to appear as the project’s long can we delay before we take action orenvironment changes. should we act immediately and mitigate the risk up front?The major components of riskmanagement are identi-fication, evaluation,prioritization, do anything with that information. In genuine risk management, you change something on a big project based on rigorous risk assessment. You change your development strategy, you change the sequence, the definition of the project, the schedule, the staffing, and you keep a de- tailed record and rationale of the decision- CAI: How then would you character- making which led to such changes. This ize the current state risk manage- kind of risk management is rather rare. ment practices throughout corporateand strategizing. Just because somebody IT organizations?identifies or “nominates” (a term I prefer)a risk early doesn’t mean we are going to TIM LISTER: Sadly, I would say the vastdo anything about it. We might accept it majority of organizations are not practic- Continued on Page 19Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 2
  6. 6. A CONVERSATION WITH: Dr. Victor Basili A Question of MeasurementDr. Victor R. Basili is Professor ofComputer Science at the Universityof Maryland. He holds a Ph.D. inComputer Science from the Univer-sity of Texas and honorary degreesfrom the Universities of Sannio(Italy) and Kaiserslautern (Ger-many). He was Executive Director The Goal Question Metric (GQM) paradigm is the mostof the Fraunhofer Center Maryland popular way to measure a model. The idea is to build anand a founder and principal of the “experience factory” that will let you predict and optimizeSoftware Engineering Laboratory everything you’ve got.(SEL) at NASA/GSFC.He is a recipient of numerous Extracted from an interview was developed in the mid-70s. It’s still theawards including a NASA Group conducted by Michael Milutis most popular way in the world to measureAchievement Award, a NASA/GSFC a model – any kind of model. The conceptProductivity Improvement and Qual- CAI: What is the value of process and behind it is really rather straightforward.ity Enhancement Award, the 1997 measurement? Why is it so important? GQM essentially states that before you de-Award for Outstanding Achievement cide what you measure, you need to figure VICTOR BASILI: Whatever the product, out what you want to know. Therefore,in Mathematics and Computer Sci- whether it’s software or something else, you have to constantly track your goals,ence by the Washington Academy of process is important, because it is the only and that’s how you track the data. ThisSciences, the 2000 Outstanding Re- way to optimize what you are doing. And makes it sound simpler than it really is. measurement is important because it’s thesearch Award from ACM SIGSOFT, only way you can observe and get feed-and the 2003 Harlan Mills Award back about what is really happening. CAI: To what extent is a successfulfrom the IEEE Computer Society. measurement initiative contingent upon standard processes? How doDr. Basili has authored over 200 these two things hang together? CAI: There are so many differentpapers, served as Editor in Chief of organizations and so many different consumers of metrics within all of VICTOR BASILI: I have a slightly contrar-several journals (IEEE TSE, Journal these organizations. In light of this, ian perspective on this. I think process isof Empirical Software Engineering) how are we supposed to determine a variable that needs to be tailored to theand program chair and general chair what to measure and why we should specific problem at hand. Although youof several conferences (ICSE). He is be measuring? may have lots of commonalities in youran IEEE and ACM Fellow. VICTOR BASILI: Actually that’s the Goal processes, they each have to be a little bit Question Metric (GQM) paradigm which different for various projects.3 CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  7. 7. While we were at NASA Goddard, we de- The seventh step is to package all of this what is happening, what should have hap-veloped an approach to this called quality knowledge so that it becomes part of your pened, and what will happen. And you’reimprovement. The first step in using this processes, part of your organization, part making changes to the way you under-model is to collect data that doesn’t neces- of the way you think about how you solve stand your organization.sarily tell you where you are or what you’re all of your problems. And then the next At the end of all of this you will end updoing. We called it “characterized” data project comes through and you keep go- with a lean and optimized set of processesbut I heard you guys call it “visualized” ing. You build up and save this knowledge for various classes of problems. Yourand I like that term. I like it because that’s in what we call an experience base. future projects will be different, but that’swhat you are doing – you are visualizing The idea at the root of all of this is to OK because you’ll have classes of processeswhat’s going on in your environment. build an “experience factory” within that will work for different kinds of proj-The second step is to set your goals for an organization. Such an experience ects. You will be able to conduct predic-particular projects and also for the entire base can tell you at any given point tions and optimize everything you’ve got,organization. Where does this organiza- how your projects are being developed. including code.tion want to be and how will this project But while all of this is happening, youcontribute to the overall knowledge that is are also learning that every project is anwithin the organization? experiment. You’re testing and observingIn the third step you choose your process,one that allows you to achieve yourgoals relative to your environment,relative to what the business is about,and relative to what you’ve got in thepresent moment.The fourth step is to do it.The fifth step is to try to do asmuch feedback and analysis asyou can in real time in order tohelp manage the project and tohelp increase learning from thatproject. Your real goal is to learnfrom every project you performat a particular organization.The sixth step is about theanalysis you do after the projecthas been completed. You’vedone as much analysis as youcan in real time, and that’susually very complicated.But now you must do moreanalysis. With post-projectanalysis we try to recognizewhat really happened, whatwas a success, what wasn’t asuccess, etc.Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 4
  8. 8. A CONVERSATION WITH: Dr. Robert Charette No Time to WasteDr. Robert Charette is an interna-tionally acknowledged authorityand pioneer in information systemsand technology, systems engineer-ing, risk management, and the leandevelopment and managementof large-scale software-intensive When you’re looking at risk management, there aresystems. He is currently Presidentof the ITABHI Corporation, an two things you need to do. First, you need to prioritizeinternational high technology your risks. Second, you need to mobilize [your solution]company involved in information against them.and telecommunications systemsmanagement consulting. Extracted from an interview To understand this linkage, you first of all conducted by Michael Milutis need to worry about principles. What isDr. Charette is also on the advisory it, for instance, that you are trying to ac-board of the Project Management CAI: How would you define software complish in terms of managing risk? What risk management? Can you break it are the things that you really value as anInstitute’s Special Interest Group down into key components for us? organization when it comes to risk? Foron Risk Management. He has instance, are you a risk-taking company orserved, additionally, as an elected ROBERT CHARETTE: I look at software a risk-averse company? Which one will de-chairman of the U.S. Software risk management as I look at risk manage- termine your risk tolerance? What are the ment as a whole. It’s all about making things that you value as an organizationEngineering Institute Risk Advisory high quality decisions through high in terms of managing risk? For example, isBoard (1995-1997), as a member quality risks. Risk management is just an open and honest communication of risk aof the National Research Council’s element of decision making and software core organizational principle?Review Committee of Space Shuttle risk management is just a sub-component The second thing you need to worrySoftware Safety (1992-93), and as of systems engineering risk management about is the risk management processVice-Chairman and Chairman of which, in turn, is a sub-component of itself. What do you need to have in place business or enterprise risk management.the National Security Industrial that is visible, repeatable, and measurable I don’t believe that you can say there’sAssociation Software Committee in terms of a risk management process? something called software risk management(1988-89, 1990-91). He is currently without also saying that you’re involved in The third thing is behavior. Behavior ison the editorial board of Software systems risk management or in business risk critical because when we make choices, weQuality Professional magazine. management. The three are really intimately intend to act. When it comes to risky situ- interconnected. This gets back to the linkage ations, we need to think about what we between strategy and technology. want people in our organization to do as well as what we don’t want them to do.5 CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  9. 9. When you’re looking at doing risk man- pen, couldn’t (and shouldn’t) you also be And if you manage to mobilize the rightagement, you need to create a principle- applying those same resources to things resources to deal with one set of risks, youbased, process-focused, behavior-driven that you know really are happening? will simultaneously be making a conscioussystem — a system in which any two of its choice not to mobilize against some other As you can see, the process can quicklypillars support the third. For example, the set of risks, which effectively means that become very messy. It is often quiteprinciples and processes you create must you are accepting those risks. In this counter intuitive, and that is somethingcondition the risktaking behaviors you respect, knowing what your opportunity that is eternally fascinating to me, becausedesire within your organization. Similarly, costs are is going to be key. were dealing here with potentialities,the behaviors and processes should rein- with trade-offs, with futures, and to reallyforce the risk principles you value. understand what is going on with these CAI: The Standish Group reportedYou have to understand what it is that intricacies, your thought processes have that over 70% of software projectsyou want people to do when they are to be broad, deep, and quick. It’s like the undertaken by large, small, and mid-faced with risk, when they are faced with old saying “cheaper, faster, better - pick any size organizations came in over-time,something that may make it look like two.” In managing risk, you oftenthey’re not going to succeed. You have to can identify and prioritize theconvince people to look at things differ- risks, but you may notently than they normally do. But within a be able to mobilizeframework; otherwise you risk making the to actually dealkinds of mistakes that ensue from more ad with them.hoc approaches.What has always been intriguing to meabout risk management is that, superficial-ly, it appears extremely easy. You simplylook at what might occur, you clarify howthese things might hurt you, and then youdevelop some approaches to keep the badoutcomes from coming into being.However, while the process itself canappear to be quite superficial, it quicklybecomes extremely subtle and complex.That’s because risks are perceived andunreal. They are only possibilities. Theyare not actual things. By the time risksbecome actual things, they are alreadyproblems and at that point they cease tobe risks.Furthermore, when you try to manageor reduce these probabilities, you quicklycome up against a perplexing problem:if one allows resources to be spent onthe reduction of risk, will the probabil-ity of project success be increased or, infact, reduced? In other words, if you arespending finite resources to reduce mereprobabilities, things that might not hap-Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 6
  10. 10. over-budget, or not at all. What is the of Defense, where risk management prac-relationship, in your opinion, between CAI: Would you be able to quantify tices have been mandated now for almostthe practice of risk management and the percentage of IT organizations 30 years, is that although a large numberthese success and failure rates? Do that are using risk management of organizations are using risk manage-you think that risk management can practices properly and getting posi- ment, its practice is really just pro-forma.and should be used to address these tive benefits from them?types of problems? In other words, they’re applying a tick- ROBERT CHARETTE: One of my side jobs in-the-box risk management process, andROBERT CHARETTE: Risk management is that I am the Director of Enterprise it’s not affecting organizational decisionis very important for creating successful Risk Management and Governance for making in any way.projects. Effective risk analysis and man- the Cutter Consortium. We did a studyagement will help you identify what your back in 2002 that took a look at orga-assumptions are, what your constraints nizational risk management practice. To CAI: Could you highlight for us what,are, what your real objectives are and what answer your question, we found that 51% in your opinion, might represent the of the organizations we surveyed claimed top three software development riskcan go wrong. Effective risk manage- factors?ment will also highlight the perspectives to be using some sort of formal approachand expectations of the various project to assess or manage risk. In other words, ROBERT CHARETTE: How about the topstakeholders involved. It is a superb tool 51% had some sort of repeatable process 100?for bringing issues to the surface that that they were following. Nevertheless, of the organizations we surveyed, only 39% The primary factor I see is the lack of real-traditionally get glossed over. were applying software risk manage- ism. Our industry likes to over-promiseThat being said, I think we need to make ment practices. In fact, risk management and under-budget. We seem addicted toa distinction between project failures was still a fairly new practice within the unrealistic objectives and unrealistic goals,and project blunders. Many of these so- organizations we surveyed. On average, we even in the face of very complex projects. found that companies had been using risk We pretend that we know more than wecalled project failures are actually, in my management for only four or five years. do, and then feign surprise when thingsexperience, blunders. A blunder is when Consequently, program and project risk don’t go as planned.we don’t do the things that we know weshould be doing and that we are also able management has yet to be integrated into The second major factor lies in the factto do. We know how to create success- a corporate approach to managing risk. that, as an industry, we tend to be veryful IT systems, for instance, but in most What was interesting, though, is that sloppy in terms of our development prac-cases we simply don’t bother to apply the although there was a minority of people tices. If you take a look at the Softwarepractices that are out there for increasing using software-specific risk management Engineering Institutes CMM or CMMIour project success rates. practices, 90% of the people in our survey results, you will see that the vast majority agreed that managing IT risk was either of organizations are still employing undis-Moreover, if you look at the relationship be- ciplined or chaotic development practices. important or very important for achiev-tween risk management and project success Poor project management practice is ing project success. In fact, 75% believed— and Dr. Bill Ibbs over at UCal Berkeley pervasive throughout the development that software risk management made theirhas been doing a lot of research in this area world today. And poor project manage- projects more successful than projects that— you will find that risk management is ment will take a project down faster than didn’t employ risk management practices.the least used of all the project management any other type of risk factor except thedisciplines. Not surprisingly, it’s least used However, if I were to refer simply to my lack of the IT community. The IT community own personal experiences, I would say that the number of people who are using soft- The third major factor revolves aroundsimply does not apply risk management ef- ware risk management practices effectively politics. Projects do not sit in an objec-fectively. The corollary, of course — and this is probably in the 20-30% range, and I’m tive, purely rational vacuum. They areis reflected in Bill’s research, too — is that probably being optimistic here. One of part of a greater whole, one involvingthose organizations that do use risk manage- the problems that I regularly encounter the political realities of an organization.ment tend to have a higher level of project even in organizations like the Department Most people don’t manage organizationalsuccess than those that do not. politics well, nor do they recognize their7 Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  11. 11. importance to project success. because you’ve allocated resources to try to blown risk assessment they should at least avert it. You’re not done until your mitiga- conduct an assumptions analysis, because itsEach of these three factors, and there tion strategy has actually accomplished its the assumptions that underpin your project.are certainly more, must be examined, goals. So once again, in the short term, You need to constantly test those assump-understood, and managed in a very ag- attack those things that are going to cause tions against reality.gressive, realistic, holistic, and honest way. the most amount of damage to you soon-And we should not ever underestimate the est. Second, be aware of the great dangerimportance of honesty. We must always CAI: You mentioned the importance posed by the medium risks, too. Theensure that our objectives are both realistic of having measures, of being able to medium level risks are the ones that reallyand honest. The paradox with honesty, of can hurt you because they are the ones objectively measure against thingscourse, is that you might have a hard time in order to develop a starting point. that you tend to accept. And if you havegetting your project supported if you are What do you think of the relative enough of them, they can overwhelm you. value of external versus internaltotally honest about the risks that exist. The worst thing in the world, in my opin- benchmarking data?The temptation to over-promise is rooted ion, is having lots and lots of medium levelin this paradox. To be unrealistic, however, ROBERT CHARETTE: You have to get risks on your project. I’d much rather man-is to court disaster. That is far worse. information from the inside of your orga- age a project that has lots of reds and greens; don’t give me one with lots of yellows. nization. Set up your measurement pro-What this means is that until we get a grams, start getting data, and at that pointdevelopment environment both at the Finally, keep in mind, despite their very compare what you have with the externalbusiness end and at the technical end, a low corresponding probability, that there world. I should also mention that I rarelyfact-based environment in which we can are still some extremely high consequence see organizations that have effective riskbe honest, then all of our risk factors will risks that may be able to take you out. management programs in place withoutjust be exacerbated. Keep a close eye on them. also having very effective measurement programs as well. It’s kind of a chickenCAI: Once identified, organizations and egg problem, though. Do you start CAI: How would you characterizecould spend years investigating their with a measurement program first and a the importance of processes in allown risk items. In light of this, what risk management program second, or vice of this? From a process perspective,is the most practical approach for versa? I’m not sure, but if your leadership what in your opinion are the criticalproceeding, once the risk identifica- success factors for effective software is willing to simply state “Where are we?”tion phase has been completed? risk management? that’s a good start.ROBERT CHARETTE: There are two ROBERT CHARETTE: First of all, youthings you need to do. First, you need to need to have some measures. You needprioritize your risks. Second, you need to to have information that is fact-basedmobilize against them. or evidence-based. Whether or notRegarding prioritization, there are two you call them software measures, orsimple questions that you can ask yourself performance measures, it doesn’there: 1) what is going to hurt me the really matter to me. What I’mmost; and 2) what is going to hurt me interested in is having somethingsoonest? You must deal with these risks that I can objectively measureright away; specifically, the ones that are against, and then predict against.going to keep you from accomplishing I also need a process that’s goingthe next milestone or the next objective in to help me evaluate not only myyour schedule. objectives, but also my assump- tions and constraints. We tend notRegarding mobilization, and this is an area to look at our assumptions. One ofthat people tend to forget about, you must the things that I frequently tell organi-remember that a risk hasn’t gone away just zations is that if they can’t perform a full-Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 8
  12. 12. Dr. Robert Charette Why Software Fails As our society comes to rely on IT systems that are ever larger, insight is needed into what may go wrong and what can be done to eliminate or mitigate the risk. Excerpted from IEEE Spectrum information technology industry for 20- Magazine, September 2005 Issue some years. It’s probably apocryphal, but for those of us in the business, it’s entirely Have you heard the one about the plausible. Why? Because episodes like this disappearing warehouse? One day, it happen all the time. Last October, for vanished — not from physical view, but instance, the giant British food retailer J from the watchful eyes of a well-known Sainsbury PLC had to write off its U.S. retailer’s automated distribution system. $526 million investment in an automated A software glitch had somehow erased supply-chain management system. It the warehouse’s existence, so that goods seems that merchandise was stuck in the destined for the warehouse were rerouted company’s depots and warehouses and elsewhere, while goods at the warehouse was not getting through to many of its languished. Because the company was in stores. Sainsbury was forced to hire about financial trouble and had been shuttering 3,000 additional clerks to stock its shelves other warehouses to save money, the manually. employees at the “missing” warehouse kept This is only one of the latest in a long, quiet. For three years, nothing arrived dismal history of IT projects gone awry. or left. Employees were still getting their Most IT experts agree that such failures paychecks, however, because a different occur far more often than they should. computer system handled the payroll. What’s more, the failures are univer- When the software glitch finally came to sally unprejudiced: they happen in every light, the merchandise in the warehouse country; to large companies and small; in was sold off, and upper management commercial, nonprofit, and governmen- told employees to say nothing about the tal organizations; and without regard to episode. status or reputation. The business and This story has been floating around the9 CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  13. 13. societal costs of these failures — in terms of wasted taxpayer and government IT projects underway that totaled $20.3 billion. Inshareholder dollars as well as investments that can’t be made — 2004, the U.S. government cataloged 1,200 civilian IT projectsare now well into the billions of dollars a year. costing more than $60 billion, plus another $16 billion for military software.The problem only gets worse as IT grows ubiquitous. This year,organizations and governments will spend an estimated $1 tril- WHEN A PROJECT FAILS, it jeopardizes an organi-lion on IT hardware, software, and services worldwide. Of the zation’s prospects. If the failure is large enough,IT projects that are initiated, from 5 - 15% will be abandoned it can steal the company’s entire future. Inbefore or shortly after delivery as hopelessly inadequate. Many one stellar meltdown, a poorlyothers will arrive late and over budget or require massive rework- implemented resource planninging. Few IT projects, in other words, truly succeed. system led FoxMeyer Drug Co., a $5 billion wholesale drugThe biggest tragedy is that software failure is for the most part distribution company in Car-predictable and avoidable. Unfortunately, most organizations rollton, TX, to plummet intodon’t see preventing failure as an urgent matter, even though that bankruptcy in 1996.view risks harming the organization and maybe even destroy-ing it. Understanding why this attitude persists is not just an IT failures can also stunt economicacademic exercise; it has tremendous implications for business growth and quality of life. Back in 1981,and society. the U.S. Federal Aviation Administration began looking into upgrading its antiquated air-traffic-SOFTWARE IS EVERYWHERE. It’s what lets us get cash from an control system, but the effort to build a replace-ATM, make a phone call, and drive our cars. A typical cell phone ment soon became riddled with problems. Bynow contains 2 million lines of software code; by 2010 it will 1994, when the agency finally gave up on thelikely have 10 times as many. General Motors Corp. estimates project, the predicted cost had tripled, more thanthat by then its cars will each have 100 million lines of code. $2.6 billion had been spent, and the expectedThe average company spends about 4 - 5% of revenue on delivery date had slipped by several years. Everyinformation technology, with those that are highly IT dependent airplane passenger who is delayed because of— such as financial and telecommunicationscompanies — spending more than 10% onit. In other words, IT is now one of thelargest corporate expenses outside em-ployee costs. Much of that money goesinto hardware and software upgrades,software license fees, and so forth, buta big chunk is for new software proj-ects meant to create a better future forthe organization and its customers.Governments, too, are big consum-ers of software. In 2003, the UnitedKingdom had more than 100 majorComputer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 10
  14. 14. gridlocked skyways still feels this cancel- and problems and increase the likelihood to correct the error will likely be manylation; the cumulative economic impact of failure. times greater than if they’d caught theof all those delays on just the U.S. airlines mistake while they were still working on Consider a simple software chore: a pur-(never mind the passengers) approaches the initial sales process. chasing system that automates the order-$50 billion. ing, billing, and shipping of parts, so that And unlike a missed stitch in a sweater,Worldwide, it’s hard to say how many a salesperson can input a customer’s order, this problem is much harder to pinpoint;software projects fail or how much money have it automatically checked against the programmers will see only that errorsis wasted as a result. If you define failure pricing and contract requirements, and are appearing, and these might haveas the total abandonment of a project arrange to have the parts and invoice sent several causes. Even after the original errorbefore or shortly after it is delivered, and to the customer from the warehouse. is corrected, they’ll need to change otherif you accept a conservative failure rate calculations and documentation and then The requirements for the system specifyof 5%, then billions of dollars are wasted retest every step. four basic steps. First, there’s the sales pro-each year on bad software. cess, which creates a bill of sale. That bill In fact, studies have shown that softwareWHY DO PROJECTS FAIL SO OFTEN? is then sent through a legal process, which specialists spend about 40 - 50% of theirAmong the most common factors: reviews the contractual terms and condi- time on avoidable rework rather than on■ Unrealistic or unarticulated project tions of the potential sale and approves what they call value-added work, which goals them. Third in line is the provision pro- is basically work that’s done right the first■ Inaccurate estimates of needed cess, which sends out the parts contracted time. Once a piece of software makes it resources for, followed by the finance process, which into the field, the cost of fixing an error■ Badly defined system requirements sends out an invoice. can be 100 times as high as it would have■ Poor reporting of the project’s status been during the development stage. Let’s say that as the first process, for sales,■ Unmanaged risks is being written, the programmers treat If errors abound, then rework can start■ Poor communication among every order as if it were placed in the to swamp a project, like a dinghy in a customers, developers, and users company’s main location, even though storm. What’s worse, attempts to fix an■ Use of immature technology the company has branches in several states error often introduce new ones. It’s like■ Inability to handle the and countries. That mistake, in turn, you’re bailing out that dinghy, but you’re project’s complexity affects how tax is calculated, what kind of also creating leaks. If too many errors are■ Stakeholder politics contract is issued, and so on. produced, the cost and time needed to■ Commercial pressures complete the system become so great that■ Sloppy development The sooner the omis- going on doesn’t make sense. practices sion is detected and■ Poor project management corrected, the better. In the simplest terms, an IT project It’s kind of like knitting usually fails when the rework exceeds theOf course, IT projects rarely a sweater. If you spot a value-added work that’s been budgetedfail for just one or two rea- missed stitch right after for.sons. The FBI’s VCF project you make it, you can simply unravelsuffered from many of the All of which leads us to the obvious ques- a bit of yarn and move on. But if youproblems listed above. Most tion: why do so many errors occur? don’t catch the mistake until the end,failures, in fact, can be traced you may need to unravel the whole SOFTWARE PROJECT FAIL-to a combination of techni- sweater just to redo that one stitch. URES have a lot incal, project management, common with airplaneand business decisions. Each If the software coders don’t catch their crashes. Just as pilotsdimension interacts with the omission until final system testing —others in complicated ways or worse, until after the system hasthat exacerbate project risks been rolled out — the costs incurred11 Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  15. 15. never intend to crash, software develop- tle luggage around frequently derailed. changing fast and promising fantastic newers don’t aim to fail. When a commercial Eventually, United Airlines, the airport’s capabilities, it is easy to succumb. Butplane crashes, investigators look at many main tenant, sued the system contractor, using immature or untested technology isfactors, such as the weather, maintenance and the episode became a testament to the a sure route to failure.records, the pilot’s disposition and train- dangers of political expediency. The IT debacle that brought down Fox-ing, and cultural factors within the airline. A lack of upper-management support can Meyer Drug a year earlier also stemmedSimilarly, we need to look at the business also damn an IT undertaking. This runs from adopting a state-of-the-art resource-environment, technical management, the gamut from failing to allocate enough planning system and then pushing itproject management, and organizational money and manpower to not clearly beyond what it could feasibly do.culture to get to the roots of software establishing the IT project’s relationship tofailures. A project’s sheer size is a fountainhead of the organization’s business. failure. Studies indicate that large-scaleChief among the business factors are Frequently, IT project managers eager to projects fail three to five times more oftencompetition and the need to cut costs. get funded resort to a form of liar’s poker, than small ones. The larger the project,Increasingly, senior managers expect IT overpromising what their project will do, the more complexity there is in both itsdepartments to do more with less and do how much it will cost, and when it will be static elements (the discrete pieces ofit faster than before; they view software completed. Many, if not most, software software, hardware, and so on) and itsprojects not as investments but as pure projects start off with budgets that are too dynamic elements (the couplings and in-costs that must be controlled. small. When that happens, the developers teractions among hardware, software, andPolitical exigencies can also wreak havoc have to make up for the shortfall some- users; connections to other systems; andon an IT project’s schedule, cost, and how, typically by trying to increase pro- so on). Greater complexity increases thequality. When Denver International ductivity, reducing the scope of the effort, possibility of errors, because no one reallyAirport attempted to roll out its auto- or taking risky shortcuts in the review and understands all the interacting parts of themated baggage-handling system, state testing phases. These all increase the likeli- whole or has the ability to test them.and local political leaders held the project hood of error and, ultimately, failure. Sobering but true: it’s impossible toto one unrealistic schedule after another. AFTER CRASH INVESTIGATORS CON- thoroughly test an IT system of any realThe failure to deliver the system on time SIDER the weather as a factor in a plane size. Roger S. Pressman pointed out in hisdelayed the 1995 opening of the airport crash, they look at the airplane itself. Was book Software Engineering, one of the clas- (then the largest there something in the plane’s design sic texts in the field, that “exhaustive test- in the United that caused the crash? Was it carrying too ing presents certain logistical problems... States), which much weight? Even a small 100-line program with some compounded the nested paths and a single loop executing financial impact In IT project failures, similar questions less than twenty times may require 10 manyfold. invariably come up regarding the project’s to the power of 14 possible paths to be technical components: the hardware and Even after the executed.” To test all of those 100 trillion software used to develop the system and system was com- paths, he noted, assuming each could be the development practices themselves. pleted, it never evaluated in a millisecond, would take Organizations are often seduced by the worked reliably: 3,170 years. siren song of the technological impera- it chewed up tive — the uncontrollable urge to use the All IT systems are intrinsically fragile. In a baggage, and the latest technology in hopes of gaining a large brick building, you’d have to remove carts used to shut- competitive edge. With technology hundreds of strategically placed bricks to make a wall collapse. But in a 100,000- line software program, it takes only one or two bad lines to produceComputer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 12
  16. 16. major problems. In 1991, a portion of because they involve tradeoffs based on nizational environment. Does the airlineAT&T’s telephone network went out, fuzzy or incomplete knowledge. Estimat- have a strong safety culture, or does it em-leaving 12 million subscribers without ing how much an IT project will cost phasize meeting the flight schedule aboveservice, all because of a single mistyped and how long it will take is as much art all? In IT projects, an organization thatcharacter in one line of code. as science. The larger or more novel the values openness, honesty, communication, project, the less accurate the estimates. and collaboration is more apt to find andTHE PILOT’S ACTIONS JUST BEFORE a It’s a running joke in the industry that IT resolve mistakes early enough that reworkplane crashes are always of great interest project estimates are at best within 25% of doesn’t become investigators. That’s because the pilot is their true value 75% of the time.the ultimate decision-maker, responsible A recent report by the National Auditfor the safe operation of the craft. Simi- There are other ways that poor proj- Office in the UK found numerous cases oflarly, project managers play a crucial role ect management can hasten a software government IT projects’ being recom-in software projects and can be a major project’s demise. A study by the Project mended not to go forward yet continuingsource of errors that lead to failure. Management Institute, in Newton Square, anyway. The UK even has a government PA, showed that risk management is the department charged with preventing ITBack in 1986, the London Stock Ex- least practiced of all project management failures, but as the report noted, morechange decided to automate its system disciplines across all industry sectors, and than half of the agencies the departmentfor settling stock transactions. Seven nowhere is it more infrequently applied oversees routinely ignore its advice. I callyears later, after spending $600 million, it than in the IT industry. Without effective this type of behavior irrational projectscrapped the Taurus system’s development, risk management, software develop- escalation — the inability to stop a projectnot only because the design was excessive- ers have little insight into what may goly complex and cumbersome but also be- wrong, why it may go wrong, and whatcause the management of the project was, can be done to eliminate or mitigate theto use the word of one of its own senior risks. Nor is there a way to determinemanagers, “delusional.” As investigations what risks are acceptable, in turn mak-revealed, no one seemed to want to know ing project decisions regarding tradeoffsthe true status of the project, even as more almost impossible.and more problems appeared, deadlineswere missed, and costs soared. Poor project management takes many oth- er forms, including bad communicationBad decisions by project managers are which creates an inhospitable atmosphereprobably the single greatest cause of soft- that increases turnover; not investing inware failures today. Poor technical man- staff training; and not reviewing the proj-agement, by contrast, can lead to technical ect’s progress at regular intervals. Any oferrors, but those can generally be isolated these can help derail a software project.and fixed. However, a bad project manage-ment decision — such as hiring too few THE LAST AREA THAT INVESTIGATORSprogrammers or picking the wrong type of LOOK into after a plane crash is the orga-contract — can wreak havoc.Project management decisions are oftentricky precisely13 Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  17. 17. even after it’s obvious that the likelihood practices known to avert mistakes are line of code is written, both the customerof success is rapidly approaching zero. shunned. It would appear that getting and Praxis agree on what is desired, whatSadly, such behavior is in no way unique. quality software on time and within is feasible, and what risks are involved, budget is not an urgent priority in most given the available resources.IN THE FINAL ANALYSIS, big software fail- organizations.ures tend to resemble the worst conceiv- After that, Praxis applies a rigorous devel-able airplane crash, where the pilot was Even organizations that get burned by opment approach that limits the numberinexperienced but exceedingly rash, flew bad software experiences seem unable or of errors. One of the great advantages ofinto an ice storm in an untested aircraft, unwilling to learn from their mistakes. In this model is that it filters out the manyand worked for an airline that gave lip a 2000 report, the U.S. Defense Science would-be clients unwilling to accept theservice to safety while cutting back on Board, an advisory body to the Depart- responsibility of articulating their ITtraining and maintenance. If you read the ment of Defense, noted that various requirements and spending the time andinvestigator’s report afterward, you’d be studies commissioned by the DOD had money to implement them properly.shaking your head and asking, “Wasn’t made 134 recommendations for improv- SOME LEVEL OF SOFTWARE FAILUREsuch a crash inevitable?” ing its software development, but only 21 will always be with us. Indeed, we need of those recommendations had been actedSo, too, the reasons that software projects true failures — as opposed to avoidable on. The other 113 were still valid, thefail are well known and have been amply blunders — to keep making technical board noted, but were being ignored, evendocumented in countless articles, reports, and economic progress. But too many of as the DOD complained about the poor and books. And yet, failures, the failures that occur today are avoid- state of defense software development! near-failures, and plain able. And as our society comes to rely old bad software Some organizations do care about software on IT systems that are ever larger, more continue to quality, as the experience of the software integrated, and more expensive, the cost plague us, development firm Praxis High Integrity of failure may become disastrously high. while Systems, in Bath, England, proves. Praxis Like electricity, water, transportation, and demands that its customers be committed other critical parts of our infrastructure, to the project, not only financially, but IT is fast becoming intrinsic to our daily as active participants in the IT system’s existence. In a few decades, a large-scale creation. The company also spends a tre- IT failure will become more than just an mendous amount of time understanding expensive inconvenience: it will put our and defining the customer’s requirements, way of life at risk. In the absence of the and it challenges customers to explain kind of industry-wide changes that will what they want and why. Before a single mitigate software failures, how much of our future are we willing to gamble on these enormously costly and complex systems? We already know how to do software well. It may finally be time to act on what we know.Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 14
  18. 18. A CONVERSATION WITH: Tony Salvaggio, CEO of CAI IT Risk ManagementAnthony (Tony) Salvaggio is CEOand President of Computer Aid,Inc. (CAI), an international IToutsourcing firm that is currentlymanaging active engagements withover one hundred Fortune 1000companies and government agenciesaround the world. CAI employs Extracted from an interview array of technologies and projects thatover 2,500 associates across the conducted by Michael Milutis we are working with at any given time,United States, Europe, and Asia. and the various cultural and regulatoryMr. Salvaggio founded CAI in 1981 CAI: What is your perspective on Risk environments within which we function,and since then CAI has been lever- Management in the IT sector? How both domestically and internationally. It do you address this on individual requires continual organizational learningaging the lessons of manufacturing projects and also, throughout the along with the rigorous documentationin their development and mainte- enterprise? and institutionalization of that learning.nance of software. Prior to founding This is also tied to another principle, and TONY SALVAGGIO: Risk ManagementCAI, Mr. Salvaggio spent 22 years is something that has real meaning for a strong corollary; namely, how do we getat IBM. In 2003, Mr. Salvaggio us. On any given day, CAI is managing our teams to continually perform close towas a recipient of Ernst & Young’s approximately 2,500 IT professionals their highest levels, on a daily basis, given“Entrepreneur of the Year” award. around the world who are charged with our total organizational knowledge and executing very specific software develop- experience over two decades?In 2004, he founded the IT Metrics ment and maintenance projects. In alland Productivity Institute. of these initiatives, CAI is contractu- ally bound, either partially or totally, to CAI: Could you share with us some of the specific strategies that you execute to specific targets, objectives, SLAs have employed for addressing these or deadlines. As a result, our organiza- challenges? tional survival is dependent upon making sure that none of our people do anything TONY SALVAGGIO: Please recognize that that will get us sued or lose customers. I whatever strategies I share with you come get frightened just thinking about it. from over two decades of continuous learning, experience, and evolution. As a We have survived over the course of two result, how we function today is dramati- decades by focusing very carefully on the cally enhanced from how we functioned implementation of Risk Management best five years ago. And this will be true once practices. This is no small challenge given more in another five years. the size of our organization, the broad15 CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  19. 19. Nevertheless, to answer your ques- person, something that is known intion, we have stayed focused over the the industry as the “expert judgment”years on several overarching strategies method. Moreover, estimates can befor mitigating IT risk. These strategies politicized, so any estimate should beare primarily a response to the project validated and scrutinized by a secondfailure statistics that have plagued the or third party, independent of theIT industry since its inception. Such origin of the initial estimate.failures represent a major risk for all IT You must also make sure that you areand software organizations, but they always tracking the estimate versus thealso represent an enormous opportunity actual, at a work component or moduleand by developing strategies that address or project level, and you must have athis directly, we’ve been able to trans- method for feeding these actuals backform such risks into an area of competi- into your estimation process, sotive advantage. that you can continually learnFirst of all, and perhaps most importantly, from experience and historyit is almost impossible to recover from and so that you are able tosystemically poor estimation and bad adapt on a daily basis.scope management. Consequently, it is of This data should also bethe utmost importance to be continually very visible to allbuilding up the best possible estimation members of theand scope management practices within project teamthe organization, given the total amountof organizational knowledge, past andpresent, that is available.Consistent with this, estima-tion should never bethe product of anindividualComputer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 16
  20. 20. and to management. And whateverthe project size, a project plan must beupdated with actuals and reported toall key stakeholders on at least a weeklybasis.We are also very big believers in workreview processes and methodologies.Wherever possible we use a projectoffice approach. Depending on thesize and inherent risk of each project,this approach has evolved into vari-ous management and reporting sys-tems. We believe that with projectsthat are only managed and reviewedby the project team and the projectteam’s direct management, serioustrouble may not be recognized untilit is too late.What ties all of this together? Timereporting. It’s not glamorous, butyour estimates and project manage-ment techniques can only be asgood as the data that goes in, andall of this ties back to how peopleare measuring themselves, whattasks they are working on, and howlong they are taking to completethese tasks. Consequently, timetracking must be task based and itmust be detailed, thorough, andimmediate. By immediate, I mean“in real time.” Time and task dataentered at the end of the workweek is essentially meaningless andwill not provide the same level ofinsight as real time task data.Finally, we have learned thatwe will make mistakes. We willoccasionally estimate a projectbadly or badly scope a project,especially when dealing with newtechnologies or unique projects.We treat these experiences andthese lessons learned as “valuable17 Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT
  21. 21. corporate assets” that must be storedin our corporate memory and lever- Time tracking must be task based and it must beaged throughout the enterprise. This detailed, thorough, and immediate. Time and taskis clearly where we have done our bestwork over the years. Wherever possible, data entered at the end of the work week is essen-we have put what we have learned tially meaningless.about estimating, tracking, reporting, planning, and management into we completed the development of an to. Darwin famously said that it is real time software systems “Automated Project Office,” which is not the strongest of the species who that institutionalize our essentially a software system that brings survive, but the ones most responsive collective learning aggregate organizational knowledge and to change. I would counter that it is and that can be review processes to bear on every one not necessarily the ones most respon- leveraged through- of our activities and projects in a real sive to change, but the ones most able out the enterprise. time, internet based manner. This ef- to learn and to keep learning. Certainly We use these fort has been a five year, multi-million learning is a form of change, but in our systems continu- dollar project from conception through industry, it is the most critical and it ally to manage our development and is now implemented will remain so as long as the technolo- projects and our within our business. gies and projects we face in the 21st work and we insist century continue to increase in scope that our aggregate In short, I would say that we have and complexity and as long as the pro- organizational knowl- developed a strategy for managing the cess of globalization continually forces edge must be totally risk of IT project failure that is rooted us to find new and innovative ways to available to all proj- in the automation and institution- do more with less. ects and all individu- alization of organizational learning. als. Most recently, This is really what it all comes down CAI is the creator of Automated Insight®, Tracer ®, and the IT Metrics and Productiv- ity Institute. Automated Insight provides a convenient, proactive, and quantitative approach for enabling project governance and managing risks throughout project lifecycles. Tracer is a process configuration management tool for IT organizations. Tracer defines and enforces processes that can vary based on the type of service event; it logs and tracks specific events, allows detailed tasks to be defined, and provides detailed time tracking. Additional capabilities include automated estimating, scope change management, and SLA management. The IT Metrics and Productivity Institute is an international consortium of industry experts, fully funded and supported by CAI, and dedicated to the creation and dis- semination of best practice standards in the IT and software industry. The Institute’s research focus areas include software development methodologies, software maintenance methodologies, software project management, software risk management, software estimation, and the science and practical application of software measurement.Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT 18
  22. 22. Fix it Now, or Fix it LaterContinued from Page 2 shape them from there or cancel them. Fi-CAI: Could you give us a list of the nally, there is the risk factor of communi-most common project risk factors? cation. I see failures of communication all dangerous to be frank and say, for exam-TIM LISTER: The first one is technical the time, particularly with the growth of ple, “I think we are very unlikely to finishrisk. Most commonly this involves using a multi-site projects over the last 10 years. this new project in 10 months.” Peoplenew product or tool for the first time. You Not only multi-site but multi-nation. I’ve will say, “You haven’t even tried, come on,know you’re not an expert at it and you’re got a project right now that’s in Massachu- give it a whirl; you’re just trying to get outtrying to figure out whether the tool does setts, Ireland, and India – all at once! You of work; you’re whining.” There’s a verywhat it says it does or whether we’ll have want to have one architecture, one design, strong, “Rah, rah, we can do it” attitude,to find something else because we don’t one product and you discover that there’s especially in top management. If you can’tknow how to use it. We also have to esti- a huge risk that these teams won’t stay say what you believe without incrimina-mate the cost of the learning curve. This locked together. You have a lot of extra tion, you have a big problem. I rememberissue of technical novelty is very common work to keep them coordinated. talking to one organization about risksin our business. I like to joke with my The problem is always in the interfaces. and having them tell me, “You know ifclients about the fact that once you get Each team thinks they are doing fine but you bring up a problem here, you own it.”really good at something, you never use it they may be out of whack with the others. This happens on major performance is-again. We finally master a tool and boom Consequently, you have to do a lot of sues where the boss typically says, “You’re– the world changes and there are new work to prevent large scale problems at absolutely right. I want you to handletoolsets, new ideas, and new messages that the end. Then each team thinks it has its that.” When that happens, no one is goingconfront us. piece done and we discover that they just to open his mouth. Instead he will think, do not hook together. I guess I’m getting “I’ll act shocked and surprised when theThe second big risk category is a set of problems hit because I’m not going to beorganizational risks. Schedule risk is one old but I feel it’s nice occasionally to find a project where everyone’s in the same the person responsible for a performanceof the most common and serious of these. miracle with an underpowered system.”With almost all projects, a deadline is building. Then you can talk to each other every day and brainstorm when problems So I think it’s largely cultural. I am notset too early. From a risk point of view, a sociologist, but I think Americansyou need to keep a sense of humor about arise. That this is so rare now adds enor- mous complexity and increased chances have the hardest problem in the softwarethis. Typically, an organization decides industry with risk management. I thinkthey have to release a product by, say, for communication risk. it is used more often and more effectivelythe second quarter of 2007 even though in Europe. Years ago I was in Finland andthey have very little understanding of the CAI: Must organizations have stan- they were so good that I had nothing toprocess. This creates a whole family of dard processes and tracking in place say to them. They are much more frankrisks on expectations. Then the parameters to be successful with risk manage- about problems. It’s the same in Theare set: for example, we think 10 people ment? Netherlands at Philips: the way they talkshould be able to do this in the next 10 about their problems and make their deci- TIM LISTER: I think I’m going to surprisemonths. From a risk management point sions is very straight-forward, dispassion- you. Practical tracking and planning is, ofof view, the schedule and budget may be ate, realistic. I wish we could bring that to course, valuable. But the big issue is reallybased on mere wishful thinking. the early stage of our projects as well. On cultural rather than quantitative or metric.A good risk manager discovers this as the There’s not just Brownian motion going the other hand, what makes America greatdefinition of the project’s work is revealed. on out there. The fundamental issue is is the way we do things because we don’tHe then calls for real estimates rather than how well the people in your organization know we can’t do them.guesswork. I think we get horrible prob- deal with straight talk. Too many orga-lems in our business from childishly set nizations just have a hard time learningdeadlines with no credentials. We need to about what might go wrong before it doesdo reasonable estimations and then either go wrong. In too many companies, it’s19 Computer Aid, Inc. presents CONVERSATIONS ON EFFECTIVE IT MANAGEMENT