Better Software - June 2008 - (Page 32)

in Fiction it might be ok to say that the emPeRoR is ideally dRessed FoR a PaRty at the nUdist beach, bUt in most oRganizations telling the tRUth is a classic “bad caReeR move.” While it is true that there are some things for which every project should prepare, this is a short, generic, and generally useless list. Rather, you should focus on these following items: • Politically unmentionable risks • Uncontrollable factors • Unquantifiable risks • The unexpected Politically Unmentionable Risks Many organizations have the habit of “shooting the messenger” whenever there is bad news. So when a project crashes and burns, the developers and the users are not at all surprised, but the “senior” managers, who were supposedly providing “adult supervision” of the project, are utterly shocked that the project has failed, or they simply declare “mission accomplished” and leave the users to deal with the mess of a buggy, partially implemented system. I recently observed this on an important project with a mandated completion date dependent on procuring some hardware that was required for a five-week suite of system tests. The hardware arrived a month late, but five weeks after the original planned start of system testing “questions were being asked” about why the testing was not yet complete. Several months later, the schedule slip had not been officially recognized in the project plan; instead there were repeated pronouncements that the timeline was “not allowed to slip.” Eventually, when the original project completion date was near, management was forced to acknowledge the slip. When the people in charge of managing the risk are the ones creating the risk, it is not hard to see that risk management is an illusion. Examples include: 32 BETTER SOFTWARE JUNE 2008 • Hoping that a major slippage can be caught up • Mandating that a project be completed by an arbitrary due date that is a “stretch target” • Delaying the start of a project but still expecting the original completion date • Assigning unskilled developers to a project but not allocating any time for training and mentoring It should be possible for team members to point out these problems and management to correct the mistakes. Unfortunately, life does not work that way. In fiction it might be OK to say that the emperor is ideally dressed for a party at the nudist beach, but in most organizations telling the truth is a classic “bad career move.” So what really happens? All minor risks are identified and “mitigated” while there is a big elephant in the room that nobody is talking about. Sometimes, if you are lucky, you can get an outsider to raise the issue, but in most cases it just sits there unmentioned, the project crashes and burns, and the failure is attributed to other causes, generally something outside everyone’s control. There is a simple fix for project politics, but it can be difficult to implement: Ensure that there is a balance of power between the business and technology sides of the project. This is necessary so that each side can hold the other accountable for its promises and decisions. Too often this is a one-way proposition. UncontRollable FactoRs Whenever I need some light relief on a project, I look at the mitigation strategies that are in place for the various risks www.StickyMinds.com that have been identified. In most cases the “strategy” is nothing more than a reactive policy to work harder, spend more money, reduce the project scope, or slip the schedule. Rarely does the mitigation strategy include anything that implies that the team will have to think deeply about how to address the actual circumstances at the time the risk is detected. Most risk mitigation strategies fail to take into account that software development is not predictable—there is an essential, uncontrollable uncertainty and randomness to it. Back near the dawn of software development, when people actually did empirical studies of how projects turned out, they found that early estimates of project size could easily be off by a factor of four [2]. So something that was estimated to take one personyear could take anywhere from three person-months to four person-years. This level of uncertainty is not acceptable to senior managers, so most organizations have mandated a limit to the variability of estimates. Often a project is allowed to miss its estimates by up to 20 percent (maybe even 50 percent in more enlightened organizations). But all the managers do by mandating a 20 percent limit is make it politically unacceptable to talk about the real project variability, which is twenty times larger. Organizations must adopt approaches that acknowledge and embrace uncertainty because many factors that influence a project are outside of the project’s control. This means organizations must select leaders who are open to alternatives and are not afraid of surprises. Unfortunately, most organizations do not follow this practice, in part because it is not easy to find such leaders. http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - June 2008

Better Software - June 2008 Contents Mark Your Calendar Contributors Technically Speaking eLightenment Code Craft Test Connection Management Chronicles Agile Model-Driven Development The Myth of Risk Management Stop the Insanity! Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.