by Jenny Boronyak | Dec 15, 2014 | Uncategorized |
Maintaining the service portfolio is a great way to identify service enhancements, document service definitions, and determine which services need to be retired or replaced. But, we have a service catalog, you say. So we’re gonna move along. Wait a minute. Sorry to break the news, but you need to go back and do some work on an actual service portfolio. The service portfolio is not the same as the service catalog. An IT Service Portfolio describes services in terms of business value, specifying what the services are, how they’re bundled or packaged, and what business benefits they provide. It’s articulated from the customer’s perspective and answers the following questions, according to ITIL: Service Strategy: Why should customers buy our service? Why should they buy this service from us? What features and components do customers want and are willing to pay for? What is the demand for the service? What are customers willing to pay for our service? What resources are needed to provide the service? On the other hand, an IT Service Catalog is a service order and demand-channeling mechanism, which is a fancy term for a website. It takes services that are already defined in the service portfolio and describes them as offerings that a customer can buy through an online service catalog. You need the foundation of the service portfolio before creating a useful service catalog. Too many IT organizations rush to define the catalog without starting with the portfolio, causing services to be poorly understood and insufficiently defined. Those organizations are probably currently in the process of overhauling their service catalog, if they haven’t already....
by Jenny Boronyak | Sep 10, 2014 | Agile, Uncategorized |
When the term “agile” comes up in a conversation these days, the mind often jumps to agile software development. But there’s so much more to being agile than delivering software products iteratively and incrementally. If our planning or change strategies aren’t agile, we can forget about being able to deliver the maximum amount of business value possible to our customers. Our entire organization must be agile in order to be able to “keep our finger on the pulse” and rapidly adapt to meet today’s demands. On top of being agile, the most successful organizations out there are also lean mean machines, capable of effectively managing the portfolio to avoid surprises and respond to threats quickly and efficiently. In our webinar last month, The Path to Business Agility, Enfocus Solutions’ CEO John Parker discussed the four components that make up a lean agile business: Enterprise Agile Delivery The agile organization must have the ability to deliver products and services iteratively and incrementally based on discovered and validated customer needs. Agile software delivery is usually the first place organizations start when adopting agile. Many organizations have yet to move onto implementing agile in other areas of the organization, and limit their focus to the responsibilities of the agile team. In reality, the agile team only makes up one part of Enterprise Agile Delivery, and Enterprise Agile Delivery only makes up one of four fundamentals that must be addressed for the organization to be considered agile. In the Lean Business Agility Framework, Enterprise Agile Delivery is achieved via three key elements: Agile Teams (Scrum or Kanban)—Support day-to-day work of self-organized teams (using...
by Karl Wiegers | Sep 3, 2014 | Business Analysis, Uncategorized |
Written by Karl Wiegers and Joy Beatty The leader of a corporate requirements organization once posed a problem. “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “Can you please direct me to any documentation available on how developers should be engaged in the requirements process so I can help them understand the value of their participation?” In another organization, a BA experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked. These questions exemplify the challenges that can arise when trying to engage BAs, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that he’ll get what he needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as you are; if they were, they’d probably all become business analysts! Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not...
by Jenny Boronyak | Jul 25, 2014 | Agile, Uncategorized |
Business agility is more important now than ever, according to a recent report by Forrester Research. In the report, they define business agility as “the quality that allows an enterprise to embrace market and operational changes as a matter of routine.” As Forrester astutely points out, seventy percent of the companies that existed on the Fortune 1000 list ten years ago are no longer in service—the number one cause being the inability to adapt to change. Many organizations have adopted agile methods for software or product development. Agile methods have helped organizations deliver more rapidly, increase customer satisfaction, and improve quality. However, agile development alone does not make the enterprise agile. An agile business must be able to make rapid changes that affect people, processes, data, technology, and rules to support threats and opportunities in the market. The Lean Business Agility Framework™ is here to guide you through choosing the methods that will enable change and achieve business agility in your organization. There are many great existing frameworks and methodologies for implementing agile best practices. However, the Lean Business Agility Framework combines all best practices into one comprehensive guide. The Lean Business Agility Framework was developed by Enfocus Solutions to help organizations visualize what is needed to transform to an agile enterprise. The framework incorporates current trends and integrates various methods from sources such as the Scaled Agile Framework® (SAFe), ITIL®, Lean Thinking, and Lean Startup® into a cohesive approach for moving to business agility. The framework is intended to serve only as a guide and requires an organization to selectively choose the methods that best fit their organization...
by Karl Wiegers | Jul 21, 2014 | Business Analysis, Uncategorized |
There is no single correct way to document specific requirements information. Every BA needs a rich tool kit of techniques at her disposal so that she can choose the most effective requirements view in each situation. In this article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I offer some ideas about how to make that choice. Often, it’s valuable to represent information at both high and low levels of abstraction. The high level offers a big-picture perspective, whereas the low level of abstraction presents the nitty-gritty details. Certain audiences only need the high-level view, whereas developers and testers do need to see all those specifics, as well. An effective requirements analysis technique is to create an alternative view of the requirements from the initial set of information and examine it for problems. Here’s an actual example. I once reviewed a requirements specification for a client who was developing the firmware for a device for testing integrated circuit components. The spec contained a long table that listed the various states this device could be in and what behaviors lead to changes from one state to another. Table 1 shows a portion of this table. I needed to know if all possible states were described and that the allowed state changes were all correctly specified. But how could I judge that? Missing requirements are hard to spot precisely because they don’t exist. I decided to draw a state-transition diagram from the information in the original table, which appears in Figure 1. A state-transition diagram is a simple analysis model that provides a high-abstraction view of such a...
by Karl Wiegers | Jul 17, 2014 | Business Analysis, Uncategorized |
An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable. This article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), briefly describes some alternative types of requirements views to consider. Analysis Models Analysis models are diagrams that present information visually. The table below lists several of the graphical analysis models that are available to the BA. Some of these date back to the structured analysis movement of the 1970s and 1980s. Others are part of the Unified Modeling Language, which provides a rich set of conventions for object-oriented analysis and design. I don’t have the space to describe these various techniques in detail here. See my book with Joy Beatty titled Software Requirements, 3rd Edition (Microsoft Press, 2013) for descriptions and examples of several of these—and other—modeling notations. Note that some requirements authors use the term model to describe any method for representing requirements information, including a list of textual functional requirements. When I say model or analysis model, I’m referring to a diagram that represents requirements information visually, generally at a higher level of abstraction than written requirements offer. I highly recommend that you use standard notations when drawing these kinds of diagrams. There are enough types of models in the software literature to cover nearly every situation, so you should almost never have to invent a new kind of diagram. Remember that these are communication...
