Author: Tony Higgins

As if Re-work Wasn’t Enough …

Written by Tony Higgins on April 26, 2011. Posted in Articles.

Studies show that somewhere between 25-50% of software project budgets are consumed by re-work. That means work that needs to be done again because, for some reason, the results were not correct. Significantly, 70-85% of this rework is directly related to poor requirements. Of course, we all know that there are many reasons requirements fall short and that there are many things that can be done to remedy this. But if the wasted budget wasn’t enough to think about, there’s more!

After the average project spins its wheels burning through scarce resources and eventually reaches the ‘goal-line’ with a finished product, we run head-first into another sobering industry statistic: for every software product delivered, 45% of the features, on average, are never used! [1] That’s right. NEVER used.

There could be many reasons why we spend lots of time and money building features that aren’t needed by the user community, but my money would be, once again, on poor requirements. Some probable sources:

Requirements elicitation and analysis wasn’t thorough enough to truly understand the needs of the business and/or the user community
Requirements validation with stakeholders was inadequate allowing unneeded features to remain undetected
Requirements ambiguities that allow developers to “fill-in the blanks” with unnecessary functionality
Insufficient user and other stakeholder involvement at key points during the development lifecycle prevented these issues from being detected
Inadequate scope management allowed additional and unsanctioned features to be introduced at various points throughout the development cycle

It’s difficult to estimate how much of a project budget could be saved by not building those 45% unused features. It depends on how significant and ‘deep-rooted’ the features are. At one end of the scale, they could simply be superficial features and options whose exclusion would have little or no impact on the underlying layers of the application. At the other end, like an ice-berg, they could represent just the exposed parts of much larger underlying capability. I suspect most are of the former kind, but 45% is a big number. It’s likely that some unneeded features involve significant capabilities of the application.

Adding to the additional development costs for these unused features, there are also the testing costs. Tests have to be written and test data created; the tests have to be run and the results reported; and bugs have to be fixed and then retested with regression-all for a feature set that will never be used. Then, the support group needs to learn more than they’ll ever get support calls for. And add to that, the costs to create training materials, guides, tutorials, online help and other resources for unused features.

The maintenance cost of the application will also be larger than it needs to be. Not necessarily because bugs will be reported on these unused features, but because as long as they exist and are in service, any fixes and enhancements will need to be regression tested to ensure that they remain unaffected.

Those are the hard costs that are incurred when you create an application with 45% unused features. But the soft costs are also significant. New users are forced to learn much more than they will ever use in practice. Plus, the usability of any application with so many unused features has to be negatively impacted. At a minimum those who designed the user interface would have had to make compromises in terms of menu and ribbon designs, wizards, dialog boxes, and preference-option screens to accommodate these additional features. It’s likely that any designer would be able to create a better and more efficient user-experience by focusing on the exact 55% of features that were actually needed.

When looking to improve the economics of application development for business, efforts should be focused on those areas with the largest potential for gain. I would suggest that reducing the 25-50% of your budget wasted on rework, and preventing the creation of 45% unused features are good places to start. And that means improving your requirements.

Don’t forget to leave your comments below.

[1] Jim Johnson. The Standish Group International Inc. 2002.

Tony Higgins is Vice-President of Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst. Tony can be reached at [email protected].

How Much Rework Do You Have?

Written by Tony Higgins on March 29, 2011. Posted in Articles. 1 Comment on How Much Rework Do You Have?

As a requirements solution vendor we talk with people every day about their requirements issues, assist them to understand the root causes, and help them articulate a business case for investing in a solution. For most companies, the biggest single inefficiency in their software development efforts is the amount of rework that’s done due to inadequate requirements. (The reasons as to why the requirements are inadequate are many and beyond this post but stay tuned for a new paper on the topic that goes into more depth).

When we ask people how much rework they have done on their software projects, the answer varies consistently between 5% and 25%. I find this fascinating since industry statistics show the average rework rate to be considerably higher (Forrester: 30%; voke: 40%). Why do people regularly report lower rework rates? Here are some reasons based on these conversations:

Vocabulary

On many projects, rework is simply known by a different name. In many cases it appears as contingency or padding in other line items within the budgeting process. In others a large amount of rework is pushed in to maintenance, and in extreme cases a new project may even be positioned.

Awareness

We have had countless conversations where people were simply unaware that rework happened. One reason is related to the vocabulary mentioned above where the rework may be disguised and dispersed under different budget items hiding the true nature of this expenditure as rework.

Scope

It seems that most people only consider the rework that takes place in the development aspect of a project. The total cost of rework depends on many factors including your development process and where you may be in the development cycle, but should include all impacted areas as well, such as: planning & estimating; all forms of testing (unit test, integration testing, regression testing, etc.); product documentation; user support; services and training; etc. When all these are factored in, the true magnitude of rework becomes much clearer.

Denial

Rework implies that something was done wrong, requiring work to be repeated. Nobody likes to be associated with this and for many it is difficult to come to terms with the amount of rework that actually takes place on the average software project. While initial discussion may start with the claim of minimal rework, after a little inquiry the rate tends to creep up. I recall one time in particular where the initial rate of 7% rework ended up being 35% after our conversation.

Combinations of the above

Various combinations of the above may be at work, each contributing to the low rework numbers that people report, and may actually believe, on a regular basis.

I wouldn’t be surprised if there are more reasons and would love to hear any you’re aware of. As people realize the true magnitude of rework on software projects, it quickly becomes a prime target for improvement initiatives.

Don’t forget to leave your comments below.

Tony Higgins is Vice-Presidentof Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst.

Be Expressive – Improve the Clarity of Your Requirements

Written by Tony Higgins on October 6, 2009. Posted in Articles.

Click on all images to enlarge

Make Sure Everyone’s on the Same Page

If you were somehow able to hold a requirement in your hand and ask, “Why do I need this? What is its purpose?” I would offer that you’re holding an agreement. A requirement is how two (or more) people have chosen to express their agreement regarding what is needed from a software application. The assumption is that all parties have the same understanding or interpretation of these written words. Quite often this assumption proves to be false – different stakeholders in fact have different ideas in their minds regarding these same words, and confidently think that others share their vision as they warmly smile and shake hands over the agreement. If only we could have a “Vulcan mind-meld” ala Star Trek, a lot of our requirements issues would be gone.

These issues are possible with each and every written requirement. When you multiply this by hundreds, or sometimes thousands, of requirements and then consider how the requirements must combine to paint a picture of the whole solution, it’s quite understandable why there can be so many surprises in the latter parts of a software project.

The fundamental problem is that traditional legal-type textual requirements are simply not very expressive, which tends to leave a lot open to interpretation. Very often, requirements authors attempt to compensate for this lack of clarity by adding even more legal-style text to elaborate and constrain what they’re trying to communicate. Sometimes this can lessen the range of interpretation as desired; but just as often, it can actually do the opposite, as these new words themselves may contain ambiguities, inconsistencies, or redundancies. These additional words are added to areas where misinterpretation has been detected. But what about all the hidden areas of misinterpretation that have yet to be detected? They simply remain hidden, lying in wait to rear their heads later on in the development cycle.

Stakeholders directly involved in defining the requirements through elicitation, authoring, or review, have the benefit of sometimes hours of discussion and debate that go into formulating the requirements. This rudimentary form of Vulcan Mind-Meld is really quite valuable in avoiding misinterpretation of the written requirement. But what of the requirements consumers who did not have a seat at the definition table, and didn’t have the benefit of all this undocumented communication? It is crucial that developers, testers, outsourcers, sub-contractors, and others who consume requirements understand what they are being asked to build, test and manage. The risk of requirements miscommunication among these key individuals is magnified, since they’re even more likely to misinterpret the original intent.

So in addition to serving as an agreement between parties, the requirements have another key purpose: to communicate what is needed completely, precisely, and unambiguously to others who may not have been intimately involved in their definition.

Have you ever noticed what someone does when they’re having difficulty communicating a thought or concept? They become animated. They start using their hands. They make sketches on the whiteboard. They start pointing at the computer screen and say things like “so imagine this”. In short, they reach out for other, more expressive forms of communication. As they do this, they often expose other areas of misconception or misunderstanding. One by one they tackle these new areas, again with various forms of expression. The same is true with requirements. Increasing the expressiveness of your requirements actually exposes additional areas of miscommunication you never knew were there – in other words, areas where you need to be even more expressive. This effect can be very powerful, and can help to raise the quality of requirements dramatically.

Some go so far as to replace textual statements altogether in favor of other more expressive forms of specification. Personally, I’ve found a combination of the two offers the best solution, and this is the approach I’ll describe.

Setting Context

Software requirements express what is required of the application in order to fulfill some higher-level business need. Requirements could describe how to provide customers with an online flight booking capability to fulfill the business need of increased sales for the airline, or how to withdraw cash to fulfill my business need of going to a movie. Regardless, this business need must be expressed along with the associated business process so that this world in which the software application will function is:

Understood by all team members, and
Used as a reference for the project to ensure it stays focused on addressing the business need.

This business context can be expressed as a combination of textual statements with a set of business process diagrams. The textual statements can be categorized according to an appropriate taxonomy (e.g. business need, business goal, business objective, business rule, business requirement, etc). There are various taxonomies in use, and I won’t use this forum to debate their merits. Business processes are best expressed using business process diagrams. There are numerous notations in use for this, from fill-blown Business Process Modeling Notation (BPMN), with its plethora of symbols, to very light-weight notations suitable for sketching processes. Since the purpose of the diagrams is to simply provide context for the software requirements – we’re not trying to re-engineer the business – I generally opt for the simpler notations. All I look for is ability to support:

Roles. In other words, who is performing the activity? This is commonly represented using swimlanes.
Activities. The tasks performed by the role.
Decisions. The ability to identify the decisions made by the roles and to specify associated conditions.
Start & End. Clear notation of where the process begins and ends, with ability to specify any pre or post conditions.
Nesting. The ability to abstract or “nest” portions of a process and denote it with a special symbol.
Free Form Notes. The ability to add unrestricted notes (i.e. text of any size and position).

I’ve found with these essentials, I’m able to illustrate most processes, and in the odd case where I can’t, I simply augment with notes.

The business need and the process, as you can imagine, are related. In areas where the relationship between the two is noteworthy or illustrative, it makes sense to somehow maintain this relationship via a traceability relationship using whatever requirements tool/platform you have. Conceptually, the context may therefore appear as in Figure 1.

Figure 1 Business Context

Generally, I ensure the business needs are exhaustive in terms of breadth – meaning if there’s a need, I want it to be specified. On the other hand, I selectively apply business process diagrams in areas where the process is business-critical, high-risk, or complex. This is admittedly a fairly simple approach, but I find it adequate in a surprisingly large number of situations. Of course, it can be extended where necessary.

Defining Expressive Requirements

As with the business context, I typically begin with textual statements describing application requirements. I mostly use a categorization scheme and traceability espoused by Rational Unified Process (RUP), which originated at HP, grouping requirements into five main categories: Functional, Usability, Reliability, Performance, and Supportability. Each of these has numerous sub-categories which some people use and others don’t. Another popular approach is that promoted by Karl Weigers in his book Software Requirements. This approach arranges User Requirements, Business Rules, Quality Attributes, System Requirements, Functional Requirements, External Interfaces, and Constraints into a hierarchical traceability strategy. As with categorization of business needs, there are numerous taxonomies for categorizing software requirements, along with many strategies for tracing the relationships among them. You need to decide on one that’s appropriate for you. Regardless, this is simply a way to organize your textual statements, and does little to improve their expressiveness.

Example legal-style text requirements list:

The system shall allow the user to book a flight
The system shall allow the user to choose the departure and destination airport
The system shall allow the user to specify multiple passengers
The system shall allow the user to specify for each passenger whether they are an adult, senior, or child.
The system shall allow the user to select either a one-way flight or a round-trip.

One of the most popular ways to improve expressiveness is to think like a user and imagine how they’d use an application. User stories are one way to do this. Another is use cases, which I’ll discuss briefly here.

Instead of a list of capabilities or features to be provided by the application, use cases describe the various scenarios of how the application will be used to accomplish some goal. As an example, imagine an online airline application for booking flights and other common traveler functions. Consider a couple of scenarios:

Book a round-trip from Dallas to Chicago for two adults
Book a one-way flight from Toronto to Atlanta for one adult, and one senior

These are different scenarios and will likely entail some different requirements. For example, in the first scenario, we actually have to handle two flights instead of one, because it’s a round-trip. In the second, there may be special requirements for seniors and perhaps senior discounts involved. Furthermore, the second example is an international flight, so there are likely some special requirements around that as well. However, you can look at these two scenarios, and probably think up several more, which are all variants of Booking a Flight, the goal of the user. To describe these various scenarios, we would create a use case called Book a Flight, and within it stipulate in detail how flights get booked. We do this in a dialog style such as …

Step 1. User chooses to book a flight

Step 2. System allows user to choose one-way or round-trip

Step 3. User chooses round-trip

Step 4. System allows user to specify departure location and destination

Step 5. User chooses departure location and destination

Step 6. System allows user to specify number and type of travelers as adult, child, or senior

Step 7. Etc.

Figure 2 Sample Use Case Steps

This is a quite different style than the legal-style text list shown earlier. This dialog describes the same functionality, but from an alternative perspective and style. Just having this alternative vantage point can itself shed new light on the requirements, help communicate what is truly needed, and help expose hidden issues. I would further argue that this form is more expressive than the legal-style text list. First, it is from the perspective of the user, which will allow existing and future end-users to consume it more readily. Further, notice that each statement makes sense only in context of those around it. If you move Step 4 to the end of the list, it will make no sense. In this style, it is quite easy to spot when things are missing or out of place, thereby ensuring completeness and integrity of the requirements.

Take a look at the requirements for an application screen below:

The screen must allow users to select meals for optional purchase
The screen must allow the user to purchase up to three extra luggage pieces
The screen must allow for the display of six different meals
The screen must display the totals of any and all optional purchases
The user must be able to select and re-select any options on the screen as many times as desired before submitting
The screen must prominently display the standard luggage allowance
The screen will inform the user at all times that their credit card used for ticket purchase will be billed for optional meal purchases
The screen must prominently display the price for meals

These are just a few of the requirements that could be specified for a particular screen. These requirements don’t even get into the various constraints on layouts and appearance that are commonplace when specifying screens.

Also notice the use case steps shown earlier in figure 2. The system steps describe many things that the screen will need to support.

Instead of relying exclusively on interpretation of this written text, what tends to be far more effective is to provide a screen mockup as shown below.

Figure 3 GUI Mockup

While some requirements authors dispense with the written requirement entirely, most generally favor maintaining some combination of textual statements and screen mockups.

A picture definitely is worth a thousand words, and this approach to visualizing what’s needed is indeed quite powerful. Supported by various visual requirements tools available today, there are some very effective approaches in practice. Just a sampling:

Wireframes: Simple wireframe mockups of user interfaces, like the one above, are fast and easy to create. Their simplicity means that they often can be updated in real-time during a review session. Another good thing about them is that they don’t look like real screens, so people don’t get confused and think that the wireframes represent a finished product. Keeping the fidelity low, at the level of wireframe, also provides silent guidance to the requirements author to stay at the level of screen concept, and not stray into designing the actual screen.
High Fidelity Screens: More richly defined screens that actually resemble the end product are at times warranted. Sometimes this happens in high-risk or complex areas of the application and often in collaboration with a user interface designer.
Screen Markups: Very common in situations where you’re enhancing an existing application, taking a screen-shot and applying markups and annotations is an effective way to quickly communicate what’s needed, and to highlight subtle points.
Screen Overlays: Similarly powerful in situations where you’re enhancing an existing application, Screen Overlays take a screen shot of the current application, and add screen controls that represent the enhancement. Modern requirements tools will provide an editor allowing you to do this, and a simulation engine allowing those overlays to become live during a requirements simulation.
System Interfaces: In areas where there’s no user interface, there’s still room for visualizations. Event or sequence diagrams are excellent visuals for illustrating behavior of a system interface.

Integrate different forms of expression

The use cases discussed earlier provide a narrative description of how the user interacts with the system each step of the way. In addition, the visualizations mentioned above illustrate what the user will actually see along the way. It only makes sense that these be integrated. While this could be accomplished manually by perhaps creating links between your use case steps and the visuals with office-automation applications, a far more effective solution is to use a modern requirements definition tool that supports this linkage, and provides other associated benefits. The most powerful of these tools allows you to have a mixture of visualization approaches associated with the use cases, as illustrated in the picture below:

Bring Data into the Picture

Data is an inherent part of any application. In some systems, it’s not very dominant; in other data-intensive applications, data occupies most of the mind-share. By adding visuals (GUI mockups) to the steps in a use case, we were effectively illustrating how the user interface is affected by actions of the user (use case steps). Data is similarly influenced by actions of the user, and this behavior should be specified as well as part of the requirements.

With things like user screens, you can specify them entirely using text or use visualizations, as discussed earlier. This of course isn’t new since many make sketches or mockups outside of the requirements definition process today, using a variety of graphics programs. One of the key values in what was discussed is making these visualizations an inherent part of the requirements, and associating them with the discrete steps of the use cases at points where they’d appear to the user.

Something very similar is possible with data. You could choose to express data elements only using textual statements or tables. Today, outside of the requirements, many create prototypes with various tools like Microsoft Excel to actually perform data operations and evaluate results. This allows requirements authors not only to validate their data requirements, but also to communicate them more effectively. As with visualizations, modern requirements toolsets allow you to bring data operations within the realm of the requirements and, like the visualizations, associate them with specific steps of the use cases where they will be performed. Below shows conceptually where data operations are being associated with use case steps, similar to how the visualizations were earlier.

Figure 4 Data Incorporated in a Use Case

By adding visuals to the steps, we’re able to illustrate how user interfaces presented by the system are influenced by user actions. Similarly, by adding data operations to steps, we’re able to show not only how data is influenced by user actions, but also how data can influence system behavior.

Pull it Together

So there are multiple ways you can express requirements. Of these, textual lists are typically the least expressive. As discussed earlier, I tend to use these alternate forms to augment rather than replace text lists. However, I typically don’t use them on all parts of the application. One criterion that tends to guide how I express requirements is requirements complexity; successfully communicating highly complex requirements demands these more expressive forms. Another criterion is risk. If the risk associated with getting the requirements wrong in a certain area of the application is particularly severe, I want to be as expressive as possible with the requirements, thereby reducing the possibility of miscommunication. The graph below provides an example of this:

While all areas of the application are covered by textual requirements at a high-level, I go to the greatest level of detail in those areas that are complex and risky. The functionality of virtually all areas would be illustrated with use cases. Most of those would have wireframe mockups, with a very few, the highest risk and most complex areas, having higher-fidelity renderings. Also in these important areas, I would leverage data operations on the use case steps. In summary, the highest risk/complex areas are specified to the greatest level of detail and in the most expressive manner, while the lowest risk/simple areas are specified much more simply.

Even though it is possible to do this manually with spreadsheets, drawing tools, and other point-solutions, this is where an integrated requirements workbench really shines in its ability to not only support all these forms of expression, but also to maintain requirements integrity, ensure consistency across them, and manage traceability. The diagram below gives a high-level overview of a traceability strategy for this information, including traceability back to the business context. Tracing back to business reference is vital to ensure that all business needs are being addressed. Conversely, a complete traceability strategy ensures that every application functionality that is being specified has an explicit business need.

Using Expressive Requirements

Defining expressive requirements can dramatically improve the outcome of software projects if only in the uncovering of latent errors early and a reduction in miscommunication. Expressive requirements can release even more value if modern requirements toolsets are leveraged. The following are just a few examples of the benefits you can derive by using a modern requirements toolset.

Generate Documents. A requirements workbench will allow you to generate requirements documents automatically from the information in the requirements model. This can be a significant shift for a more traditional requirements organization in that time is spent focused on the requirements themselves, making them more expressive, analyzing them and improving their quality as opposed to being focused on the mechanical tasks of producing and maintaining a document. You still get the document, just without the effort.

Generate Simulations. A requirements workbench will allow you to transform a requirements model into an animated, live simulation. Simulations with expressive requirements make reviews far more effective, quite frankly, enjoyable. The simulations will leverage all the content in the model including the textual requirements, the use cases, the visualizations, and the data, integrating them into a single “vision” of the future application. Traceability is a vital part of the review process. When reviewing requirements, you must be able to relate them back to the original business need on-demand. Comprehensive requirements workbenches available today expose this traceability not only during requirements authoring tasks, but also during the simulations used for analysis and review.

Comments, feedback, discussions often result from simulation sessions. These are useful exchanges of ideas that also need to be recorded and managed such that they’re not missed, that they’re accessible, and that you can always refer back to them. A modern requirements workbench will record this informal input alongside the comments during simulation and make it accessible throughout the workbench so people are aware of these discussions and so authors can effect change based on them.

Generate Tests. A requirements workbench will allow you to automatically generate tests from the requirements defined in the model. These tests will cover all possible usage scenarios throughout the model and express for each step in the test any relevant screens, data, or externally referenced materials.

The importance of traceability continues through to the tests as well. Each test generated has complete traceability information in its header that identifies which requirements it helps to prove. As I’m sure you can imagine, this ability to generate tests is hugely valuable to the QA professionals on a software project.

Integration with Development and Test Tools. Practitioners, such as developers and testers who consume the requirements, base their work products ultimately on the requirements. It’s therefore very important that the requirements information be available to their toolsets as well. Today’s requirements workbench will integrate with popular UML design toolsets as well as QA testing toolsets to provide them with high-quality, expressive requirements content.

Managing Requirements Change

With more expressive requirements, most change will occur at the beginning of the project when alterations are inexpensive. The modern requirements workbench provides several capabilities to help manage change. Some of these include:

Traceability: As discussed at several points earlier, the modern requirements workbench supports traceability among all requirements artifacts, provides mechanisms to create relationships that are fast and easy, makes traceability information available as you work, and provides sophisticated and filterable views into traceability for deeper analysis. Traceability is very important for analyzing impact as part of requirements change.
Versioning: The modern requirements workbench will version all requirements elements such that you can always go back in time to see them as they existed at points in the past.
History: The modern requirements workbench will provide a comprehensive historical record detailing who changed what, and when they did it.
Difference: The modern requirements workbench will allow you to select any two versions and instantly see the precise differences between them, for all requirements elements regardless of the form of expression.

Summary

The key problem for software requirements historically has been less-than-perfect requirements. One of the main reasons for poor quality requirements is miscommunication of requirements, owing to a lack of requirements expressiveness. Multiple forms of expression for requirements can remove this miscommunication. At the same times, integrating these multiple forms in a single unified model allows them to be manageable and scalable. The modern requirements workbench makes this approach for practical, expressive requirements possible.

Don’t forget to leave your comments below

Building and Managing a Requirements Center of Excellence. Part 2.

Written by Tony Higgins on September 29, 2009. Posted in Articles.

Why Adopt the Requirements Center of Excellence Model?

The Centers of Excellence (CoE) trend has gained traction recently within the IT departments of large organizations. In fact, the META Group refers to the model as “the next step in IT’s evolution” (Source: The Application Center of Excellence, META Group). This section summarizes costs, risks, and various limitations of traditional quality management practices and contrasts them with the Requirements CoE model.

Problems with Traditional Requirements Practices

Requirements Development not Rigorously or Formally Applied. Most organizations today will author requirements and then attempt to raise the quality of these requirements through manual document walkthroughs and reviews, which has proven to be an onerous, expensive and, to a large degree, ineffective approach. Any errors in the requirements will be detected at some point and have to be remedied, if not during development or testing then during operation by the user. With more rigorous application of requirements best practices and automation, the majority of these expensive errors can be detected early when they are easy and far less expensive to fix.

Traditional Methods and Tools Fail to Close the Gap between Business and IT. The traditional requirements approaches and toolsets continue to focus on managing requirements through a lifecycle with little regard to their quality or if these requirements truly address the business needs. The result is a continual procession of “Death March” projects [Yourdon].

Piecemeal requirements practices and toolsets. In many, if not most cases today, software development is distributed to some degree within an organization (across divisions, departments, or at least projects) and each area tends to be a “microcosm” of disparate tools, approaches and practices, workflows, and artefacts. There is typically little systematic learning and improvement in such an environment. The business incurs not only the obvious direct costs of this but also indirect costs associated with staff turnover due to frustration and dissatisfaction of working in such an environment

Disconnected Processes The different disciplines on the project that utilize the outputs of requirements definition often have processes that are not integrated with those of the requirements discipline. This discontinuity is especially pronounced if the projects and departments have no consistency of tools and/or process across them. Any and all attempts to leverage common services such as technical documentation, customer support and training development, not to mention consistent management reporting and oversight, result in huge inefficiencies in such an environment.

The Business Value of the Requirements CoE Model

Drive Errors out Early in the Life Cycle. A key focus of the Requirements CoE is to promote the definition of requirements whereby they evolve through successive iterations to a high level of quality. The direct result is that less rework is required during later phases of the lifecycle resulting in a higher-quality product, faster, and at lower cost.

Communicate Unambiguously with IT so they Build what Business Needs. The Requirements CoE fosters enhanced communication between Business and IT. Consistency of notation and process is a large part of it, but modern Requirements Definition practices and toolsets make this a reality.

Give the Business the Necessary Control of the Process. Historically the business attempted to express the need, this was interpreted and documented as well as possible, and then IT would proceed largely unchecked until some version of the developed product was made available. It was then that any misinterpretations and miscommunications became obvious. Unfortunately by this time most of the budget and schedule was spent, so changes translated into project over-runs or, where this wasn’t an option, the business would simply accept the inadequate product. The Requirements CoE endeavors, through process and automation, to provide business with meaningful points of control during development to prevent and detect misinterpretations and miscommunications early.

Integrated with Other Disciplines. One of the largest gaps in software development solutions today is the lack of end-to-end integration throughout the software lifecycle. This is true of both processes and automation. While it may be possible to greatly enhance the performance of an individual discipline, one then runs into a brick wall when the results of that work cannot be passed or integrated into another discipline that needs it. The Requirements CoE not only focuses on ensuring the definition of high quality requirements, but also the seamless communication of information with other software development disciplines (testing, development, etc.).

How to Build a Requirements CoE

The flexibility of the CoE model enables companies to start small, use existing resources, and achieve tangible benefits almost immediately. This section outlines a typical process for building a Performance CoE step by step.

Assess

The Assessment activity begins with clearly identifying and articulating the business goals that the CoE is fulfilling, or helping to fulfill. This step is critical to maintain the focus of the CoE on addressing business needs.

As an outcome of this activity objective success criteria (KPIs) for the CoE will be established, consistent with business goals. This will allow for clear assessment of progress as the CoE is implemented and set the targets that staff needs to meet. The criteria will be prioritized – often based on short, medium, and long term need, and used to drive implementation planning. This is often based on the most prominent issues that need to be resolved (i.e. “pain points”) but can also be based on risk, criticality, or other drivers. Also, an agreement on how to calculate Return on Investment (ROI) is typically done at this point, since such information is usually required following implementation to justify existence of the CoE. The specific measures required as inputs to the ROI are determined so that their collection can be planned for.

In addition to the above, the organization’s “environment” in which the CoE will play a pivotal role needs to be documented to serve as input to subsequent scoping and design activities. This environment considers the three perspectives:

People. The skill levels and proficiency of staff in the Requirements discipline, and of those who work from the requirements in adjacent disciplines (e.g. design, test, etc.). It takes into account the diversity or consistency of this across the organization.

Process. The existing process, specifically in the area of Requirements, is examined. The activities performed and the artefacts produced as a result are recorded, in addition to how these artefacts are used by adjacent disciplines. The interface points of the discipline with management processes in terms of review, tracking and reporting are also recorded. Once again the consistency of application across the organization is taken into account.

Automation. The tools currently used and planned for use in Requirements and adjacent disciplines are recorded, as well as the manner in which they are used. Any prominent issues with current usage in the context of the existing process are documented.

Finally, the set of current projects along with their status, priority, impending milestones and commitments are itemized.

This accounting of the business goals the CoE is to fulfill and how to measure them, the environment in which the CoE will play a role and the current state of projects and initiatives, along with the constraints of impending commitments provides a basis on which to plan an optimum implementation approach for the organization.

Scope

Based on the information gathered during the assessment, prudent decisions can now be made on how best to implement the CoE in an incremental fashion to ensure business objectives are met at minimal risk to existing operations and commitments. The result of the scoping activity will be the high-level approach for incremental implementation identifying:

Which CoE capabilities will be implemented, in what order
Across what part(s) of the organization and projects,
What business objectives will be met, and how this will be measured
justification for the approach based on risk, opportunity, and other criteria

This results in a high-level Implementation Plan for the CoE.

Design

This activity will evolve the high-level Implementation Plan developed in the previous activity to the point where it can be enacted. These plans are most often based on a phased approach with the immediate phases being expressed in detail, and subsequent phases expressed in less detail as they will be updated based on lessons learned from the initial phases. The Implementation Plan will identify the activities that need to be performed, schedules, milestones, resources required, responsibilities, risks and mitigation strategies to successfully implement the CoE in an iterative fashion. Associated costs and budgets will also be determined.

It is important to note that the nature of the CoE is to consolidate and advance the level of corporate expertise in the area of Requirements. The very nature of this group is one of communication with other groups in the organization, and so the implementation of the CoE will require significant involvement of other groups and projects.

Implement

This activity results in the implementation of the CoE over time, by enacting the plan outlined during design activities above.

Continual monitoring of progress and measuring convergence on KPIs is performed throughout the implementation, along with risk monitoring to ensure objectives are attained without compromising existing projects and their goals.

A significant part of the initial implementation is education and awareness for everyone in the organization, and certainly those affected directly or peripherally so that expectations are effectively managed.

Validate

Once operational, the initial capabilities of the CoE are quickly assessed as to their effectiveness and their meeting of the objectives set, and adjustments made accordingly. Learnings from the implementations are used to influence detailed planning for subsequent implementation of additional CoE capability.

Validation is an essential step in managing the Requirements CoE implementation and growth based on the value-driven goals. In the validation activity, actual measures of KPIs are compared to targets set forth during Assessment.

Iterate

Following deployment of the initial Requirements CoE capabilities, high-level plans for additional iterations can be reviewed, modified, and detailed based on the additional knowledge gained and any other changes (e.g. business environment changes, project actuals, changes in risk, etc.). Subsequent iterations will either expand capabilities of the Requirements CoE, or its breadth in the organization, or both.

In many cases there are some centralization activities in various areas of the company already – for example, a CoE focussed on performance validation or defect management. If this is the case, it may make sense to formalize the activities and processes between the individual centers as their individual capabilities grow.

Another approach is to start by using the Requirements CoE model to resolve one specific critical issue (e.g. excessive requirements “churn” in critical project), then:

Gradually build up the resources and capabilities of the CoE to optimize Requirements processes and techniques on a project basis (pre-empt requirements issues through process consistency)
Extend the CoE model to other areas such as capacity planning, code optimization, etc.
Ramp up to standardized processes and solutions throughout the enterprise.

Answers to CIO Questions about a Requirements Center of Excellence

Q: How do I ensure quick results?
A: Use the iterative approach (approx. 2-3 months per iteration). Focus on the services that will generate immediate results, such as verification and validation of requirements

Q: What level of investment will be required?
A: An initial investment of even one FTE can be enough to deliver value by establishing an inventory of current practices and consolidating requirements toolsets. The iterative approach is a way to offset subsequent investments with returns from previous iterations.

Q: How do I ensure adoption of the CoE concept?
A: Executive commitment and support is considered essential. Find one or more project teams who are receptive to the establishment of a CoE. Leverage this collaboration to produce even a single success story that can be marketed to the next projects

Q: How do I prevent disruptions to the organization’s daily operation?
A: The initial focus on critical business issues will align CoE services with daily operations. At the same time, the CoE should be flexible enough to support specific project requirements and culture before it is used as the foundation for standardizing enterprise processes.

Q: How do I use the CoE model to compete with the alternative service providers?
A: Focus energies to ensure that you are faster and cheaper. This will overcome what are typically the biggest objections.

Q: How do I demonstrate value of the CoE ?
A: It is essential to measure CoE impact on the projects and CoE effectiveness. Some KPIs can include product improvement – lower defect rate, fewer change requests – as well as CoE efficiency – projects per person, project time, cost of project, etc.

Summary: 10 Tips for Building and Managing a Requirements CoE

The earlier you plug into development and delivery processes the easier it is to deliver value to your internal customers
The fastest path to success is to begin with high-value capability like automated verification and validation of requirements, and automated generation of tests. It is very easy to show value even on the first projects.
Internal selling is essential. It is not enough to be the best technically. You need to communicate and demonstrate value to your organization
You need to define your value proposition to compete for the projects where alternative providers may be under consideration. The emphasis in early projects will be the cost and speed of your services.
Your organization might be unaware of all the capabilities and value of Requirements optimization and management. Educate your organization, evangelize IT management, and create workshops for the decision makers. Blueprint can assist you in this.
Robust infrastructure and automation platforms are essential to success of the Requirements CoE. Simply having good processes will not prove that you do the job better than any other internal and external competitor
Knowledge accumulation is critical for continual improvement of Requirements Development practices. You will need to ensure that every member of the CoE reports all findings in these areas
Ensure that you measure your achievements. This is important for controlling the value of the CoE and also proving the value to the outside world.
You need to provide your customers with high visibility into your progress, status, and findings. Lack of information drives customer dissatisfaction.
While your goal is to standardize processes and practices to ensure lowest cost and the highest efficiency, you need to be “easy to do business with”. This means flexibility to adopt your approach and your capabilities to the customer’s project framework and even culture.

For Part 1 of this article click on: http://www.batimes.com/component/content/article/106-articles/500-building-and-managing-a-requirements-center-of-excellence-part-i.html

Don’t forget to leave your comments below

Building and Managing a Requirements Center of Excellence. Part I.

Written by Tony Higgins on September 22, 2009. Posted in Articles.

Maximize Application Quality; Minimize Cost and Time-to-market.

The phrase “the world runs on software” is almost cliché now. Everyone’s life is a daily testament to this adage. Software is ubiquitous and is without question business critical. Virtually every modern-day business has some, if not all, of their business-critical functions implemented in software. In the software game, if you “get it right” the benefits of implementing business in software can be tremendous. If you don’t “get it right” you can find yourself out of business.

Errors in a software development projects have to be confronted if you are to deliver a product with any degree of quality – it isn’t a matter of “if” you fix them, it’s a matter of “when”. Most errors in a software development project originate very early in a project during requirements definition – 68% in fact [Standish]. This represents a huge opportunity to improve software project performance since it is well known that errors are exponentially cheaper to fix when detected earlier in the development life-cycle. But how do we find errors at this early stage and/or prevent them altogether? How do we unambiguously communicate the requirements to developers, testers, and support personnel in a language they understand? Once these questions are answered, how then do we make this a core-competency of our software development capability across all projects? This is what a Requirements Center of Excellence (CoE) is intended to address. It is an investment to capitalize on what is one of the largest opportunities related to software development, and therefore business, today.

In short, a Requirements CoE is the consolidation and centralization of Requirements expertise, knowledge, process, and tools, so that it may be continually improved and leveraged to maximum advantage across all projects in an organization. With a Requirements CoE, valuable new lessons from one project, instead of taking months or years to propagate “organically” can be quickly leveraged across the organization thereby driving rapid improvement.

Just some of the benefits from implementing a Requirements CoE include:

Cost Savings. Early error detection and correction dramatically reduces rework

Efficiencies. Consolidation of disparate requirements initiatives

Reduced Time to Market. Reduced rework results in finished products sooner

Product Predictability. Early error detection reduces risk, improving predictability

Quality. Higher quality requirements and automatically generated inputs for Developers and Testers means less rework and higher quality results

Rapid Improvement. Requirements investments are leveraged across the organization much faster

One of the most promising aspects of a Requirements CoE is that it allows for consistent measuring performance from the perspective of business and end-user results across the organization – not just measuring systems and components at a project or departmental level. With all projects addressing requirements with a consistent approach, common metrics can be established and directly related to business objectives.

A Requirements CoE can be built incrementally with return on investment measured at every stage. For the more risk-averse you can start small, consolidating and leveraging existing requirements resources, and expand as the value is proven.

A Requirements CoE can dramatically reduce the cost of software development for the organization and provides mechanisms to make the benefits sustainable.

What is a Requirements Development Center of Excellence?

A Requirements CoE is an internal group focused on optimizing the quality of requirements produced for all software development projects, ensuring that the requirements reflect true business needs and that they can provide the basis for efficient and effective product development.

The types of activities a Requirements CoE performs include:

Requirements tool evaluation, standardization, purchase for the organization
Requirements process definition, standardization, and tailoring
Requirements Metrics definition, automation, collection, storage, reporting
Requirements Training and mentoring services for company staff
Project “Startup” services (assess, recommend tools, process, training, mentoring)
Requirements component reuse storage, repository, cataloguing, and guidance
Requirements model review and consulting services for projects
Requirements guidelines, standards, and best practices
Representation in industry Requirements community
(a more comprehensive list is provided later in this article)

Through the Requirements CoE approach, project teams are able to take advantage of all of the expertise, process, toolsets, and best practices the Requirements CoE has developed and consolidated. This section provides an overview of the Requirements CoE and examples of the services it can provide. The next section takes a closer look at the business value of implementing a Quality CoE

Traditionally every project team is an island with its own staff, tools, and practices. The Requirements CoE model centralizes the expertise and processes, brings Key Performance Indicators (KPIs) to requirements initiatives, and can actually reduce total headcount needed to develop, test, and deliver higher quality applications.

Checklist:

You Should Transition to the Requirements CoE Model soon if you have

Chronic overruns of project budget or schedule, or regularly change scope of application to meet targets
Inability to estimate the cost and schedule impacts of proposed changes during development
Different approaches to expressing requirements from project to project
Project success seemingly dependent on involvement of a few key individuals
No perceptible improvement in predictability of projects from one to the next
Applications that are difficult to modify or customize, and expensive to maintain
Incomplete or inaccurate technical documentation for an application

How a Requirements CoE works: Five Simple Examples

The examples below contrast how an organization might respond to real-world situations with and without a Requirements CoE.

Example 1: A key employee with several years’ experience in business analysis leaves the company mid-way through a critical project

With a Requirements CoE.: The company’s best practices for Requirements Development are defined and shared through the Center of Excellence. All Requirements Center models and sub-models developed by the Analyst over the years are immediately available from the Requirements repository maintained by the Requirements CoE. The Requirements CoE can provide short-term relief to the current project with Business Analysis skills, and/or help ramp up a replacement with any training and mentoring that may be required.
Without a Requirements CoE. The project scrambles to find a replacement and then ramp up that replacement on the manner in which this project works with requirements. Information, notes, emails, and any other bits of information found are gathered in an attempt to reconstruct requirements in their current state. Co-workers and past colleagues are polled to find historical knowledge from the employee.

Example 2: Acquire a Company

With a Requirements CoE. All projects of the “host” company develop requirements in a consistent and effective fashion in accordance with the company’s best practices for Requirements Development as defined and shared through the CoE. CoE experts assess the acquired company’s Requirements Development capabilities and make recommendations for transition and any modification to existing assets (eg. Project Start-up packages, courses, packaged services, etc.). Training and mentoring packages of the CoE are used as part of a transition plan to educate staff of the acquired company. Project Start-up packages, maintained and delivered by the CoE, are used to launch new projects within the acquired company or as a basis to plan transition of projects in progress, where appropriate. A focused transition with well-defined “end-state” where all expectations of host and acquired staff can be managed effectively. Acquired staff gets a sense they are transitioning to a well-managed environment.
Without a Requirements CoE. Host organization differs in Requirements Development approach from project to project, with low level of consistency. Not clear what acquired company should transition to, if to transition at all. Result is perpetuating acquired company’s requirements approach thereby creating yet another “stovepipe” in the organization, inhibiting integration of the acquired company and the efficiencies that should have been gained because of it. With no clear “end-state” for the requirements discipline the expectations of acquired staff are difficult to manage and they lack a sense of moving to something better. Instead they have a sense of being assimilated into a chaotic environment. Morale diminishes among the acquired staff increasing turnover, reducing productivity, and increasing risk of failed acquisition.

Example 3: External party (customer, prospect) to review or audit software development capability.

With a Requirements CoE. Requirements Development process including best-practices, sample artefacts, templates, guidelines are maintained by the Requirements CoE and made accessible to all projects. Project performance measures collected analyzed and reported on by the CoE are also available. Any mappings of adherence to industry models (CMMi, ISO, etc.) are also be maintained by the CoE. All this information is available for review by the external party and can be explained and discussed with experts from the CoE. Projects in progress can be shown to adhere to the standard process and any can be chosen as an example for further examination.
Without a Requirements CoE. An effort is launched to canvas projects seeking the “nicest” examples of requirements artifacts. Any process descriptions are similarly gathered or created in order to explain how requirements activities are performed. Directories for old projects are scanned, again seeking good examples of requirements artifacts. Metrics on performance are gathered where they exist, and attempts made to normalize and reconcile them in order to extract some meaning.

Example 4: A new, business-critical project initiative is being considered and accurate estimates of time and cost are required in order to make a decision to proceed.

With a Requirements CoE. Requirements models for past projects in the repository are examined for reusable models and sub models. Metrics on past project performance are analyzed. A high level, abstract Requirements Center model is created and supplemented with any reusable sub-models found. This model, along with performance metrics gathered, is used as key basis for estimating the new initiative.
Without a Requirements CoE. Pull most knowledgeable, senior people from current assignments together and collect subjective impressions from past projects of similar nature, magnitude and complexity, if they exist. Estimate for new initiative is based on these impressions and personal experience.

Example 5: A new project is being launched, and the “environment” consisting of process and tools needs to be established.

With a Requirements CoE. The Project Manager notifies the CoE of the new project. Experts from the Requirements CoE deploy the “Project Start-up” packaged service. They assess the project to deduce best fit, given project type, complexity, duration, budgets, people, etc. CoE experts deliver training and mentoring, deploy and configure the toolset, and put process in place. The CoE experts assist with project launch and deliver mentoring with emphasis during early stages of Requirements Development, ensuring staff are proficient with process and tools. Initial artifacts are reviewed by CoE experts to help staff converge on the optimal solution. CoE experts are involved in every major project review and are on call to provide “Just in Time” mentoring and assistance. CoE experts liaise with tools manufacturers as “single point of contact” for special requests and support on behalf of all projects.
Without a Requirements CoE. The Project Manager tries to secure time with process “experts” from wherever they may be in the company. Experts and senior project staff do “process engineering”, typically under project budget, to identify desired approaches, tools, templates, guidelines, etc. for the project. The results of this activity are highly dependent on the personal experience of the individuals involved. The project then puts all in place, must devise means of educating staff, acquires and deploys/configures tool(s). Interfacing with vendor is often done by designated project staff. When issues arise with process, tools, advice is sought in informal manner from whatever source might be available.

Start Small and Grow Organically

One of the key advantages of a Requirements CoE is that it can be established incrementally and show incremental returns on investment. A Requirements CoE can be built on a small scale initially with minimal capital expenditure and you can scale up its resources, services, and capabilities incrementally as its value is proven.

Initially the Requirements CoE could focus on the standardization of requirements artifacts including notations and formats. This can be followed by, or deployed in conjunction with, standardization of tool support for defining requirements. In time, the process by which requirements are developed based on the notations and automation can be formalized and tuned. The standardized process would include aspects made possible only by automated tool support, such as immediate validation of requirements using simulation and testability assurance. Still later a centralized repository for requirements artifacts to facilitate reuse could be added followed by a formal requirements metrics program to provide the basis for continual requirements improvement.

Therefore the CoE can grow both in capability and breadth of adoption across the enterprise at a rate that fits the constraints of the organization.

Requirements CoE Resources and Services

The Requirements CoE has the potential to become a competitive advantage for any company whose business relies on software. Since requirements are the cornerstone of the software development process with all other disciplines dependent on its artifacts and with 68% of all errors being introduced at this point, there is tremendous potential for cost-savings and quality improvement. The nature of the services that can be provided by a Requirements CoE include:

“Project Start-up” Services with Respect to Requirements

Leverage the growing Requirements Development knowledge and experience base
Provide expert assistance in assessing and devising best approach for tools, process, and training/mentoring needs for the project
Assist in setting up environment including project guidelines, standards, templates, and other assets
Deliver training and mentoring in Requirements Development process and tools

To be a Cross-product/divisional “Communication Hub” for Requirements

“harvest” business assets and make reusable
- Business cases and studies to make it easier for other divisions to adopt
“harvest” technical assets and make reusable
- Best practices in Requirements Development across projects
- Reusable Requirements components
- Reusable Requirements Training components
Establish mechanisms to foster communication in Requirements Development
- Newsletters, bulletin boards, interest-group meetings

Requirements Development Tool Expertise

Single point of liaison with Requirements Development tool vendor. Promote organization’s interests, enhancement management, beta participation
First-line support for Requirements Development tool
Experts in tool configuration for specific project usage and application
Development of, and repository for examples templates that support process
Best Practices in tool usage for specific applications

Requirements Development Process Expertise

Generation and maintenance of standard Requirements Development process
Expertise to tailor and adapt the standard process to suit specific projects
Collection of empirical data and metrics to facilitate continual process improvement
Expertise to teach and mentor project staff in Requirements Development process

Education and Awareness of Requirements Development to the Larger Organization

In early stages this new discipline will be largely unknown to most. This center should be capable of fielding requests for information and providing introductory education
Should also be in a position to deliver demonstrations, learning sessions, and similar as part of awareness efforts

To Liaise with Industry Associations and Represent the Organization in these Forums

In order to “harvest” best-practices and approaches found by others, and to monitor trends in the discipline
In order to contribute organizational learning

To provide these services the Requirements CoE should maintain a core staff, whose levels will depend upon how aggressively the organization chooses to grow the discipline. Initially this could involve a part-time manager and single domain expert but could scale over time to support an enterprise.

In this article, we have discussed what a Requirements CoE, is and how it works. Stay tuned for next issue’s follow up, on why organizations should adopt a Requirements CoE, and step-by-step lessons on how to build one.

Don’t forget to leave your comments below