Hello, and welcome to this podcast on Outside In Software Development, sponsored by IBM's Rational Requirements Composer Team. I'm Bruce Baron, and I'll be interviewing our guest, Carl Kessler, Vice President with IBM Software Group. Carl, in your book, Outside in Software Development, you emphasize the importance of understanding who the different customer constituencies are. You call these projects stakeholders. Why is it so important to business and IT leaders today? The pressures on IT and application development teams continue to accelerate. Operational costs are growing typically at twice the rate of the overall IT budget. And at the same time, app development and support budgets are shrinking. So, Bruce, you're wondering, how does a business succeed and even innovate in this climate? We have to ensure that every project is a winner, which means three basic things: better collaboration between the business leaders and IT staff; more productive project development; and, early predictability that the project aligns with real business needs. The foundation to address all three is to understand who the stakeholders are and what -1-
they really need. Okay, then, let's start with the first item on your list. What are the issues around collaboration between IT and the lines of business? Bruce, nothing is more important than getting the requirements right. Nothing. Perfect, on schedule, error-free code that misses the business goal? It's worthless. So getting the right tools and processes in place to deal with requirements is essential. Look at the data. Consultants tell us that more than 40 percent of development budgets are wasted on poor requirements, and as much as 40 percent of the code that is written goes unused. We've repeatedly heard that as many as 23 percent of projects are canceled before completion. And those are the success stories in this space, compared to the many projects that aren't canceled but which are a distraction of time and money because they simply missed the mark. All right. I feel the pain. What does an IT team need to do to prevent this? There are four items on the work list. First, -2-
we have to overcome the barriers of poor communication, especially when due to language, culture or time zone. Second, get to a common vocabulary and understand the motivation of each of the organizations that support a project. Third, we have to work in an audience suitable way. For example, provide business stakeholders requirements information in forms that they can easily understand. That typically means documents and intuitive visuals of the application flow like process flows and UI storyboards. And then for the designers and developers UML, detailed picture requirements, and all the formats they relate to. Fourth, make sure you can round trip. In other words, as a development team progresses in the design or even coding, we have to allow the business team to understand what's going on and provide feedback -- really early feedback -- so that if it doesn't map to their expectations or needs, we learn about it very quickly. And all four of these, these are why I'm such a big fan of the Rational Requirements Composer, because it makes it easy to accomplish these tasks. Well, Carl, I'm glad to hear you like Rational Requirements Composer. But what are some of the specific -3-
capabilities of Composer that resonates with you as an outside in software developer? Well, there's a long list, Bruce. One important aspect is providing a suite of collaboration methods that are appropriate for the different roles in the business, from wikis, to discussion boards, documents and artifacts that can be updated with real-time information. All of this helps ensure that we focus on gaining consensus on problems and solutions. This collaboration strength is really important and really impressive. You can identify different stakeholder roles and responsibilities, capture the interview feedback by role to create and continuously update a valid vision for the project. Another important aspect is the various visual capabilities for capturing and validating needs. Like storyboards, which are incredibly helpful to aid collaboration between business and IT teams. And use cases, which have become a standard model for developers. This especially helps us specify how we handle scenarios where the business flow threads between different stakeholders, different organizations even within the same firm, and weaves together use cases that, well, in isolation -4-
might seem independent but they're not. To have this level of information accessible to the entire dev team and to have all this visual and textual information interlinked allows for awareness of the business threads that matter. This is an important tool to help cut out needless development of code that won't be used and to emphasize the value of the more essential business capability. The ability to build a process model that exports to the developers as activity diagrams they can design to, that's another big hitter. And finally, Requirements Composer helps folks address a very controversial topic: that is, how much energy to put into requirements artifacts. Carl, can you say more about that? What do you mean by amount of energy into artifacts? Well, Bruce, documents don't automatically create clarity. A 700-page spec that spells things out in great detail may be inappropriate if the business goal, the process models and the use cases could really be captured in a mere 100 pages, or, better yet, captured in the right mix of diagram, text and discussion. This is especially important when you seek agreement on a -5-
project. Getting consensus on those 700 pages will be nearly impossible to do in anything near a timely fashion, and today time is not something businesses can afford to waste. But capturing stakeholder comments on the parts of the story that matter to their role and responsibility, that's fast and clear and effective. Requirements Composer helps teams spend the right amount of energy on artifacts, and allows you to measure outcomes in running productive code that meets the business objectives and not by weighing documents. By the way, this has another important value. One of the messages of outside in software development is that you have to keep your stakeholders engaged throughout the project to help you stay on course and to identify any environmental changes that might affect the way you build and deliver the application. So you need the ability to iterate on the code, get stakeholder feedback and iterate some more. A tool that enables this will go a long way toward assuring that the application you build is the one the business really wants. Requirement Composer's unlimited online access to team documents makes this really easy. It also allows a team to get that continuous feedback without having to spend a lot -6-
of extra resources. With Requirements Composer, the ability to look at UI storyboards and process models, to comment on them directly in discussion threads and to maintain a single authoritative source of data about the project, this is what allows for breakthroughs in efficiency and quality. Wow, that's excellent. So, Carl, before we wrap up today, do you have any final comments? Well, Bruce, the whole idea of outside in software development is to enable teams to dramatically improve the value of their development efforts. The right tools make a huge difference in adopting outside in best practices and getting to that value very quickly. You can tell, I'm very excited about Rational Requirements Composer, because it's a way teams can jumpstart their use of outside in and see meaningful measurable results fast. To learn more about outside in software development, let's ask our listeners to go to www.ibm.com/software/ucd/books.html. Great. For more information about Rational Requirements Composer, listeners can go to www.ibm.com/rational/announce/rrc. Thank you, Carl, for -7-
your time today, and thank you to the audience for listening. [END OF SEGMENT] -8-