Reining in IT

Software Development

February 2006

In the corporate world, governance has gained greater visibility over the past few years. The Sarbanes-Oxley (SOX) Act has forced U.S. companies to improve their approach to financial governance, and the Health Insurance Portability and Accountability Act (HIPAA) has spurred similar changes in employee health management. Attention is now turning toward IT—and rightly so, considering the Y2K fiasco, the dot-com meltdown and our high rate of project failure.

The Need for Control

Effective IT governance provides several benefits to your organization. First and foremost, it helps you to ensure that the right IT investments are made and that your money is spent wisely. How do you accomplish this? By determining which projects to invest in through portfolio management of your organization's potential projects, ongoing projects and existing systems (see "Extending the RUP with the Portfolio Management Discipline," www.en terpriseunifiedprocess.com/essays/ portfolioManagement.html). Also, investing in enterprise architecture efforts to help you identify and then build to a common infrastructure ensures that funds are spent wisely (see "Extending the RUP with the Enterprise Architecture Discipline," www .enterpriseunifiedprocess .com/essays/enterpriseArchitecture .html). This common infrastructure also enables an effective approach to reuse, which is often referred to as asset management (see "Extending the RUP with the Strategic Reuse Discipline," www.enterprise unifiedpro cess.com/ essays/strategicRe use.html). Note that the referenced articles assume that the RUP is your underlying development process; however, they provide advice that you can adopt within any IT organization.

Second, your IT governance efforts provide senior management with insight into your overall IT efforts. You can't manage something if you don't understand it. Third, your IT governance program should clearly define lines of authority and accountability. Project teams should be given the authority to fulfill their mission, the development of high-quality, working software that meets the changing needs of their stakeholders. The people involved should in turn be held accountable for fulfilling that mission.

To ensure accountability, your governance program should define preventive, detective and corrective controls. Preventive controls include training to ensure that developers have the required skills, as well as an appropriate software process for developers to follow. Detective controls could include the adoption of common development guidelines for all to follow and a collective ownership philosophy so that low-quality work can't be hidden. Corrective controls define the consequences of not following policies and enforce the application of those consequences.

When it comes to effective IT governance, organizations face significant challenges. Because there is no defined body of knowledge or even an accepted set of practices that define proper approaches to IT, many organizations find it difficult to determine how to govern IT. Furthermore, one size does not fit all—an IT governance strategy that works for a large bank could be a complete disaster for a small software firm, or even for a similar, competing bank. Your organization is unique, so you need to define a strategy that reflects your situation.

False Sense of Control

It's easy to think of IT governance as a strict old governess responsible for raising her employer's children. The governess tells the children what to do, teaches them how to do it properly, and scolds them when they're caught misbehaving. Each time she tells the children what she expected of them, the children reply, "Yes Miss Butternutjob, we'll try to do better"—and as soon as she turns her back, they resume their shenanigans. Sounds like your organization? Well, you're not alone.

To forestall this problem, many traditional organizations put a bureaucratic, "documentation-driven" governance program in place instead of a goals-driven one. Management often insists on a standard set of artifacts from each project team. This is clearly a questionable strategy: A 50-person project team working together for two years will do something different than a five-person team working together for four months. A system developed internally should clearly be approached differently than a system whose design and implementation is outsourced to an offshore company. It simply doesn't make sense for project teams to deliver the same sets of documentation.

Worse yet, documentation has very little to do with predicting the success of a software project. Have you ever seen a project team write a comprehensive requirements document and get it accepted by the stakeholders, only to go ahead and build something else? Or the stakeholders say that's not really what they wanted after the team built the system to spec? Or the team delivers late and over budget, even though they consistently reported that things were going well? Have you ever seen a team write a detailed architecture model and have it reviewed and accepted by really smart people, only to see the architecture fail in practice? Or the developers simply ignore the architecture model and build the system the way that they want to? Have you seen any of this happen under the guise of management oversight? If so, that's not effective IT governance.

[click for larger image] Agile Change Management: Scrum's approach to change management, like other agile processes, is straightforward, enabling developers to treat requirements as a flexible, prioritized stack.

True Control

"Agile Change Management" (see page 44) overviews Scrum's approach to managing changing requirements. The rules are straightforward. At the beginning of each monthly sprint (iteration), the development team asks its stakeholders for funding. Based on the team's past performance, the stakeholders give it a budget for the month, perhaps $100,000. The team commits to implementing $100,000 worth of the highest-priority functionality remaining. If stakeholders wish to change, add or reprioritize any of the remaining requirements, they are welcome to. If they wish to change this month's requirements, they merely define a change request, prioritize it and put it on the stack. At the end of the month, the development team demonstrates what it's built, so that the stakeholders can determine if they received good value for their investment.

With this approach, developers are clearly accountable for producing working software every month. They can't elicit requirements or formulate architecture for months on end, only to produce nothing of value. Furthermore, they have to produce high-quality software or they'll quickly find themselves with an unmaintainable mess—and they'll lose their funding.

Similarly, stakeholders are accountable for the project's scope and budget. They have complete control over identifying and prioritizing requirements, so they can no longer claim that they're not getting what they asked for. They're accountable for the budget because they can invest in the teams that provide good value, and they control how much is spent. If the development team does a good job, a smart stakeholder will give it $125,000 for the following month; if it does a poor job, it might get only $75,000 and be put on warning.

Most traditionalists claim that this is too radical; that it would never work because you don't know how much you're going to spend on the project, nor can you predict how long the project will take. Nothing could be further from the truth. With this approach, stakeholders can spend as much as they want and can fund a project for as long as they want. Want to limit your budget to a million dollars? Spend only that much. Want a system delivered in six months? Fund the team for only that long.

As we all know, the traditional community has a spectacularly poor track record of estimating time and budget at the beginning of a project, at any rate. Smart IT managers know that they can't accurately estimate early in the project, and instead revise their work throughout the project's life span. Even smarter managers (the agile ones) understand that it's a waste of time lying—er, I mean putting together an early project estimate. Interestingly, few experienced stakeholders believe the estimates provided by IT anyway; they just choose to go along with the lies because that's what everyone else does. My advice? Spend less time playing financial games—instead, invest the effort in building software.

Over the past year or so, Alistair Cockburn has published his experiences with governing agile project teams. In "A Governance Model for Agile Projects" (http://alistair.cockburn.us), he notes that consistent status reporting makes it easier to compare and monitor projects, but that it can force-fit teams into unnatural slots that hamper their productivity. You don't want your IT governance cure to kill your patient—the project team. Cockburn suggests that teams report status via a collection of intention-completion bars, one for each critical deliverable of the project team. Each bar depicts percentage completion and the current status of that deliverable (red, yellow or green). Every team reports status in the same manner, but does so for the aspects that are pertinent to their situation.

Avoiding Horrors

Don't underestimate the cost of your IT governance program. SOX is a perfect case in point. The U.S. government's original estimate for a company to comply with SOX was 25 work hours per year. It was later revised to 383 hours per year (about $91,000). In March 2005, a survey of 217 companies showed the yearly cost of compliance to be an average of $4.36 million (www.fei.org/404_ survey_3_21_ 05.cfm).

Furthermore, don't let your IT governance program curtail your ability to improve. Base your IT governance strategy on open and honest communication and effective collaboration, not command and control management.

Scott W. Ambler is a Canada-based software process improvement (SPI) consultant, mentor and trainer with Ambysoft Inc. He has written several books and is a regular speaker at software conferences worldwide.