Author: John Simpson

Managing Requirements 101

Written by John Simpson on September 13, 2011. Posted in Articles.

Wish someone would explain requirements management in plain English? Have stakeholders that could benefit from understanding the value at a high-level? Your executives might not care about CMMI, BABOK or the nitty gritty details of functional specifications, but they do care about delivering what was promised to customers on time. And that’s the value of requirements management.

Too often projects fail due to poorly managed requirements. At the core of the issue is that projects are increasingly complex, changes occur and communication is challenging. In this paper we will discuss the significance of requirements management without using industry jargon, as well as, the four fundamentals every team member and stakeholder needs to know. No Ph.D. required, no 2-week certification course, just the basics to help your team deliver what you promised.

Why successful teams do requirements management.

Requirements management is about keeping your team in-sync and providing visibility to what is going on within a project. It is critical to the success of your projects for your whole team to understand what you are building and why – that’s how we define requirements management.
The “why” is important because it provides context to the goals, feedback and decisions being made about the requirements. This increases predictability of future success and potential problems, allowing your team to quickly course correct any issues and successfully complete your project on time and within budget. As a starting point, it’s valuable for everyone involved to have a basic understanding of what requirements are, and how to manage them.

Let’s start with the basics. A requirement is a document (a.k.a. artifact) that defines what you are looking to achieve or create – it identifies what a product needs to do, what it should look like, and explains its functionality and value. A requirement can be expressed with text, sketches, detailed mockups or models, whatever information best communicates to an engineer what to build, and to a QA manager what to test.

Depending on your development process, you might use different terminology to capture requirements. High-level requirements are sometimes referred to simply as “needs” or “goals”. Within software development practices, requirements might be referred to as “use cases”, “features” or “functional requirements”. Even more specifically within agile development methodologies, requirements are often captured as “epics” and “stories”.

Regardless of what your team calls them or what process you use, requirements are essential to the development of all products. Without clearly defining requirements you could produce an incomplete or defective product.
Throughout the process there can be many people involved in defining requirements. A stakeholder might request a feature that describes how the product will provide value in solving a problem. A designer might define a requirement based on how the final product should look or perform from a usability or user interface standpoint. A business analyst might create a system requirement that adheres to specific technical or organizational constraints.

or today’s sophisticated products and software applications being built, it often takes hundreds or thousands of requirements to sufficiently define the scope of a project or a release. Thus, it’s imperative that the team be able to access, collaborate, update, and test each requirement through to completion, as requirements naturally change and evolve over time during the development process.

Now that we’ve defined the value of requirements management at a high-level, let’s go deeper into the four fundamentals that every team member and stakeholder can benefit from understanding:

1. Planning good requirements: “What the heck are we building?”

2. Collaboration and buy-in: “Just approve the spec, already!”

3. Traceability & change management: “Wait, do the developers know that changed?”

4. Quality assurance: “Hello, did anyone test this thing?”

ONE: Planning good requirements

So what makes a good requirement? A good requirement should be valuable and actionable; it should define a need as well as provide a pathway to a solution. Everyone on the team should understand what it means. Requirements vary in complexity. They can be rough ideas sketched on a whiteboard to structured “shall” statements. They can be part of a group with high-level requirements broken down into sub-requirements. They may also include very detailed specifications that include a set of functional requirements describing the behavior or components of the end product.

Good requirements need to be concise and specific, and should answer the question, “what do we need?” rather than, “how do we fulfill a need?” Good requirements ensure that all stakeholders understand their part of the plan; if parts are unclear or misinterpreted the final product could be defective or fail. Preventing failure or misinterpretation of requirements can be aided by receiving feedback from the team continuously throughout the process as requirements evolve. Continuous collaboration and buy-in with everyone is a key to success.

TWO: Collaboration and buy-in.

Is everyone in the loop? Do we have approval on the requirements to move forward? These questions come up during development cycles. It would be great if everyone could agree on requirements, but for large projects with many stakeholders, this does not usually happen. Trying to get everyone in agreement can cause decisions to be delayed, or worse, not made at all. Gaining consensus on every decision is not always easy. And in practice, you don’t necessarily want “consensus,” you want “buy-in” from the group and approval from those in control so you can move the project forward. With consensus, you are trying to get everyone to compromise and agree on the decision. With buy-in, you are trying to get people to back the best solution, make a smart decision and do what is necessary to move forward. You don’t need everyone to agree that the decision is the best. You need everyone to support the decision.

Team collaboration can help in receiving support on decisions and in planning good requirements. Collaborative teams work hard to make sure everyone has a stake in projects and provides feedback. Collaborative teams continuously share ideas, typically have better communication and tend to support decisions made because there is a shared sense of commitment and understanding of the goals of the project. It’s when developers, testers or other stakeholders feel “out of the loop” that communication issues arise, people get frustrated and projects get delayed.

Once everyone has bought-in to the scope of work, it is imperative for requirements to be clear and well documented. Keeping track of all the requirements is where things get tricky. Imagine having a to-do list a mile long that involves collaborating with multiple people to complete. How would you keep all those items straight? How would you track how one change to an item would affect the rest of the project? This is where traceability and change management add value.

THREE: Traceability and Change Management.

Requirements traceability is a way to organize, document and keep track of the life of all your requirements from initial idea through to testing. A simple metaphor for traceability is connecting the dots to identify the relationships between items within your project. Here is an example of a common downstream flow:

You should be able to trace each of your requirements back to its original business objective. By tracing requirements, you are able to identify the ripple effect changes have, see if a requirement has been completed and whether it’s being tested properly. Traceability and change management provide managers peace of mind and the visibility needed to anticipate issues and ensure continuous quality.

Traceability also allows for coverage that provides the ability to make sure the product meets all the vital requirements. Because requirements come from different people – from the customers to the engineers – each person contributes different requirements to the project. By tracing requirements, you ensure your entire team stays connected to the interdependencies of other items and the people working on those items.

Managing change is important and prevents “scope creep” within projects and releases. Scope refers to “the work that needs to be accomplished to deliver a product with the specified features and functions.”3 Scope creep refers to unplanned changes in development that occur when requirements are not clearly captured, understood and communicated. The benefit of good requirements is a clear understanding of the end product and the scope involved. This leads to a better development schedule and budget, which prevents delays and cost overruns.

FOUR: Quality Assurance.

Getting requirements delivered right the first time can mean better quality, faster development cycles and higher customer satisfaction with the end product. Requirements management not only helps you get it right, but also helps your team save money and many headaches throughout the development process. Concise, specific requirements can help you detect and fix problems early, rather than later when it’s much more expensive to fix.

Research has shown that project teams can eliminate 50-80 percent of project defects by effectively managing requirements. In addition, it can cost up to 100 times more to correct a defect later in the development process after it’s been coded, than it is to correct early on while a requirement.4 By integrating requirements management into your quality assurance process, you can help your team increase efficiency and eliminate rework. And, rework is where most of the cost issues occur. According to the Carnegie Mellon Software Engineering Institute, “60-80 percent of the cost of software development is in rework.” In other words, development teams are wasting the majority of their budgets on efforts that aren’t performed correctly the first time. For example, a developer codes a feature based on an old specification document, only to learn later that the requirements for that feature changed. These types of issues can be avoided with requirements management best practices.

In Summary.

Requirements management can sound like a complex discipline, but when you boil it down to a simple concept – it’s really about helping teams answer the question, “Does everyone understand what we’re building and why?” From the business analysts, product managers and project leaders to the developers, QA managers and testers, along with the stakeholders and customers involved – so often the root cause of project failure is a misunderstanding of the scope of the project.

When everyone is collaborating together and has full context and visibility to the discussions, decisions and changes involved with the requirements throughout the lifecycle of the project, that’s when success happens consistently and you maintain continuous quality. Also, the process is smoother with less friction and frustration along the way for everyone involved.

And, isn’t that something we’d all benefit from?

Don’t forget to leave your comments below.

John Simpson is a Vice President at Jama Software where he represents the voice of their customers in the development of Contour, collaborative requirements management application. John has over 16 years of experience in the enterprise software industry, having worked at Microsoft, WebTrends and Omniture (now owned by Adobe) prior to Jama. He has contributed to several articles, whitepapers, videos and presentations on business analysis, collaboration, Web technology and innovation. When not at work, John is an avid runner and fundraiser for cancer research supporting Komen for the Cure and the Lance Armstrong Foundation. He lives in Portland, Oregon where Jama is headquartered.

References
1. To learn more about good requirement and ambiguous terms to avoid be sure to check out our “Ambiguous Terms To Avoid” whitepaper.
2. A Guide to the Project Management Body of Knowledge. 4th ed. Project Management Inst, 2008. Print.
3. “Effective Requirements Definition and Management.” Borland Software Corporation. 2009. Web. <http://www.borland.com/resources/en/pdf/solutions/rdm_whitepaper.pdf>.4. “Effective Requirements Definition and Management.” Borland Software Corporation. 2009. Web. <http://www.borland.com/resources/en/pdf/solutions/rdm_whitepaper.pdf>.
Other articles we referenced during our research, and recommend if you’re interested in learning more.
5. “Business Requirements Analysis.” MindTools. Web. <http://www.mindtools.com/pages/article/newPPM_77.htm>.
6. Frederick, Richard. “Introduction to Requirements – The Critical Details That Make or Break a Project.” Global Knowledge. 2007. Web. <http://www.globalknowledge.fr/PDF/WP_>
7. Larson, Elizabeth & Richard. Project Times. Web. <http://www.projecttimes.com/articles/>.
8. Ludwig Consulting Services, LLC. 2009. Web. <http://www.jiludwig.com/>.
9. McMahon, Chris. “The Full Team Approach to Managing Requirements.” Search Software Quality. Serena, Web.
10. “Real Reuse for Requirements.” MKS. Web. <http://www.mks.com/resources/data/>.
11. Robin, Goldsmith F. “Four Tips for Gathering Requirements for the New Business Analyst.” Search Software Quality. IBM, Web.
12. Wikipedia. Requirements Management, Traceability, Scope, 2011. Web. <http://www.wikipedia.com/>.

The State of Requirements Management

Written by John Simpson on December 15, 2009. Posted in Articles.

Goodbye 2009, Hello 2010!

For many organizations, 2009 simply can’t end fast enough. The brutal economy made for a tough year, there’s no denying that. However, taking a moment to reflect on things from a business analyst’s point of view, I believe there are a few bright spots to celebrate. Consider them the signs of hope for a better 2010. In this article, I want to highlight three trends we first saw emerge from The State of Requirements Management Report we published back in June 2008 on the challenges, trends and solutions happening in software product development. In that report we surveyed 200 organizations and explored topics such as:

What are the biggest challenges in innovation that companies face?
Is the Agile process over-hyped?
How does collaboration apply to requirements management?
What frustrates people more – scope creep, unrealistic expectations or lack of testing?
Which genre of music is most popular? OK, that one we threw in just for fun.

I never anticipated the kind of response that report would get, with over 18,000 downloads of it since we first published it, but in hindsight I think it struck a chord with people, especially those in the business analyst community, shedding light on some of the challenges we all deal with day in, day out. You can read the full report and compare the results to what you experienced this year. I would be curious to hear your thoughts and experiences. http://www.jamasoftware.com/media/documents/State_of_Requirements_Management_2008_Jama.pdf

As I look back on 2009, the three positive trends I saw emerge which will carry over into 2010 include:

1. Greater Respect and Appreciation for the Business Analyst Role

Understanding what the customers need and documenting all the requirements isn’t easy. In fact, these were the top challenges based on feedback we saw within The State of Requirements Management Report at 65% each.

As it becomes more apparent to executives and senior management that requirements are the building blocks of innovation, the respect for the people whose job it is to manage requirements increases. Can you say “Christmas bonus”? And, I’m not talking fruit cake; give the BAs you love something good this year!

In all seriousness, this heightened appreciation for BAs is also reflective in its being an area of job growth, despite high unemployment rates in other sectors. Essentially, if you have strong business analyst and product management skills, you are in high demand. Feel good about that for a moment, now put down the eggnog and get back to work. You’re only as good as your latest specification, right?

2. Greater Accountability for the Requirements Shared by the Entire Team

Collaboration has been a hot trend in product development for a few years now. But, what does that really mean in terms of results? One of the lesser known benefits of better collaboration is that over time you see an increase in accountability across the entire team for getting the requirements right and building the products to spec. That’s a good thing for everyone. How often before did all the responsibility fall just on the shoulders of the business analyst or product manager to define the set of features and write gorgeous requirements that would be magically understood and implemented flawlessly by all?

Truly collaborative teams embody this shared accountability which raises the bar for everyone involved, whether it’s your job to listen to the customer and capture the requirements or interpret the detailed requirements downstream to code and ensure the functionality is right. When everyone contributes to the development of the requirements, the success rates increase dramatically.

If your team doesn’t embody this characteristic now, you might want to make it a priority in 2010, or hope for a miracle bag of requirements pixie dust from Santa. I think that’s high on the wish list right after the Wii and Twilight stuff.

3. Agile is More of a Mindset than a Development Process.

Man, there was a ton of attention given to Agile again this year. Agile conferences. Agile books. Agile processes du jour. I think I’ve contracted “Agileitis”, the rapidly, contagious disease that can be spread from the “pigs” to the “chickens” in a Scrum daily stand-up meeting… I know there’s a bad Swine flu / Bird flu whopper of a joke in there somewhere.

The key point is, Agile isn’t just a flavor of development process. It’s a core philosophy – a cultural mindset of embracing change, inviting the voice of the customer into your process throughout, and designing workable software that is continuously improving over time. Call them releases, iterations, sprints, milestones – whatever you want. The labels are less important than the outcome of the products you produce. The evolution I saw emerge in 2009, and will continue in 2010, is the concept of a “hybrid” approach where mature companies merge disciplined requirements management practices for proper planning and requirements documentation, with the freedom for developers and testers to adopt more agile, lightweight methods to build and test new releases. It’s the best of both worlds.

I’ve seen many companies be successful with a hybrid process, and one of the reasons it’s more prevalent now is that the tools available today are designed to flex to support whatever process or processes work for your team.

Big picture – the goals are the same – build great products faster, cheaper and with higher quality. My recommended New Year’s Resolution: Adopt whatever mix of processes, people and tools you need to achieve your goals, demand and accept nothing less, and you’ll have a great 2010.

Looking ahead to January – Share Your Voice.

In January, I’ll be conducting the 2010 State of Requirements Management Survey and would love your participation. That way, we can establish an annual benchmark study for our industry on what’s real and what’s hype, and see what others are doing to be more successful managing requirements. So look for that after the holidays.

On a personal note, from my family to yours – I’d like to wish everyone and their families – happy holidays and best wishes for a prosperous new year! See you in 2010.

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware.

Connect the Dots; Five Tips on Requirements Traceability

Written by John Simpson on November 17, 2009. Posted in Articles.

As a business analyst do you ever feel like you are Russell Crow’s character in the movie A Beautiful Mind where it takes a genius to track and relate all the information you’re managing within your projects?

Welcome to the World of Requirements Traceability and Impact Analysis

In this article, our goals are to demystify traceability and its related concepts, and provide insights and examples for five tips to help you take control of requirements and keep everyone in sync. Traceability is a hearty topic, so along the way, we’ll try like heck to keep things educational and entertaining, such as other movie references to The Matrix and Quicksilver.

Have we piqued your interest? Read on my business analyst friends…

What the Heck is Traceability?

It sounds so clinical and complicated. Why do teams do it? It sounds like a lot of work. Is traceability really worth the effort? Good questions. The short answer: Yes. And, here’s why it’s so important in one word: Change.

If managed poorly, change will wreak havoc on even the most talented and experienced development teams. If change is managed skillfully, using tools like traceability, teams are better equipped to assess the impact of changes, track the history, keep everyone in sync and (deep breath) consistently improve the quality of the products they’re building – every project, every release. Sign me up.

In some industries, traceability isn’t an option, it’s mandated. I’d recommend that regardless of the industry you’re in or the process you use – whether you’re building components for commercial airplanes using Waterfall or designing the next killer iPhone app using an Agile method – traceability is an industry best practice that will benefit your team greatly. But, like everything it comes with its challenges.

CHALLENGES

Swimming Upstream or Downstream without a Trace is Risky Business

You can probably relate to these scenarios. You get a great new insight from your best customer mid-project, and a high-level business requirement needs to change. How will this change impact the functional requirements your developers are working on right now? Your QA team just found a deal breaker of a bug in your most popular feature and you’re two weeks away from launch. Do you ship with the known bug or delay the launch? Who is working on that feature? Who else needs to be notified and weigh in on the decision? What else does it affect? These scenarios occur daily for development teams. So, how do you deal with them? How do you minimize risks and manage change effectively? One of the tools in your arsenal is traceability.

One common challenge that teams face in implementing traceability is the incremental time and costs involved. There’s no question that in order to do traceability well, there is a time investment that’s needed upfront to set up the trace relationships and configure coverage reports. However, the incremental costs incurred with using traceability are significantly outweighed by how much time and money you will save further along in the development process, due to the benefits that traceability provides.

BENEFITS

Traceability is Your Ticket to Greater Project Success – On Time, On Budget and Within Scope

For most organizations, the benefits outweigh the time required to set-up traceability by at least 2X. With a consistent process, structured templates and the help of a modern requirements management tool, much of the process can be automated and streamlined. Even if you opt to manage it manually, traceability offers several valuable benefits to your organization:

Minimize Risk. Assess risks and the overall impact of a change before it’s made
Control Scope Changes. Manage change throughout the process and avoid scope creep
Improve Quality. Ensure quality standards are met or exceeded to achieve industry compliance
Reduce Development Costs. Avoid gold plating and costly engineering rework
Increase Productivity. Keep the team in sync and reduce administrative overhead
Complete Test Coverage. Ensure all requirements are properly tested before a release
Greater Visibility. Gain end-to-end visibility into the process for the entire team and stakeholders
Accelerate Innovation. Cut product planning and developments cycles in half

TERMINOLOGY

Before we dive into the five tips, let’s take a moment to define a few terms.

Terminology	Definition
Traceability	Traceability is a sub-discipline of requirements management. Traceability documents the life of a requirement, tracks every change and links its relationships with other items within a project.
Trace Relationship	A link between items within the scope of a project, used to help assess impact on other items when a change occurs.
Upstream	Upstream relationships, a.k.a. backward traceability, look at the links between detailed functional requirements back up to the original customer need and high-level requirements captured. It’s used to ensure that the evolving product remains on track in regards to the goals of the product and what customers need. Helps to avoid scope creep and gold plating.
Downstream	Downstream relationships, a.k.a. forward traceability, look at the links between a high-level requirement and the functional requirements, test cases, tasks, defects and other items that support it. It’s used to ensure that you’re building the right product.
Traceability Matrix	A traceability matrix is created by associating requirements with the work products that satisfy them. Often it’s used to track tests associated with the requirements on which they are based and the product tested to meet the requirement.
Impact Analysis	Using impact analysis, traceability links between requirements, specifications, design elements, and tests are captured, and these relationships can be analyzed to determine the scope of an initiating change.
Version History	Used for change control, a detailed history of each version of a requirement, or other types of items, is documented and stored in a system of record, enabling complete audit trails used for change management over the lifecycle of the requirement.
Suspect Links	Suspect links help to manage the impact of requirement changes. A trace relationship (or link) becomes suspect after a requirement in the relationship changes. A suspect links report is often used along with Impact Analysis for assessing impact before making a change.
CMMI	Created by the Software Engineering Institute, CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. As it relates to traceability and requirements management maturity, see Levels 2-3.

TIP #1. It’s like the Six Degrees of Separation from Your Business Objectives (instead of Kevin Bacon)

Look at that, we managed to slip in a Kevin Bacon reference. It isn’t just because we’re fans of the movie Quicksilver, it actually has relevance here. As in many aspects of life, your product development success is highly dependent on relationships. All of the details such as user requirements, functional requirements, test cases and other items that define the scope of what you’re building are related in some fashion, either directly or indirectly. Here’s an example of a common process flow.

Using trace relationships you can connect everything together to map out the interdependencies between the different items. These relationships are the foundation for doing traceability effectively. As another example, here’s a screenshot of a Visual Traceability Layout showing both upstream and downstream items related to this requirement.

In addition, trace relationships are as much about connecting the people involved as about connecting all the items. Each requirement in the system has customers, stakeholders and members of your team associated with it. There are analysts who own defining it. There are developers building it. There is the QA team testing it. And, there are stakeholders and customers who care about its status.

When one item changes it has a ripple effect on other related items and the people associated with it. Keeping track of this ripple effect is crucial to the success of your projects. That’s one of key reasons to do traceability.

TIP #2. Mr. Anderson – Welcome to the Traceability Matrix.

Wow! And now a reference to The Matrix movie; we’re on fire. In all seriousness, a Traceability Matrix isn’t science fiction. It’s very real, and can be a valuable report for helping you ensure complete test coverage. For a manual example of a Traceability Matrix, you can build one in Excel such as this one courtesy of Joyce Ludwig.

ID	User Requirements	Forward Traceability
U2	Users shall process retirement claims.	S10, S11, S12
U3	Users shall process survivor claims.	S13

ID	System Requirements	Backward Traceability
S10	The system shall accept requirement data.	U2
S11	The system shall calculate the amount of retirement.	U2
S12	The system shall calculate point-to-point travel time.	U3
S13	The system shall calculate the amount of survivor annuity.	U3

This simple insurance claims system example shows both forward and backward tracing between user and system requirements. User requirement identifiers begin with “U” and system requirements with “S.” Tracing S12 to its source shows this requirement is problematic, and should be rewritten to support the processing of survivor claims or the traceability link corrected.

Here is an example of an automated Traceability Matrix generated from Contour. In this example, the matrix is reporting on the relationships between Features and Test Cases. This is useful to identify gaps in test coverage, which is a popular use of a trace matrix to ensure each feature is properly tested.

TIP #3. Impact Analysis – Your Virtual Crystal Ball into the Future.

What if you could anticipate the impact a change would have on your project and the entire team before it occurred? Would this potential change send the development team over the edge or would they have bandwidth to squeeze it into the next release? These insights are possible and the tool to get them doesn’t require a Weegie board or any magical pixie dust, just Impact Analysis. Impact analysis relies on the trace relationships you’ve set-up prior and reports on the complete picture of all the items that are affected – both directly and indirectly.

Here’s an example of an automated impact analysis report for a high-level business requirement. If it were to change, four directly related system requirements would be affected and one indirect use case would also be impacted.

Now if only we could apply impact analysis to other aspects of our lives, like the decision to have that second helping of pumpkin pie on Thanksgiving. What’s the impact on “project reduce fat tire”? Oops, better expand the scope on that one and push out the release date until New Year’s.

TIP #4. Version History – Your Complete Audit Trail in Rich, Glorious Detail. Whoohoo!

If you prefer things at a high-level and don’t like to dive into the details, look away. This tip isn’t for you. This tip on version history is for those among us that like to roll-up their sleeves and get deep into the glorious details of every little change. It’s also been humorously referred to as the “CYA tip”, for coverage of a different kind.

Personal motives aside, capturing a complete and detailed record of all changes is a critical element for reaching higher levels of requirements maturity within your process, such as CMMI. It’s also helps companies meet industry compliance standards in specific fields, such as aerospace and medical devices. One of the benefits of doing traceability is having a comprehensive audit trail of changes, so you can analyze who, what, when and why a change occurred. At the same time, you can easily roll-back to an earlier version if needed because it’s all stored in the unified system of record.

Here’s an example of seeing a side-by-side comparison of two versions, using an automated process within Contour. For efficiency gains, the specific field that changed is highlighted in yellow, so you don’t have to spend time hunting around the full requirements specification document to pinpoint and understand precisely what changed. Viva la details!

As with the other aspects of traceability, you can track version history manually through static documents using versioning. It’s just more cumbersome and time consuming to manage complex projects that way.

TIP #5. Avoid Noise. Communicate Changes Quickly, Intelligently and to Those Who Care

How often have you been involved in a project where “change notice paralysis” sets in after about two to three weeks of inbox overload? Usually it occurs when the entire team is on a project-wide distribution list and the project manager is on the hook to send out an email with the complete 200-page Software Requirements Specification document attached for every little change that occurs. Right intention, wrong solution. What happens next? People waste time hunting around in the requirements spec, trying to determine if the latest change is relevant to them, which is costly. Or, they tune out the email barrage as noise and become vulnerable to missing a change that is important to what they’re working on, which is also costly.

There are smarter ways to keep everyone on the same page. You need to ensure that everyone impacted by a change is in the loop. At the same time, you don’t want to flood the entire organization with emails. What do you do?

In this example using Contour, when a change occurs, you can instantly send a direct link to the specific requirement that changed with version notes to just the relevant groups or individual users that are affected by it. The notification step is then part of the overall change management workflow. Stay in the loop. Avoid noise.

Let’s Automate!

You can manage traceability manually using Microsoft Word or Excel documents. That’s a real option. For small teams and simple projects, that’s probably all you need. We’ve provided links to a few free templates courtesy of industry experts that you can use to manage traceability manually:

Traceability Matrix Template (.xls) from the CDC.gov, requirements management templates
Impact Analysis Checklist (.doc) from Karl Wiegers, Process Impact

The challenge with a manual process is it can be extremely time consuming and cumbersome if your projects have any level of complexity – meaning you have many requirements, frequent scope changes or if members of your team are remote working from different locations. In these scenarios, automation can provide a huge boost to productivity, saving you valuable time and money. Automation also minimizes the risks of human error.

What’s the ROI?

The return on investment is different for every company, but through our experience, we’ve seen as high as a 42:1 benefit-to-cost ratio for a global entertainment company. For most organizations, as a conservative benchmark, you can expect to speed development cycles by 50% and improve quality by 2X or more within the first six months, using a requirements management application.

Take Action!

Concepts are nice, but actions are what matter most. Take action today to become a traceability master.

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 14 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware

Why on Earth Would You Promote a Business Analyst?

Written by John Simpson on October 20, 2009. Posted in Articles.

We have a recommendation. Whether their official titles are Business Analyst, Product Intelligence Analyst, Requirements Analyst or something else, if they define and manage requirements as a core function of their jobs, then they are strong candidates for a promotion. Think this is a crazy request during this bad, but they tell us, improving, economy? Maybe it’s not such a bad idea at all!

Read on to understand the five reasons why senior executives at innovation-driven organizations are realizing how strategically important business analysts are to the overall success of their companies. And, they are rewarding those who excel in this role. We’ll leave it to the bosses to decide exactly how they want to spread the love – bonuses, parking spots or other perks are always nice.

In many places the Business Analyst role doesn’t get much appreciation, because its value is misunderstood or viewed just as a tactical role. Let’s debunk those myths here by examining the important role the BA has throughout the organization.

They are Shepherds of Innovation

As you know, innovation isn’t just a hyper-buzzword. Innovation is what customers demand, it’s what shareholders expect. And it’s what helps fatten the coffers of most successful corporations. How many nights do you lie awake thinking about how to more effectively deliver innovative products to market faster than the competition?

As unsexy and tactical as “requirements management” sounds and maybe is perceived, it is the foundation of an organization’s ability to innovate. As business analysts, these employees are your shepherds of innovation. Try that sound bite out at your next company meeting and see how the morale and company culture changes to embrace this important function.

Project Success Lives or Dies by Requirements Management.

This isn’t meant as a statement to create dramatic effect – study after study shows that the management of requirements is a top success factor. If you work in an industry such as Aerospace, Medical Devices or Healthcare where safety isn’t optional, then requirements management is itself a mandated requirement. Based on that, it seems reasonable to suggest that anyone who manages a function that’s this critical to the success of your company deserves some kudos. For example, the newly published Business Analysis Benchmark Study by IAG Consulting highlights several major findings, including:

Companies with poor requirements, on average, spend $2.24 million more per project on strategic projects than those that employ requirements best practices.
Companies with poor requirements and business analysis capability have three project failures for every one project success.
Only 32% of companies employ practices that make the likelihood of project success “Probable.” The remaining 68% enter every project with an “Improbable” likelihood of success, even before they begin the project
Over 40% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts. This requirements premium is avoided by organizations that consistently use best practices in business requirements when completing projects.

An Idea is Worth $0 Until it Becomes a Well-executed Requirement.

We see requirements as the glue that holds the entire innovation process together – from ideas to requirements to products. So, without well-defined, well-managed and well-executed requirements, innovation simply doesn’t happen. Good ideas don’t materialize, R&D investments go to waste and smart people get frustrated – all things that paralyze an organization. Thus, an investment in requirements management and in this key role will yield a higher Return on Ideas – think of it as a new kind of ROI to go with the financial one.

They Save Your Company “a lot” of Time and Money.

Call it productivity. Call it efficiency. Call it failure avoidance. Whatever you want to call it, your business analysts save your company a lot of time and money. How much is a lot? It can be a difficult thing to quantify precisely, but a lot is somewhere between “oodles” and “a truck load”. And we all have an idea how much that is! How ever you measure it, when requirements get done properly, projects get delivered on time and products go to market faster. And, last time we checked, those were two things that great companies and senior executives valued. A lot!

Chief Business Analyst Sounds Pretty Nice.

Meet the new Chief Business Analyst, time to make room at the executive table! Should we get new business cards printed up? We’re not kidding. By championing the development of thousands of well-written requirements and collaboratively managing them throughout your innovation process, your staff of business analysts significantly impact the performance of your company every day. And, that makes them a strategic asset. Hmm, that sounds like a function worthy of a C-level executive. We think CBA sounds pretty nice too.

References: http://www.iag.biz/resources/library/business-analysis-benchmark.html A summary of the Business Analysis Benchmark appeared in a recent Business Analyst Times. To reach it click http://www.batimes.com/component/content/article/106-articles/517-business-analysis-benchmark-the-path-to-success.html

Don’t forget to leave your comments below

Top Five Reasons BAs Need a Central Hub of Product Intelligence

Written by John Simpson on September 22, 2009. Posted in Articles.

In the world of product development, and specifically requirements management, you hear a lot about building a “central repository of requirements” or a “single system of record”. But, why does that matter? What problem does that solve? What’s the real value in creating a central hub of product intelligence?

First, let’s define central hub of product intelligence. What are we really talking about? Naturally, we think of the data (aka. artifacts or items) – the ideas, feature requests, requirements, design specifications, analysis documents and reports, release plans, defects, etc. – all the data that explains the scope of the product the team is building. The difference in why we use the word intelligence instead of data is that product intelligence expands beyond the artifacts. It also includes two other important related categories of information that support the social nature of the product development process.

Conversations. There is an ongoing dialogue throughout the product development lifecycle. Customers provide feedback. Analysts capture insights. Teams discuss requirements. Managers communicate decisions. Organizations make commitments. By including the conversations in context to the requirements and other data, your team will have the complete story of what customers need and understand the discussion as to how your team arrived at the requirements you have. The context is huge. Without context, you have higher risk of misinterpretation and defects later on.

Relationships. Often referred to as traceability (the upstream and downstream relationships between requirements and other items), the links between the data and the people who own the data are important for understanding all the dependencies, and creating a dynamic environment where you can intelligently manage and communicate changes when they occur. As a practical example, for developers working on detailed functional requirements, having the visibility to look upstream to the high-level business requirements and original feedback from the customer is huge in providing full context to what they’re on the hook to build.

Why This Matters

There are many reasons, but let’s look at these top five.

Information silos kill productivity – 42% of employees accidentally use the wrong information at least once a week.
Employees and information are fluid – they flow in and out of teams and projects constantly – what info gets lost in transition?
Employees spend 25% of their time just looking for information.
Employees waste 20 minutes or more each day recreating information that already exists.
The total information we’re inundated with grows 66% every year, so this problem will only get bigger over time.

Unproductive Stat of the Day. “It’s estimated that employees at U.S. companies waste over 5 billion unproductive hours annually just looking for information.”
– Searching Kills Employee Productivity Blog

It’s such a simple concept – capture all the relevant product intelligence in one place. Wow, that’s a breakthrough idea, right? The reality is that it’s difficult to eliminate this problem completely; it affects every organization on some level. We’ve worked at start-ups with 10 people in the same office and Fortune 100 companies with 75,000+ employees worldwide, and it exists at both. The question isn’t whether it’s an issue in your company. The more important question is, “What’s the full impact it’s having on your team and their productivity, and could a better solution make a significant difference?”

Solutions range from using back of the napkin/whiteboard to Word/Excel documents to Wikis to specialized requirements management software. You may use them all; we do. The solutions you choose will depend on your organization and the complexity of the products that you’re building. One of the decision criteria to use to gauge whether you need specialized software is to determine what degree your team suffers from the Silo Effect. Borrowing from the infamous Cosmopolitan quiz style, use the list of questions below to determine whether your team is at risk.

Take the Silo Effect Quiz

[Yes] [No] – Do you have duplicated sources of data and multiple versions of requirements spreading across your organization like the Swine flu?

[Yes] [No] – Do you have departments that are disconnected and unaware of what the other is doing? Is the right hand talking to the left hand? Be honest!

[Yes] [No] – Do you operate in an industry with compliance standards, where detailed version history and specific requirements documentation are required for approvals?

[Yes] [No] – Do you spend more than 20% of your time hunting around for the latest product information and requirements specs?

[Yes] [No] – Is visibility into the product development process limited for stakeholders? Hint: if you’ve heard or use the term “black box” in a meeting recently, then mark “yes”.

[Yes] [No] – Do you have communication gaps or blind spots related to customer commitments, feature request or other insights into what your customers need?

[Yes] [No] – Do you have frequent transitions of staff in and out of product teams?

[Yes] [No] – Do your business analysts match the 27 points of compatibility with your engineers? Sorry, ignore this one. We got carried away by the style of these quizzes.

In all seriousness, if you answer “yes” to two or more of the first seven questions above, then it’s probably time to evaluate other options to help you eliminate the silos and bring it all together into a central hub that’s accessible, searchable and reportable.

Productivity Gains from Eliminating the Silo Effect

Save time and money that’s wasted searching for information
Reduce costly guesswork, rework and related defects
Eliminate redundant research and duplicate projects
Shorten ramp-up time of new employees to the team
Give complete context to the goals and scope to everyone involved
Improve the mental well-being and sanity of business analysts (it’s not all about your company. You deserve something out of this too, right?)

Keep in mind, that having a central hub of product intelligence isn’t the end-all-be-all solution for fueling innovation. It’s just one capability in a list of many that are required to successfully plan and build products that work. If you have a broken development process, a central hub won’t solve that. If your team doesn’t have the right skill sets, it won’t fix that either. However, what we’ve found over the years is that of the myriad of challenges we face managing product development, bringing all the relevant product intelligence together in a central hub is one of the immediate and practical steps an organization can achieve right away to speed productivity, reduce costs and improve quality.

Moment of Zen: Sometimes the first step is the most valuable one to take!

Don’t forget to leave your comments below

John Simpson, Jama Software: [email protected]