Tag: Lean

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

The Business Analyst’s Requirements Meeting from Hell!

Written by Dana Brownlee on October 6, 2009. Posted in Articles. 3 Comments on The Business Analyst’s Requirements Meeting from Hell!

Secrets to Managing the Difficult Personalities in Your Meetings

Business Analyst Sherry Martin couldn’t stop thinking about her last team meeting as she walked down the hall towards her office. She’s leading a team charged with developing a requirements document for a hot new IT product, and things have not been going well. Slamming her office door behind her, she let out an exasperated scream and looked for something to punch! Her team was driving her absolutely crazy and she channeled Scarlett O’Hara as she proclaimed, “I will never run a meeting like that again!” Her problem in a nutshell boiled down to three really difficult personalities that continually recurred on her team. These personalities were indeed a cancer, not just infecting the team and its results but also spreading throughout the group and infecting individual team members as well.

Sherry needs an antidote… now!

Here’s a little help for Sherry…and for you! Let’s explore these common dysfunctional personalities and take a look at how to effectively manage them.

The Dominator

We’ve all experienced “the dominator” in one way or another. Some people tend to dominate discussion simply because they’re excited and over zealous. These can actually be valuable members of the team if we can find appropriate approaches to harness and manage all that positive energy. Unfortunately, most of us are more familiar with the other type of dominator – the overly aggressive, bullying personality that tramples on others’ comments and may attempt to hijack the meeting completely! Sometimes, these dominators are overly negative (“That’ll never work here!”), and other times they just won’t let anyone else get a word in edgewise. In either case, dominators can certainly sour not just the effectiveness of the meeting but also the morale of the team.

Techniques for Effectively Managing the Dominator

Thank the dominator for the feedback and ask for others’ input (e.g. “Steven, that’s an interesting idea. Let’s see if others have suggestions as well.”)
Reiterate the dominator’s comment, write it visibly for all to see, and then ask for other ideas to complete the list. (e.g. “Steven, it sounds like you’re recommending that we use these three vendors as our short list…is that correct? That’s a great suggestion. Let’s compile a list of several suggestions, then discuss them all. We’ll list your suggestion as “A” on the list. I’d like to get at least three other suggestions from the team. What do others think?”)
Instead of having the group respond to an issue verbally, ask them to take 2 minutes to jot down their idea, issue, or recommendations on a post it instead. Then ask each person to share one comment they wrote.
Suggest the group use the round robin technique (go around the room asking each person to share a comment) and start at the opposite end of the table from the dominator (e.g. “This is such an important issue that I want to be sure I’m getting everyone’s ideas. Let’s do a quick round robin starting with Jill…”)
Call on a few people you haven’t heard from (e.g. “Michael, what are your thoughts on this issue?”)
Take a break and solicit the dominator’s support offline (“Steven, you’ve brought up several key points. I’m hoping to get some of the other team members involved in the discussion to hear their ideas as well. Some members of the group are not as assertive, but I want to be sure we hear from them.”)
Break the group into pairs or triads and let them discuss an issue in those smaller groups before initiating a large group discussion
Gain agreement with your team to use a physical object (e.g. sponge football) to balance discussion. The person holding the football has the floor, and they must toss it to someone else once they make their point.

The Multi-Tasker

Increasingly, we’re seeing more and more multi-taskers in our meetings. Aptly named, they’re the ones whose attention constantly darts between the meeting leader and any number of other tantalizing distractions (e.g. PDA, laptop, reading material, etc.). Indeed, the multi-tasker is physically present but mentally elsewhere.

Techniques for Effectively Managing the Multi-Tasker

Bring the issue up to the group during first few meetings and decide as a group how you want to handle the technology distractions…options may include

Using a “technology drop box” at the front of the meeting room and agreeing to drop it in prior to meeting start
Limiting meeting time to one hour to ensure participants aren’t away for too long
Agreeing on 15 minute technology breaks every hour
Participants bring a buddy to “cover” for them in case they have to step out for a call

Use facilitation techniques that keep participants actively engaged

Round robin
Active questioning
Affinity diagramming
Sub team work
Dot voting
Use a circular or U shape room setup that allows you to easily walk around (and near) various participants quite easily
Agree upon a mild punishment for texting, emailing, etc. during the meeting. One group used a PDA jar and violators had to put in $5 per violation. (Money was later used for team lunches)

The Rambler

The rambler can seriously derail a meeting with their circuitous, protracted, rambling commentary. Oftentimes, the rambling strays into areas bearing little resemblance to the topic at hand. The rambler can not only significantly extend the length of a meeting but also completely alter the meeting content, thereby minimizing the team’s efficiency and effectiveness.

Techniques for Effectively Managing the Rambler

Have a printed agenda (on a flip chart or whiteboard) in the room. When conversation strays off topic, stand up and point to the specific agenda topic to refocus the group.
Include timings for each section of the agenda so you can more easily focus the group on the time allotted for each discussion point. Possibly ask someone on the team to provide a five minute warning before the scheduled end time for each section of the agenda.
Simply raise your hand and interrupt discussion to ask if the conversation is on topic and helping the group reach their goal for the meeting. (“Guys, allow me to step in for a moment to ask whether the vendor discussion is relevant for this particular section of the agenda?”)
Introduce the Parking Lot at the beginning of the meeting and announce that you’ll interrupt discussion to place any off-topic discussion points on the parking lot to help keep the group on track. (“Jill, I realize that you feel strongly about the inventory control issue, but I’m wondering if we should try to resolve that now or could we possibly place it in the parking lot?”) Review all parking lot items at the close of the meeting and assign action items for each.
Assign someone on the team to act as the “rambler police” (use a badge if appropriate). This person is responsible for raising their hand anytime the discussion veers off topic.
Consider using the ELMO technique. ELMO = “Everybody, Let’s Move On!” Whenever anyone in the group feels the group is rambling too much, they’re expected to pick up the ELMO doll in the center of the table.

Don’t forget to leave your comments below

Dana Brownlee is President of Professionalism Matters, Inc. which operates www.meetinggenie.com, an online resource for meeting facilitation tips and instructional DVDs.

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

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].

Requirements Gathering in a Flat World

Written by Darren Levy on September 29, 2009. Posted in Articles.

In his 2005 bestseller The World is Flat, New York Times columnist Thomas Friedman famously proclaimed that advances in global communications technology had essentially rendered the world flat. By this he meant that the massive investment in communications infrastructure that fueled the dot-com bust has, as a virtuous by-product, allowed a new generation of companies to leverage cheaper resources abroad.

And has it ever!

The ubiquity of persistent Internet access has enabled a new generation of companies to leverage resources – be they human or IT-based – wherever they might be physically located. Regardless of how you feel about the political implications of offshore outsourcing, it’s clearly no passing fad.

It wasn’t too long ago that developing software via offshore outsourcing belonged solely to the province of large enterprise organizations. This of course is no longer the case as even the smallest companies have come to rely on distant software development teams in Eastern Europe, former Soviet republics, and Asia. In fact, this ability to instantly tap cheaper development resources and expertise has directly contributed to a burst of innovation, as smaller companies are able to level the playing field with their larger enterprise counterparts.

Yet this opportunity also comes with some thorny strings attached – any short term savings realized can be quickly offset by poor requirements definition and gathering practices. As business analysts well know, clearly articulated software requirements represent the foundation of any successful software project. Indeed, the reason why so many software projects continue to fail is precisely because not enough attention is paid to this critical first step in the software development process.

Communicating and managing software requirements is of course challenging enough even when all your team happens to be situated in the same location. But when working with a distributed team, many of whom don’t even share a common first language, the potential for errors grows considerably. And thus, any savings realized by cheaper resources is suddenly squandered. Worse still, time is wasted, morale suffers, and the project team is forced to shift into “fix-it” mode.

On-Demand Apps Grow Up

When Salesforce.com was founded in 1999 by former Oracle executive Marc Benioff, the notion of applications hosted “off-premise” was still something of a radical idea. At that time, there were still a number of barriers to widespread adoption: application performance, security assurances, and bandwidth constraints, to name but a few.

Just 10 years later, practically every major software category now includes a healthy ecosystem of on-demand solutions. Not only has the supporting infrastructure matured with offerings like Amazon’s EC2 cloud platform – allowing software providers to more easily configure their application in the cloud — but the next generation of on-demand applications are pushing the envelope in terms of what can be delivered through a browser. More and more, these applications feel and act like traditional desktop software. But of course, they can do so much more because they are intrinsically connected. Now, every on-demand application has the potential to become a dynamic collaboration platform that succeeds in bringing all project constituents to the table. And, as more on-demand application developers create and publish their APIs, they can be integrated into other facets of the software development process.

But it’s this idea of connectedness that’s so powerful when it comes to keeping distributed teams marching to the same beat. Business analysts are not just responsible for defining requirements but also for ensuring that they’re properly communicated and correctly applied. While large enterprises might have the luxury of a robust requirements management tool at their disposal that incorporates collaboration (and surprisingly, only a small percentage of these enterprises have adopted these types of solutions), the average small to medium enterprise does not. Instead, most of these companies use some combination of Word, Excel, and email to define and communicate requirements to their development teams. Because these tools are disconnected from one another, the potential for miscommunication is an endless challenge. And when those development resources are located half a world a way, it’s not a question of if something will go wrong but rather when.

So what’s a budget-minded business analyst working with a distributed development team to do?

Requirements Outlook? Mostly Cloudy.

In many respects, business analysts can find inspiration in the latest hype cycle: social media. Social applications like Facebook and Twitter have reshaped our personal dialogue and communications framework. And aspects of these sites will likely transform the way we think about software requirements.

For better or worse, we are in constant communication with our own personal circle of contacts. Anyone who has been part of a software development team understands how important it is to be in regular contact with the rest of the team. From the beginning of a project (i.e., defining use cases) through the implementation phase (i.e., bug tracking), persistent communication is the new Critical Chain. Put another way, when you can’t all be present for the daily stand-up meeting, how do you ensure everyone is on track?

There are three key ways that migrating the requirements gathering process to the Cloud will help business analysts get better results from their distributed development teams:

Collaborate in Real Time, in Context. Email is a terrific communications tool. But it’s asynchronous and often detached from a larger context. This becomes especially problematic when multiple teams are working on different aspects of the same project. By unifying the requirements process in a hosted environment, distributed teams can collaborate in a meaningful way and identify potential problems before they get out of hand.

Visualize the Workflow to Mitigate Language Barriers. One of the most vexing challenges that business analysts face when it comes to working with offshore developers is communicating across multiple languages. There are the obvious spoken language barriers to overcome. But more often it’s the nuance and culture of language that presents the most significant obstacle. Because business and software requirements are technical in nature, employing a visual language to communicate requirements becomes a necessary complement. As traditional requirements gathering tools move to the Cloud, the ability to clearly represent business requirements in a visual manner (i.e., use case scenarios, parking lot diagrams, etc.) will help keep all project constituents on track.

Visibility for All, Across the Entire Requirements Spectrum. No software developer should be an island to themselves. Even though two developers might be working on two discrete and unrelated tasks, it’s still vital that they understand the underlying business requirements that are driving the project. By standardizing the requirements management process in the Cloud, the business analyst can provide all of their team members with the “situational awareness” they need to understand how their software will be used.

In Flat We Trust

The world is indeed becoming flatter by the day. Just as the path of water naturally finds the path of least resistance, free markets will invariably gravitate towards the most cost-efficient resources. However, even with all of Friedman’s optimism regarding the potential rewards of offshore outsourcing, he also goes on to warn us: “In this era of mounting complexity with more people, systems and products entwined in a bewildering web of global networks, explaining is an enormously valuable skill.” In a sense, that is exactly what software requirements are all about: explaining. And explaining becomes all the more important when teams are fragmented by geography, culture, and language.

Don’t forget to leave your comments below

Darren Levy is the founder of GatherSpace.com, a provider of on-demand requirements management solutions based in Los Angeles. Email him at [email protected].

Beyond Requirements Analysis – Enterprise Analysis

Written by Alan S Koch on September 15, 2009. Posted in Articles. 1 Comment on Beyond Requirements Analysis – Enterprise Analysis

“What do your Business Analysts do?”

“They develop and manage project requirements, of course. What else would they do?”

What else indeed!

The BA Body of Knowledge (BABOK®) defines what a professional BA should know and do. Much of it is focused on requirements work – but not all. One of the knowledge areas that takes the BA beyond requirements work is “Enterprise Analysis.”

Enterprise Analysis (EA) encompasses those activities that the job title “Business Analyst” actually points toward: analyzing business processes. The majority of these activities is outside of projects, and in fact, put the BA into the position of recommending and justifying projects.

Enterprise Analysis

Analyzing business processes is indeed a big part of what we do during Requirements Analysis. But that is not the only context where this analysis should be done, and in fact, it is not the most valuable time to do it. In the Enterprise Analysis knowledge area, the BABOK identifies several other contexts in which such analysis should be done.

Activity: Creating and Maintaining the Business Architecture

As the name of this activity implies, “Creating and Maintaining the Business Architecture” is an on-going activity that has as its focus the entire enterprise. The “Business Architecture” is a model of all the business processes that are used throughout the enterprise. It shows how they work and relate to each other.

The net result of this is an understanding that most organizations lack, of how all their moving parts mesh with each other. This broad understanding of the enterprise’s processes becomes the foundation for all of the other responsibilities of the BA. But its bigger value comes in providing every member of the organization with a clear understanding of how his or her department and individual job fits into the bigger picture

Recommending and Justifying Projects

The bulk of the activities described in the Enterprise Analysis knowledge area center around proposing and justifying projects. These are activities that occur in some form or other in any organization. But with the BA’s involvement, they can provide much more value and ensure the organization’s resources are spent on the most valuable projects.

Activity: Conducting Feasibility Studies

Projects are created to solve a problem or to take advantage of an opportunity. It is rare for there to be only one available solution to a problem or opportunity, so part of project initiation involves exploring the alternatives. The BA can provide a valuable service by calling upon his or her understanding of the Business Architecture to analyze the feasibility of a variety of options.

Activity: Determining Project Scope

Scope definition should not be the first step in requirements development; it should be done during the project proposal process. How can the decision-maker(s) approve or disapprove a project without a clear understanding of its boundaries?

Activity: Preparing the Business Case

The business case is the logical argument for embarking on a project. It consists of contrasting the status quo (current situation) with the various options for addressing the problem or opportunity at hand and recommending the most appropriate option. In most cases, these options are being contrasted in terms of money (e.g., “If we spend $x on this project, it will result in $y increased revenue per year”).

Activity: Conducting the Initial Risk Assessment

An important piece of information that the decision-makers need is an understanding of the risks involved in a project. Clearly, you cannot do a complete risk-planning workshop before the project has been initiated (that is part of the Project Planning process). But an initial survey of the project risks can provide the decision-makers with key information.

Activity: Preparing the Decision Package

The BA has no authority to approve or disapprove any project. The people who do have that authority rarely have the time that is necessary to do the requisite research. So, the BA’s role in the decision-making process is to do all of the necessary research, and compile it into a form the decision-makers can use.

Activity: Selecting and Prioritizing Projects

After a project has been approved, it should not be a foregone conclusion that it will begin immediately. Projects must be prioritized against each other so the organization’s resources can be deployed in the most appropriate way. Again, the BA is not the decision-maker, but provides the necessary analysis to the decision-makers.

Project Work beyond Requirements

The last three activities that the BABOK includes under the “Enterprise Analysis” knowledge area are project-related activities that go beyond Requirements Analysis. They continue the theme of Enterprise Analysis by maintaining a broad organizational view of the project.

Activity: Launching New Projects

Here, the BA works with the appropriate people in the organization to ensure that the necessary resources, including the right project manager, are committed to the project. The BA’s unique role in these activities is to focus on the bigger picture of why the project was approved and how it fits into the bigger organizational context. This ensures that the intent of the decision-makers is honored as the project is framed and kicked off.

Activity: Managing Projects for Value

In this activity, the BA works closely with the project manager to ensure the project is tracking toward providing the value that was promised in the business case (above). The BA helps the project manager keep the project’s value proposition on track. And if the assumptions on which the project was approved turn out to be false, the BA can help the decision-makers determine their best response.

Activity: Tracking Project Benefits

In this last activity, the BA closes the loop on the business case (above). The business case proposed making certain investments in order to accrue certain benefits. After the project is over, the actual investments are known, and the actual benefits can be measured. At some appropriate time after deployment, the BA should report back to the decision-makers about how the results of the project compare with the business case. This discussion process will help the organization make better decisions in the future.

Expanding Your Value as a BA

Requirements Analysis is an important way for the BA to provide value to his or her organization. By adding Enterprise Analysis, the BA can dramatically increase his or her value by ensuring that every project fits well into the bigger picture and provides the best possible result to the organization.

Don’t forget to leave your comments below

Alan S. Koch, PMP is a speaker and writer on effective Project Management Methods. He is a certified Project Management Professional and President of ASK Process, Inc, a training and consulting company that helps companies to improve the return on their software investment by focusing on the quality of both their software products and the processes they use to develop them.

Mr. Koch’s 29 years in software development include:14 years designing, developing and maintaining software; five plus years in Quality Assurance (including establishing and managing a QA department); eight years in Software Process Improvement and 10 years in management

Mr. Koch was with the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) for 13 years where he became familiar with the Capability Maturity Model (CMM), earned the authorization to teach the Personal Software Process (PSP) and worked with Watts Humphrey in pilot testing the Team Software Process (TSP).

For more information about Mr. Koch: http://www.ASKProcess.com/experience.html.

This article was originally published in Global Knowledge’s Business Brief newsletter. (www.globalknowledge.com)