ll/1P7 ER IIX PgfMgif Wednesday, April 11, 2:35 PM... Barton's headache worsened. Leaning back in his seat, hands folded in his lap, he'd ceased trying to get into the conversation. What had begun as a project status review had deteriorated into open conict. The combatants represented the company's two major IT subgroups, Loan Operations Systems and Customer Support Systems. At rst, the meeting had been orderly and polite; each person took turns walking through his or her list of projects in progress, explaining the reasons for \"red,\" \"yellow,\" or \"green\" status indicators beside each project. The lists showed a lot of green, some yellow, and a small amount of red. Oddly, Barton noticed, both departments seemed to have exactly the same proportion of green, yellow, and red status projects. The trouble had started when Rebecca Calder, a brilliant young fast tracker from Loan Operations Systems, had commented that one of her yellows might better be classied as a green. Iorge Huerta, an ex- perienced senior analyst from Customer Support Systems, seemed an- noyed by the remark and made a point of saying the same thing about one of his own yellows. In the course of the ensuing argument, it be- came apparent to Barton that many of the green and yellow projects on both lists were behind their original schedule and over their origi- nal budgets. Although he found it educational to listen for a while, 89 This document is authorized for use only by Kemo Camara in ClS41050 Fall 2023 taught by Gregory Reinhardt, University of Louisville from Aug 2023 to Dec 2023. The Road of Trials eventually Barton raised his hand and shifted forward, which both Calder and Huerta correctly interpreted as a signal to shut up. Then he asked a question: \"Why is it that we are behind schedule and over budget on so many of these projects?\" Huerta was quickest to respond: \"It's because we lack discipline in the project management process.\" Body language told Barton that Cal- der disagreed, as she had with pretty much everything else Huerta had said for the past ten minutes. Barton glanced in the direction of Cal- der's squirming, but raised a nger to keep her from interrupting. Bar- ton turned back to Huerta: \"Explain.\" \"It's simple, really,\" said Huerta. \"We don't plan enough, and we don't establish project scope sufciently in advance. We don't do a good enough job of obtaining a general agreement on what we are trying to accomplish with a project. Because of this, success is a moving target. We suffer again and again from scope creep. Because there's a failure to establish the clear requirements of business users at the beginning of a project, often project managers nd themselves under pressure to de- liver in excess of what was originally agreed. The scope of the original plan can start to move and continue to move. If the project manager isn't alert, the requirements will constantly change. The project spends long periods of time on delivering nothing, continually reviewing and altering direction.\"1 This sounded like a reasonable answer to Barton. But he pressed Huerta: \"And your suggested solution to this problem?\" \"More planning,\" said Huerta, \"and more discipline in decision making. We spend more time up front in formal planning activities, working with users to understand their needs and to help them under- stand what is possible in what we are planning to do. If we do this well, we'll be able to strike a rm agreement in advance on what the project will accomplish, which will provide a basis for a disciplined process for achieving those objectives. If it's not part of what we're trying to accomplish, we don't do it, no matter who's asking for it. There may be some things outside the scope that have to be added, but we can do that deliberately too. If we're going to expand the scope, we should take ofcial notice that we're doing that and adjust our estimates of the time and resources it will take to complete the project too.\" 90 This document is authorized for use only by Kemo Camara in CIS41050 Fall 2023 taught by Gregory Reinhardt, University of Louisville from Aug 2023 to Dec 2023. Project Management Barton was impressed. In just a few words, Huerta had presented a diagnosis and a prescription for cure, both of which sounded plausible. But Calder was still squirming in her seat. Barton turned to her. \"Rebecca, you don't buy this logic?\" \"No, sir, I do not.\" \"Why not?\" She sighed. \"Iorge has just presented to you the solution that we've been trying to implement since the beginning of time; it never works.\" \"Why not?\" \"Because the diagnosis is awed. He thinks we should spend more time and effort making sure we understand the requirements up front. I don't think the users' requirements even eXist in advance, and they are certainly not knowable in advance\" \"Ooooh, now we're getting metaphysical,\" ridiculed Huerta. Barton didn't like his tone. \"I didn't let Rebecca interrupt you,\" Barton said to Huerta, \"so let her nish.\" Huerta shut up. \"Go on,\" Barton said. \"Well, the difculty is that we discover many of the important re- quirements only as we begin to try to create the system. Communicat- ing intangible ideas is very difcult. Only as they start to interact with the system do users begin to see more concretely what is possible and come to better understand the questions we are asking them. Only as our discussions begin to refer to actual system features do we really understand what they are saying they need. Users necessarily change their minds about what they want as they come to understand more clearly what is possible. An approach that denies or even discourages such changes by claiming that it is more 'disciplined' to stick to the 'formal plan' is just denying reality.\" Huerta couldn't help himself: \"So we just launch off on a project, eX- pecting to gather our requirements as we go . . .\" Barton turned sharply, and his words trailed off. \"No,\" said Calder, \"we don't just 'launch off'! We spend some time in advance trying to gure out what we can of what the system needs to do, but at some point we need to start building the system so that we can discover the things we'll never discover if all we do is think about, talk about, and plan a hypothetical system. Iorge implies, along with 91 This document is authorized for use only by Kemo Camara in CIS41050 Fall 2023 taught by Gregory Reinhardt, University of Louisville from Aug 2023 to Dec 2023. The Road of Trials a lot of other management gurus, that if we are just more careful and thorough, if we just spent enough disciplined time in the requirement- gathering phase, we could get pretty close to understanding what we need, and from there it would just be a matter of executing to plan. Their prescribed solution is more planningmore time spent study- ing and not doing anything. I don't buy it. Let's admit that even if we think really thoroughly about things in advance, we still won't antici- pate important problems . . .\" \"That's what contingency planning is for,\" interjected Huerta, quickly. \"Contingency plans are for problems you can anticipate,\" Calder retorted. \"A big chunk of the problems with most projects are things you can't anticipate. If we buy into the philosophy of project manage- ment that considers unanticipated problems to be a result of awed planning, we doom ourselves to repeat our failures. Every time you have a scope creep issue, you blame something you should have done on an earlier phase of the project. Never mind that the thing you sup- posedly should have done better earlier was impossible.\" \"It's not impossible!\" Huerta practically shouted. Barton did not stop him this time. \"A couple of years ago, we were developing a user interface with a notebook metaphor. On the screen, it looked like a notebook page, and there were tabs at the edges so you could ip to a different page. We had made an arbitrary decision to place the 'spine' of the notebook at the side, and that was built into the design of the underlying software infrastructurethe 'object classes,' if you want the technical term. When we showed it to users, they said, 'Looks great, but can you put the spine of the notebook at the top rather than on the side?' And we did it! We spent weeks making a change because we had not captured that detail in advance. We could easily, with a truly disciplined process, have picked up this requirement in advance. Or, alternatively, a good process would have labeled this change for what it is: scope creep. We would have said back to the users, 'No, we're not going to do that, it doesn't matter that much.' And we'd have been right. They would have gotten accustomed to the spine at the left rather than the top after less than an hour us- ing the system. A disciplined process helps us avoid these kinds of problems.\" 92 This document is authorized for use only by Kemo Camara in CIS41050 Fall 2023 taught by Gregory Reinhardt, University of Louisville from Aug 2023 to Dec 2023. Project Management \"Not a fair example,\" said Calder. Barton settled back to listen and rest his eyes. His head was pounding. \"Not all examples are like that. Last year, I was working on a project where we had peak load prob- lems. We would have had a tremendously difcult time imagining in advance that the load requirements would be so high; nobody foresaw the business events that caused such high peaks in load on the system.\" \"That could have been anticipated, with the right process . . .\" \"Yeah, well maybe it could. In an ideal world without taxes, crime, or war. Maybe. But how condent are you that you can anticipate every problem, or even every important problem, on the large complex sys- tems we work on all the time? You can't do it. You'd have to be prescient or superhuman to anticipate all of the possible emergent issues. The idea that a coherent and complete set of customer requirements can be captured in advance is pure ction, at least in most cases. And it makes no sense to give advice that, in effect, says, 'We need you to be more superhuman.' \" \"What makes no sense,\" said Huerta, \"is to encourage people to just race off at the start of a project, like a bunch of IT cowboys, justifying their actions on the grounds that 'you can't anticipate all the important problems anyway, so we might as well race ahead so that we can begin making messes.' \" Calder did not respond immediately. This pause to think and change the tempo of the argument impressed Barton. Her argument had begun to impress him as well. There was a welcome moment of silence before she replied, quietly, \"Actually, that's exactly how I see it. We should get on with making the messes so that we can deal with them sooner rather than later. You will inevitably have messes. Better to have them sooner rather than postpone them. Early messes on a project may not always be pleasant; they may look like management messes. But better early mess than late-breaking disaster. Fail faster to succeed sooner. Fail forward.\" Barton stirred. \"Is that it?\" he asked Calder. \"Is that your proposed solution?