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 system. It shows the various states the system could be in at a given time (rectangles), the permitted transitions between states (arrows), and the conditions and actions that lead to each transition (could be written on the arrows if desired). Other conventions have similar notations variously called a state machine diagram, statechart diagram, or simply a state diagram.
Sure enough, I found some problems with this diagram, shown with the dotted red lines in Figure 1. First, the table contained no functionality to get to the Off state! That is, I expected to see an arrow in the diagram going from Shutdown to Off, but I found no requirement to make this happen. Also, the table didn’t mention the possibility of an error occurring while in the Running state. Thus, by creating this second view as an analysis tool, I identified a couple of missing requirements. Better now than later, I always say.
Table 2 suggests techniques that are appropriate for representing various types of information at both high and low levels of abstraction. Chapter 12 of my book with Joy Beatty titled Software Requirements, 3rd Edition (Microsoft Press, 2013) provides more details on many of these methods and contains references to additional sources to learn about these techniques. Use this table to help you select appropriate techniques for documenting your requirements information.
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 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 tools. If you make up your own kind of picture using some other language of symbols, no one else will know how to read it. This rather defeats the purpose of communication. Instead, take the time to learn about the various modeling notations. You can practice with them by documenting an existing system, so you learn which types of models are useful for showing certain kinds of information.
Decision Tables and Decision Trees
These are tabular and graphical techniques, respectively, for representing complex logical expressions (such as a sequence of if/then statements) and the associated system behaviors. They are a great way to ensure that you have written requirements to cover the system's behavior with all logical combinations of conditions. Complex logic often leads to missing requirements because certain combinations of ANDs, ORs, ELSEs, and NOTs were overlooked. Decision tables and trees are particularly good techniques to spot exceptions whose handling hasn’t been specified.
Functional requirements describe the behavior of the software to be built. Test cases describe ways to determine if the correct requirements have been implemented properly. Functional requirements and test cases represent two complementary ways of thinking about the software system. The first is from a constructive perspective (let me describe how to make it), and the second is from a destructive perspective (let me try to break it).
One school of thought maintains that detailed written requirements aren’t necessary; user acceptance tests provide an adequate description of what needs to be built. I prefer to think of specifications and test cases as being complementary views of the requirements. Thinking about the system from both perspectives often reveals inconsistencies and gaps in the BA’s and user’s knowledge.
Prototypes and Screen Designs
When prototyping, the BA is taking a tentative step from the requirements domain into the solution space. A prototype is like an experiment. It tests the hypothesis that the requirements you have developed to date are accurate and complete. Most people find it more insightful to work with a prototype than to read through a long list of functional requirements. A prototype serves as a tangible first cut at some portion of the possible product.
A low-resolution prototype, such as a wireframe, provides the gist of the proposed user interface, whereas a high-resolution prototype presents detailed screen designs. However, even a detailed visual prototype does not depict the details hidden behind the presentation layer. A prototype doesn’t show input field interactions or describe how the system processes input stimuli to produce output responses. As with analysis models, a prototype is a useful but insufficient means of “documenting” requirements; you still need to record the details somewhere.
Tables and Structured Lists
If multiple requirements are worded similarly except for a particular change from one requirement to the next, consider grouping them in the form of a table or a structured list. Grouped requirements are more maintainable because a global wording change need be made only once. This is more concise than writing out all the individual requirements in detail, and the differences between the similar requirements will be obvious. For traceability purposes, each item in a list should receive a unique identifier. Following is a set of similar requirements from an actual SRS, shown in the original style (bulky, repetitive, and eye-glazing) and then as a much more compact structured list. The list form more efficiently communicates the same information and still provides a unique label for each requirement.
SGML.Insert.23: The product shall provide a facility that will insert SGML data corresponding to signature block formats selected by the user from among a set of available boilerplate signature blocks.
SGML.Insert.24: The product shall provide a facility that will insert SGML data corresponding to leaveout formats selected by the user from among a set of available boilerplate leaveouts.
SGML.Insert.25: The product shall provide a facility that will insert SGML data corresponding to caption formats selected by the user from among a set of available boilerplate captions.
SGML.Insert: The product shall provide a facility that will insert SGML data selected by the user from among a set of available boilerplate formats for the following:
.23: Signature blocks
Mathematics provides a precise, concise, and unambiguous language for represent certain types of knowledge, particularly that associated with performing computations. Some types of computational information are better represented in the form of tables. Two examples are interest rates as a function of investment bond term and discount percentages applied to volume purchases of a product.
Always keep in mind that specifying requirements is a communication process. Every BA should develop a rich toolkit of techniques for representing information effectively. If natural language is the best technique in a particular situation, fine: use it. But first ask yourself whether some other method, either by itself or in conjunction with the text, will do the job better.
If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish prayer, and a Scandinavian proverb: “When the map and the terrain disagree, believe the terrain.” Unfortunately, we have no absolute “terrain” for requirements: every representation is a map! Even though you can’t tell which representation is correct, differences between them indicate problems. In this article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I’ll explain the value of creating more than one view of your requirements.
Consider the figure below. A use case presents a high-level view of requirements from the user’s perspective. It describes some goal the user needs to accomplish with the help of the system, expressed as a sequence of interactions between a user and the system that leads to an outcome of value. A primary purpose of the use case technique is to help the BA derive the functional requirements that developers must implement to let users perform a use case. These functional requirements represent a second, more detailed view. The BA might also draw graphical analysis models, diagrams that represent additional views of the requirements. The BA should be able to relate the functional requirements to elements shown in the models to make sure that these complementary views agree.
Suppose a tester were to write some test cases—thereby creating yet another view of the requirements—based on the use case. Now the BA can compare the test cases with the functional requirements and the analysis models to look for mismatches. You might find that a particular test case cannot be “executed” with the current set of functional requirements. (Note that you don’t even have to have any executable software to benefit from this sort of conceptual testing.) Or you might discover that a specific functional requirement is not covered by any test case. Such disconnects can reveal missing and unnecessary requirements, as well as missing and incorrect test cases.
Ambiguities, assumptions, or missing information in the use case description can lead the BA and the tester to different conclusions, which they can find by comparing the various views derived from the use case. Every time I’ve performed this kind of comparison between test cases, functional requirements, and other views, I have discovered errors. Fixing those errors at this stage is a whole lot easier than fixing them much later in the project.
Pictures, such as graphical analysis models, represent information at a higher level of abstraction than detailed text. It’s often valuable to step back from the trees and see the forest as a whole—the big picture. This is a valuable way to find missing and incorrect requirements. A reviewer could examine two pages of detailed functional requirements that seem to make sense, but he might never detect the one requirement that isn’t there or the one that is simply wrong.
Suppose, however, you draw a picture—a model—based on your mental image of how that part of the system ought to function. Then you compare the model to the list of requirements, and you find that a line from one object in the diagram goes to a different destination than the corresponding requirement says it should. Which is correct? The BA might not be able to determine which is right, but the difference between the two views points out a problem you need to resolve.
This high level of abstraction allows the reader to see how pieces of information fit together without getting mired in the gory details immediately. Of course, developers and testers eventually will need the details so they can do their jobs. Early in the days of structured analysis, the philosophy was that diagrams could completely replace the need for a detailed requirements specification. This simply doesn’t work. Models, prototypes, and the like are highly valuable, but they don’t contain all the information developers and testers need. Use high-abstraction models to supplement—not replace—textual specifications with an alternative communication vehicle.
Different people learn and comprehend information in different ways. Some people like to read, others prefer pictures, while still others learn best by listening or while manipulating something with their hands. To accommodate these different learning styles, try to depict information in a variety of ways. It’s not obvious how to help tactile learners examine a requirements specification, but multimedia can provide a rich communication experience. You can embed hyperlinks in a word-processing document to other types of objects:
- Sound clips that explain a particular concept.
- Video clips that illustrate how something works or how a user performs a task.
- Photographs that depict views of an object from various angles.
I see little use of hypertext in the requirements documents I review, yet hypertext is an excellent way to provide your readers with easy access to other related information. Consider incorporating links to reusable sources of common data definitions, user class and actor descriptions, glossary entries, business rules, and the like.
As with every other requirements technique, creating multiple views incurs a cost. In addition to expending effort to create the different views, the BA must keep them all current as changes are made. If the views get out of sync with each other, readers won’t know which one to believe (if any). This reduces the value of the multiple views. You might not need to update a high-level model every time you change some detailed functionality description, but you’ll probably need to revise the corresponding test cases. Don’t become a slave to the modeling, caught in the analysis paralysis trap of endlessly perfecting the pictures. In many cases, though, the cost of creating and maintaining multiple representations is more than outweighed by the insights into the requirements that different views offer and the errors they reveal early in the game.
There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant. The first man wrapped his arms around the elephant’s leg and said, “Why, an elephant is just like a big tree.” “No,” said the man who held the elephant’s tail, “an elephant is like a rope.” The third man felt the side of the elephant and reported, “This elephant is like a big wall.” The fourth man gripped the elephant’s trunk and declared, “You’re all wrong. The elephant is like a giant snake.” The fifth man rubbed the elephant’s tusk and said, “I think an elephant resembles a spear.” “No, no, no!” said the final man, who touched the elephant’s ear. “An elephant is like a big fan.”
The blind men were all correct. The elephant has all the characteristics they described, but no single feature of the elephant provides a complete description of what an elephant is all about. Each man had but a limited view of the elephant and could draw conclusions only from that view.
There’s an analogy with software requirements. I learned long ago that no single view of the requirements tells us everything we need to know about them. Often it’s desirable to represent requirements in multiple ways, thereby giving the readers a richer, more holistic understanding of the requirements elephant. Unfortunately, nearly every requirements specification I have read contains just a single view: natural language text. The clever business analyst can do better than that.
Limitations of Natural Language
Natural language is, well, natural for people to use. We employ it every day of our lives in diverse forms. But natural language has some shortcomings. One of the biggest limitations is ambiguity. I once was talking with my father about cars. I said, “For my next car, I’d like to get one of those high-mileage gas-electric hybrids.” My father replied, “I don’t know if you’re going to be able to find a used one.” Used one? I didn’t say anything about buying a used car. When I said high-mileage, I meant, “gets many miles per gallon.” When my father heard high-mileage, he thought, “big number on the odometer.” These are both perfectly sensible interpretations of the phrase high mileage. Ordinary, natural language led to a miscommunication in a casual discussion with someone I knew rather well.
In conversation, we rely on context, body language, and the chance to ask questions for clarification to ensure that we understand what we heard. We have an opportunity during discussions to detect and quickly correct ambiguity. Written communication, such as a requirements specification, doesn’t allow for this opportunity. Confusion can result from misinterpretations and ambiguity, and ambiguity is one of the big risks that natural language poses for requirements. This is one reason why you should never expect an SRS to replace conversations among BAs, developers, and customer representatives. However, when collaborating on software development over long distances, you don’t have many opportunities for conversations. High-quality written communication becomes essential for success.
Writing in natural language also leads to bulky and verbose specifications. In an attempt to clarify what he’s trying to say, the BA might duplicate a piece of information or state it in more than one way. Redundancy often is not helpful in requirements specifications. It can introduce additional ambiguities and inconsistencies. And, frankly, long documents with page after page of text are boring to read and daunting to review. There’s a good chance that reviewers will glaze over and fail to find some of the problems in the document. This is unfortunate, because well-executed reviews of requirements documents are one of the highest-leverage quality practices you can perform on a software project. Detecting and removing defects while they are just ideas is much faster and cheaper than correcting problems in the code.
Another issue is that detailed textual requirement statements represent a low level of abstraction. Each requirement describes but a small fragment of the system’s functionality or characteristics, with little context. Specification readers can have a hard time grasping the big picture and seeing how each individual requirement contributes to it. This makes it difficult for them to judge whether each requirement is correct, complete, and necessary. So the ability to depict requirements knowledge at multiple levels of abstraction and from different perspectives provides a much richer understanding than can any single view.
In this series of four articles, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I will describe why it is so valuable to create various views of your requirements. I’ll tell you about some of the analysis models and other techniques you can use to represent requirements information and give you some ideas about how to choose an appropriate model.
With the PMI’s recent release of the new Professional in Business Analysis (PBA) certification, business analysts (BAs) in the community are asking what is the difference between this new PMI-PBA and the IIBA’s existing Certified Business Analysis Professional (CBAP)? Also, if we’re looking into getting certified, which one should we go after?
In their announcement to offer the new certification, the PMI quoted a statistic by the US Bureau of Labor Statistics that “business analysis jobs are predicted to increase 19 percent by 2022.” We agree that this is a good reason for more people to get certified in the field of business analysis. We’re looking at this new certification from the PMI as great news; business analysis as a profession needs to break through the lack of recognition and demand more respect from the global community so that we can all be more successful in our jobs. This certification is definitely a step in that direction.
But before you go and sign up for the PMI-PBA pilot program, we recommend making sure it’s the right certification for you. After looking at the available literature, including the PMI-PBA Examination Content Outline (ECO), it is apparent that this particular certification is focused on a very specific area of business analysis, and is developed for a very specific subset of business analysts.
According to the PMI’s literature on the new certification, “business analysis is a critical function that helps define business requirements in order to shape the output of projects and drive successful business outcomes. In order to ensure the quality of requirements and projects, it is crucial that individuals be skilled and knowledgeable in industry standards and best practices.” While at Enfocus Solutions we agree this is true, we’re also aware that there is a broader usage of business analysis than the PMI-PBA’s project- and program-focused definition.
There’s more to business analysis than just requirements. We’ve always preached that at Enfocus Solutions. While the PMI has acknowledged there are broader applications for business analysis, they do not focus on those topics as a part of the PMI-PBA certification. Their website is very clear that the focus of the PMI-PBA is business analysis in the context of project and program management.
The scope of the PMI-PBA is much narrower when compared to the CBAP offered by IIBA. The PMI makes it clear their BA certification significantly emphasizes requirements management, especially with the recent release of the Requirements Management Knowledge Center of Excellence. On the other hand, the IIBA’s Business Analysis Body of Knowledge (BABOK), a well-established resource for BAs, incorporates enterprise and strategic business analysis, as well as requirements management. Comparing BABOK’s Knowledge Areas to the PMI-PBA ECO’s Domains, you can see the PMI-PBA is centered around requirements development and management activities, whereas BABOK has much broader applications.
This isn’t necessarily a bad thing. It’s just something to keep in mind when looking for the right certification for yourself. In what ways will you need to use business analysis? Are you performing it on an enterprise-scale, or a project-scale?
When we compare the qualification requirements for the two certifications, it becomes apparent that the PMI-PBA leans toward a certain type of audience—that of project and program management. For applicants with a relevant bachelor’s degree, the PMI-PBA requires less hours of BA experience. The PMI-PBA requires 4500 hours over 8 years, versus the CBAP’s requirement of 7500 hours over 10 years. The PMI-PBA is actually more similar to the Certification of Competency in Business Analysis (CCBA) offered by IIBA, which only requires 3750 hours of BA experience over 7 years. What does this tell us? That people going after the PMI-PBA probably don’t spend all of their time on business analysis, and most likely have other project-related responsibilities.
Also, to renew the PMI-PBA every 3 years, you must complete 60 Professional Development Units (PDUs). These courses are created by education providers registered with the PMI, meaning the content is generally focused on project and program management. This is also something to keep in mind if trying to decide between one certification or the other. Are you planning on following a project management-focused path? Or, will you need to learn broader applications of business analysis?
While both certifications have their merits, the PMI-PBA is very obviously geared toward someone with an existing project management background. The IIBA’s CBAP is geared toward a broader audience by including enterprise and strategic business analysis activities. There is an existing, well-established body of knowledge developed by the IIBA, covering all areas of business analysis. However, some people don’t need all of that information. Business analysis is often only a part of what someone does. So, depending on your goals, either certification could be the right one for you. Generally, we suggest people who work in more of a project management capacity to apply for the PMI-PBA as a natural continuation of your project management skills development.
When it comes to software development projects, agility should be focused on delivering business value in increments, and not developing software in cycles. While software development is a major aspect, it’s not the end goal of our projects.
Too often when following agile development, the team is uncertain or unclear of what to build that will actually deliver the value set out for at project inception.
Then, what happens is the team starts coding before understanding what really needs to be built, which is a very expensive way to validate that the solution meets customer and business needs. If there is no feedback until the end of a big project, it might be too late or costly to adjust. Instead, it is prudent to get as much feedback as possible, as early in the project as possible.
As Eric Ries, author of Lean Startup, puts it, don’t we all want to “avoid building products that nobody wants?” Recent Standish Group research shows that 20% of Features are used regularly and 50% of Features are hardly ever or never used. According to the study, the gray area is the 30% of Features and functions that get used sometimes or infrequently. All of these Features and functions that are never or barely used are causing higher costs, lower value, and longer cycle times, resulting in lower customer satisfaction. Focusing on the 20% of the Features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction.
To focus on the 20% of Features that give the most value, you need to validate early. So instead of coding and then getting feedback from stakeholders, validation should be upfront in the project and follow Lean best practices, meaning performed with as little waste as possible. The Lean concept of Minimum Viable Product (MVP) is perfect for cost-effective product validation. The MVP is that version of a new product or service which allows a team to collect the maximum amount of learning and feedback with the least amount of effort required. MVPs help the project team to identify and focus on the issues and features that are important to customers before developing a fully working solution.
According to Eric Ries in his presentation on the “Minimal Viable Product,” there are several useful techniques for creating a MVP so that the team can prioritize and eliminate the Features and functions that provide little or no value to customers:
Smoke Testing—Determine whether users would actually pay for a product or service before developing it by creating landing pages where users can pre-order. Then, use Adwords to attract users to your site. A smoke test is a tried and true marketing technique that measures customer interest in the product or service.
Search Engine Marketing (SEM)—SEM is a Google innovation in which the advertiser decides how much a user’s click on an advertisement is worth. After setting the amount per day you’re willing to spend, sit back and watch the search engine bring visitors to your website. SEM is a great technique for startups and small businesses who don’t have much of a budget for marketing. Over time, through website optimization (i.e., tweaking landing pages, split-testing the payment system, etc.), those visitors will convert into customers.
In-product Split-Testing—Create hypotheses about an existing product or service and test your ideas out to determine whether your hypotheses about what customers really want are correct. Split Testing can be used to test out large and small changes, and it’s a good way to get regular feedback and avoid building something nobody wants.
Paper Prototypes—Draw a basic prototype on paper of how an application interface should work, and walk customers through what it will be like and how it will solve their pain points. Paper prototypes are good for identifying usability issues in software that hasn’t been built yet, meaning the team isn’t wasting time and money developing something that doesn’t work.
Customer Discovery/Validation—First, discover what customers need and want through various stakeholder engagement methods, such as personas, scenarios, and stakeholder needs. Then, create a repeatable sales roadmap and corroborate your business model with Customer Validation. Validate that you are offering a product that customers want to buy through the process you’ve devised to sell it. When Customer Validation is successful, continue on the roadmap as planned. When it isn’t successful, return to Discovery activities to determine what customers will pay for. Customer Discovery and Validation should be a no-brainer on every product and service, but often gets left out or done poorly, resulting in unsuccessful projects.
Removing Features—Remove unnecessary Features and focus on the single value proposition that outweighs all others. This is a good technique for new product development. When early users adopt your solution because of how awesomely you executed that value proposition, you’ll have the chance to add those Features and wow them again later. Removing Features can also be a useful technique for existing products and services when certain Features do nothing for user engagement or revenue.
The benefits of using this approach are quickly evident when the organization starts to receive value early in the project cycle. Using code to validate ideas is very expensive, but there are cheap methods available. Better, more cost-effective validation practices will eliminate working on Features that provide little or no value.
There were a few great questions asked at the end of our webinar yesterday, Agile Business Transformation. While I didn’t have time to answer them in the information-packed webinar, here are your answers.
Q: Does Enfocus know of publications on Agile transformations for business with products with HW as well as SW products?
A: --Agile Development has been used for both the development of hardware and software products. One of the best-known examples is the development of Nokia phones. In Enterprises, many infrastructure groups are also starting to use agile. Many organizations are starting to adopt DevOps which is an umbrella concept that refers to anything that facilitates a smoother interaction between development and operations. The best information for large agile transformations is at www.scaledagileframework.com. There is also a major movement toward integrating Lean with agile and there are several good books on this subject. A very good book on this subject is Implementing Lean Software Development: From Concept to Cash by Tom and Mary Poppendieck.
Q: I find it challenging to differentiate a Feature from An Epic! For example, how would you determine if a BR is a feature or an Epic?
A: -- Great Question. A feature has to be small enough to fit into a Release. An epic spans multiple releases. Epics are approved by Portfolio management, whereas Features are defined by program management and are used to decompose an Epic into manageable components. View an epic as a project and a feature as a component of a project.
Q: Most of the time, we find the stories changing to be a Feature or Epic!
A: --This is very common. Teams have to groom the backlog to ensure that stories are small enough to fit into a sprint. Some Scrum trainers recommend that Teams spend 10% of their time each week grooming the backlog. It is much better to have a separate backlog for Features and another backlog for Stories. The Feature backlog is maintained by Program management. The Features are validated and prioritized and given to Teams when ready. The Team Product Owner and Team Members break the Features into stories that comply with INVEST. One backlog for both does not work well for most teams. Many people refer to this problem as “user story hell.”
Q: Question: My team consists of system integrators. Before we can engage them, we need an SOW and they need requirements. With agile, there's no sets of requirements, how do you guys address this gap?
A: Enfocus Solutions fully addresses this gap. There are two basic ways to do this. It really depends on who provides the Product Owner.
If your organization provides the Product Owner, then the Product Owner defines stories for the backlog and works with development teams to negotiate what will be done for each sprint. You are basically negotiating for a fixed number of sprints. The Product Owner’s job is to define the user stories and associated tests in enough detail to maximize the velocity of the Team. The Product Owner will also need to serve as the SME for the team.
If the Product Owner is provided by the Systems Integrator. Then you will be defining a set of Features which represents the project scope. The validated set of Features is placed in a Statement of Work and are given to a System Integrator. The SOW is done for each Release. Our software fully supports both of these methods.
Q: Could you update the presentation so that on slide 11 with all those stats, could you provide the link to the source, or at least the dates of the report?
A: A copy of the updated slide is shown below. (Also note all slides will be sent to registrants and available in the archive within a few days.)
Q: Slide 13: Any stats on how many organizations actually use paper? Versus Word or other docs that are stored electronically.
A: -- I do not have stats on this. I think the number will grow continually as organizations become more agile. There is a huge growth in collaboration and agile development tools. Producing paper documents is slow and anti-agile.
The common Program Management Office (PMO) is constantly challenged and called into question by senior management and the C-level. Without executive support, the PMO struggles to be successful in delivering program and project outcomes that effectively provide business value.
Traditional PMOs have a tendency of becoming too bureaucratic and too focused on managing tasks instead of value, increasing project complexity and causing headaches across the enterprise. But recent research proves PMOs can still be effective at delivering business value if managed the right way—at the enterprise level.
To deliver value with initiatives and reduce project complexity, the organization requires centralized coordination of processes and practices. In a traditional, departmentally-based PMO, it is very difficult to align projects with the strategic priorities of the organization. These types of PMOs may be successful on a departmental level but are often not taken seriously by the rest of the organization. When PMOs are departmentally-based, they tend to define value in different ways, skewing project results. Instead, the organization needs a PMO that provides a consistent mechanism to standardize practices and evaluate progress of initiatives across the organization, without creating unnecessary complexity.
When the PMO is operating at an executive level, there is an increased likelihood that project outcomes align with organizational strategy because the PMO has the ability to affect the entire organization. According to a recent study, strategic PMOs that implemented an enterprise-wide approach in 2013 tended to have the most mature processes and practices, and were the most likely to achieve consistently successful project outcomes. The findings indicate that the traditional approach to Program Management Offices is transforming to an approach in which there is one central Enterprise Program Management Office (EPMO) held accountable for the organization’s entire program portfolio.
The EPMO provides a way of effectively managing projects in today’s complex, global marketplace. The traditional PMO lacks direction and control on enterprise-wide initiatives. Without executive sponsorship, projects fail. Resources are reluctant to work with and report to individual PMOs within their own silos without executive support. A centralized EPMO has the respect and executive sponsorship necessary to get people involved. The EPMO creates the appropriate decision-making processes for addressing issues that arise, including how to resolve issues that cross multiple projects. The EPMO structure varies from company to company; most organizations have a single EPMO at the executive level that oversees all projects, but larger organizations have departmentally-based PMOs reporting to a central EPMO that ensures projects are aligned with the strategic plan and manage project prioritization.
The EPMO has the ability to align all projects, either at the corporate or departmental levels, with the organization’s strategic plan to better manage project prioritization and resource allocation. When organizations take on too many projects or programs at once, resources are stretched thin. There needs to be an EPMO in place that can determine whether the projects in the portfolio are carefully aligned with organizational objectives, and that can prioritize projects according to those objectives, making sure to eliminate low-value added projects or projects that don’t align with the enterprise strategy.
A major advantage of the EPMO is that its perspective spans across departments and initiatives, meaning it has insight to all projects and programs across the organization. Unlike a traditional, departmentally-based PMO, an EPMO is able to perform impact analysis on a project in the context of the entire organization—how will the project affect existing people, processes, and technology, as well as concurrent projects.
An EPMO can do a lot more for your organization than a traditional PMO. Implementing an EPMO will improve the way the program portfolio is managed, increasing the business value delivered with each initiative by...
Defining a consistent definition of value across the organization
Ensuring projects meet or exceed customer expectations
Aligning projects with organizational strategy
Ensuring projects are successfully delivered—on-time, on-budget, and aligned with customer needs
Mitigating risk early
Reducing cycle times
Reduce project costs
Identify impacts on the organization, individual departments, and customers
Resolves issues that cross multiple projects
Provide transparency to project stakeholders
Communicate project progress across silos
Ensuring project teams have appropriate skills and competencies
Standardize project processes, tools, and templates
Standardize measurements and metrics
When we attended Knowledge14 in San Francisco earlier this week, one thing we noticed is how amazingly far organizations have gotten in adopting IT Service Management (ITSM).
But while it does seem organizations have caught onto the fact that moving towards ITSM provides a lot of value, many have still not yet adopted or placed enough emphasis on the ITIL practices of Service Strategy and Service Design. This is a huge mistake, as ITIL offers valuable guidelines to service providers on the best ways to design and maintain services for the business.
Image from ITIL Service Design
One of those guidelines is to create a Service Design Package (SDP). It seems that many new service providers either neglect the SDP or create one that’s lacking in all the necessary elements. However, creating an SDP ensures your services are designed well, and according to the authors of ITIL Service Design “the better and more careful the design, the better the solution taken into live operation,” so creating a SDP is not a step you want to skip.
The Service Design Package (SDP) follows a service through its lifecycle from initial proposal to retirement. It contains all the information required to manage an IT service. The SDP specifies the requirements from the viewpoint of the client (not IT) and defines how these are actually fulfilled from a technical and organizational point of view. When created properly, SDPs bring a lot of value to the business. A SDP…
- Improves the quality of services
- Improves decision-making
- Makes implementation of new or changed services easier
- Improves alignment of services to the business
- Makes service performance more effective
- Improves IT governance
- Makes ITSM more effective
- Reduces Total Cost of Ownership (TCO)
Once a SDP is completed, it is passed from Service Design to the Service Transition phase to provide all information required to develop the service solution, including a preliminary (i.e., intended) time-schedule for the Service Transition phase. Service Transition, Operation, and Continuous Improvement provide input to the requirements in the SDP, ensuring services get better as time goes on.
According to ITIL, a Service Design Package (SDP) should consist of the following contents:
This section includes the agreed and documented business requirements, such as the problem statement, vision, and business objectives. The requirements also include service contacts, such as the business stakeholders and customer representatives. These are the high-level details with which the rest of the SDP must align; you want to make sure to deliver the right service to the right group of people.
Service Design refers to the functional requirements describing the new or changed service and the Service Level Requirements (SLRs), including service and quality targets. Also, this section includes the operational management requirements for the new or changed service (e.g., supporting services and agreements, control, measuring and reporting). Lastly, this section should document the plan for the service’s transition, implementation, and operation. The Service Design section is very heavy in detail. In addition to the requirements for all service components and infrastructure, don’t forget supporting processes and procedures, as well as measurements, metrics, and reports.
Organizational Readiness Assessment
The information in this section will make up the plan to assess benefit, financial, technical, and resource aspects, and needs to include a description of the new skills, competencies, and capabilities required to transition and implement the new or changed service.
Service Lifecycle Plan
The last section includes the plan for each subsequent phase in the ITIL service lifecycle. This should include the required business processes, as well as a plan for communication and reporting. The Service Lifecycle Plan documents to manage related people, processes, and technology. It should also include timescales and quality targets for each phase. The Service Lifecycle Plan must include all details about service transition and operations focusing on the following:
- Service Transition Plan—document transition strategy, objectives, policies, risk assessment, and plans
- Service Operational Acceptance Plan—document interface and dependency management, as well as planning, events, reports, and service issues regarding the new service and final service acceptance
- Service Acceptance Criteria—document the acceptance criteria progression through each stage of the lifecycle
There are not many tools on the market that enable ITIL’s Service Strategy and Service Design. Enfocus Solutions provides software and services to IT service providers and managers looking to adopt ITIL best practices. Our software and services are designed to ensure services deliver value to the business by providing the capabilities to create a complete Service Design Package.
In today’s world business leaders are demanding IT organizations deliver high value mobile applications at little cost and lightning speed. And if you’ve worked on any mobile application project, then you know that mobile application development projects can be a challenge.
Mobile apps and websites used to simply be a replica of the desktop version of a website, but today they are much more. They are productivity tools, information lifelines and are central to how successful companies are conducting business. For example, in the past marketers used to have to wait and gather campaign statistics – in this day and age, marketing and sales use mobile apps to track campaigns, manage promotions, track inventory – in real-time!
By now we’ve all heard of Pinterest and have seen how much growth they have experienced since they first popped up on our social media radar a couple years ago. From inception, Pinterest has seen visits skyrocket by 5,124 percent to more than 28 million visits per week in their second year of business. The result? As an organization, they had to move quickly to successfully support their growth spurts, or risk the trap of ‘growing too fast’ and not being able to keep up with the market demands. They did this through automation, agile tools and strong collaboration between developers and all other operations.
In other words, Pinterest was successful because they were able to move quickly and had established an agile development environment early on.
One of the key principles of Agile Development is the ability to handle changing requirements even late in the project, and minimize the risk usually involved in doing so. In fact, in agile projects, it’s vital that the stakeholders can make changes easily at any point in the development lifecycle – from beginning to the end. Tracking and managing these constant changes is vital in order to stay on top of any project and still come in on time and on budget – and with happy stakeholders.
But for any project, it’s important to remember that before agile development comes effective discovery.
Discovery starts with the team—it can include business analysts, designers, developers, business stakeholders and the list can go on. Establishing what stakeholders want can be tricky but a must in the discovery phase—in fact it’s what successful discovery is all about. The team needs to look at: what are the current best practices? What are the current experiences? How can your future app improve these current practices and experiences? Is this feasible? Can it be built? What should be built first? What will be the most valuable functionality?
But discovery goes beyond just asking the questions, it’s important that the time is taken to understand who the people are that you are asking these questions to.
By doing user research, a clearer picture can be painted and an understanding of who your users are is established. User personas can show who the user is, how they currently perform their work and what they would find valuable to have in the future. Create a story map and include what makes your project fun, painful, or confusing for the stakeholder. Do we need to change behavior for the stakeholder? What should the outcomes be? Capture and analyze the problem statement or opportunity so that you are addressing in enough detail to get everyone on the same page.
And don’t forget about your business overall. What will YOUR company gain from building this app? Develop the app in the context of your business objectives to make sure you’re meeting the needs of the company and helping them achieve their overall goals.
Establishing and meeting key performance indicators are vital in figuring out what the right mobile application should look and act like for your organization and your market. Establish a common vision among all team members and stakeholders so everyone is motivated toward the same clearly defined goal. Also make sure everyone is aware of vital constraints – understand and communicate the budget, deadlines, and other limitations to your whole team.
Organizations that implement and utilize agile discovery are more successful at understanding what needs to be built—resulting in more successful projects that deliver higher value features and products at lower costs and higher rates of user satisfaction.
Learn more about Enfocus Solutions and how we can ease your Agile Discovery process.