Tag: Requirements

Real Reuse for Requirements

Written by Cynthia Low on March 9, 2009. Posted in Articles. 2 Comments on Real Reuse for Requirements

A telecommunications company in a hotly competitive market needs to deliver the next generation of cell phone to its customers quickly, and at the lowest possible cost. The company wants to adopt a baseline set of requirements for the next generation project, but must make necessary modifications to leap ahead of the competition.

An automotive supplier must produce embedded software components consistently and reliably for its OEM clients. To do so, the supplier’s development process must account for the slight variations required by each manufacturer.

Requirements reuse provides organizations, like those illustrated in the scenarios above, with the unique ability to share a requirement across projects without absorbing unnecessary duplication of artifacts within a repository. This is a critical capability that accelerates time to market and cuts development costs. Shared requirements can either track to the ongoing change made by the author or they can remain static if the needs of the project dictate. Further, change to a shared requirement can be made by anyone and the system handles the branching and evolution of that requirement appropriately.

The concept of reuse is a familiar notion within the software development realm, but less common when considered in the field of requirements management. There are various definitions and use cases which must be taken into consideration when implementing a solution to address requirements reuse.

This whitepaper discusses the elements that make up a requirement and establishes common understanding of how requirements evolve, how that evolution is retained, and how organizations can reuse requirements to speed business innovation, reduce complexity and control costs.

Dissecting a Requirement

To understand the concept of requirements reuse, we must first look at the various parts of a requirement: data, metadata and relationships.

Data
Describes an object, and is relevant to the object itself. An example of data may be a summary or description of a requirement.

Metadata
This is data about the data, which aids in organizing or using the object within a process. It typically describes the current state of the object, and has the same scope as the data itself. For instance, metadata may describe the State/Stage within a requirement workflow (i.e., Approved, Rejected, Satisfied, and Tested).

Relationships
This characteristic of a requirement allows you to model:

structure (i.e., Consists Of, Includes);
history (i.e., Revision Of, Derived From);
conceptual links or traces (i.e., Satisfies);
references (i.e., Defined By, Decomposes To);
security (i.e., Authorized By, Enables).

Any given requirement can have information in each of the data, metadata and relationships categories. When requirements are reused, any or all of the information can also be reused.

An organization’s chosen requirements management tool needs to have an underlying architecture and the user capabilities that support the strategic level of reuse dictated by the demands of the organization. Since reuse can occur at a number of different levels by leveraging the data, metadata and relationship elements of a requirement, flexibility is also critical to solving the reuse challenge.

History, Versions and Baselines

When implementing a complex reuse scenario, or even a system where requirements persist release after release, one must be able to identify significant points in that requirement’s evolution. In the development world, these significant points are called “versions.” This term may mean different things to different people, so we will begin with a definition of the term “version” as it applies to requirements reuse and show how it relates to similar terms like history, baselines and milestones.

Consider a system where requirements are captured within requirements documents but are stored as individual items within the repository.

History is the term used to describe the audit trail for an individual item or requirement. All changes made to the item, whether it is to data, metadata or its relationships are captured in its history. History answers to the who, when and what questions with respect to changes to that item.

Version represents a meaningful point in an individual item’s history. Not all changes to an item are significant and warrant a new version of the item. For example, the reassignment of a requirement from Nigel to Julia would not require a specific version identifier. The change is recorded to the item’s history, but a new version is not created.

Baseline is a very similar concept to version but has a much different scope. Individual items are often organized into groups or sets. In the requirements management domain these sets are called documents and a baseline is a meaningful point in a document’s history. Some organizations use a slightly different definition for baseline. Rather than being a snapshot in time for a given document, a baseline, as defined here in the context of requirements reuse, is a goal to work towards. For the purposes of this discussion we will call the goal-oriented baseline a milestone in order to distinguish between the two.

Requirements management claims to allow for the versioning of individual requirements. Many tools support versioning by way of cloning or copying the entire requirement. Even fewer solutions relate the copy to the original requirement.

Although related, versioning and reuse are not the same. The concepts of versioning are often confused with that of reuse. In the next section, we will explore various reuse scenarios to illustrate the differences (and the benefits) of versioning and reuse.

Reuse or Not Reuse? – The Many Flavors of Requirements Reuse

Requirements Reuse without Reuse – Share

The ability to share an item between projects, documents or other work efforts could be considered a form of reuse. Under this definition all of the projects that are sharing the item see, and can possibly even contribute to, the evolution of the item. The metadata on the item is shared as are all the relationships and the data.

This is not real reuse. I question whether to call this reuse at all, but it is included here for completeness.

Requirements Reuse without Heritage – Copy

As mentioned previously, copying an object from one place to another can also be considered a form of reuse. In fact, this is the form of reuse that Microsoft Word (or any other non-Requirements Management tool) supports. When an analyst opens a document, selects some content and performs a copy/paste gesture into another document, they are reusing that content for a new purpose. This form of reuse has no knowledge of heritage or “where did I come from” and of course changes in one document have no impact on changes in the other. In fact, changes are completely independent and one document has no knowledge that change occurred in the other, let alone what the change might have been.

This is also not real reuse. Any flavor of reuse must minimally include a pointer to where the original content came from.

Requirements Reuse with Heritage

Given the above scenarios, let us assume you can answer the “where did I come from” question. Augmenting the copy with the pointer back to its origin provides several options for reuse. It is the manner in which this link is leveraged that will differentiate each of the following reuse models. Most RM tools available today have some notion of links or relationships – if not at the individual requirement level, at the document level. Document level links are better than nothing, but they are not very powerful. In the long run, they don’t really answer the traceability question in sufficient detail to be meaningful.

Having a link to an item’s origin is the start of real reuse though it is certainly not the end.

Requirements Reuse with Change Notification

In this situation, a requirement and all related information (data, metadata and relationships), is reused in its entirety. Project state determines the state of the requirements at the time of reuse, and any change to requirements in a reuse scenario causes a ripple effect, flagging all artifacts related to those requirements as suspect.

Requirements Reuse with Change Control

Reuse with Change Control is similar to Reuse with Change Notification in that data, metadata and relationships are reused in their entirety. This seems, and in fact is, the same as the Share topic discussed above, however, there is one significant difference; the two projects sharing the same requirement only share it until the point in time where one project needs to change it. When the information changes a new version/branch is created and only items referencing that new version are declared suspect. All other projects or documents are unaffected.

Requirements Reuse with Annotations

In the two reuse paradigms above, the requirements and related information (data, metadata, and relationships) are reused in their entirety. In Reuse with Annotations, only some of the information belonging to a requirement is identified as a candidate for sharing and reuse. The rest of the information is specific to the project or document. The shared information is held in the repository while the other information belongs to the project or document reference. Each instance of the requirement being reused has its own metadata and relationships. The project or document state is, or can be, independent of the state of the requirements that are contained within it. New versions of the requirement are automatically created when the shared information in the repository is changed. These changes that trigger new revisions can suspect other references, as well as other items in the system, by the ripple effect of that change. For example, changes to requirements may affect test cases or functional specifications downstream.

Once you have project or document independence in terms of the metadata, you have the ability to model both a dynamic (share) and static (reuse) form of reuse at the same time. The project manager or analyst decides if they want to remain consistent with the evolving requirement in a dynamic way or if they want to lock the requirement down such that the impact of change does not affect their project.

Requirements Reuse with Annotations and Change Management

Applying change and configuration management paradigms onto the requirements management discipline in a single integrated and traceable solution can bring the power of reuse to a new level. By incorporating a process on top of reuse and controlling how and when requirements can be modified and reused enables you to reap these benefits without unnecessarily branching and versioning objects unless it is authorized and appropriate to do so. Requests for Change (RFCs) come in, get filtered and are directed by various review boards. Some of these RFCs get approved and assigned to users to affect the requested changes. Ideally, this change management process can define what types of changes can be made; whether it is modification, branching, applying a baseline or other gestures. Only when an approved RFC is associated with a requirement can an analyst modify the requirement, causing the system to version and branch accordingly, and notifying the related constituents appropriately.

There are clearly, additional reuse models that are not described herein – Component level reuse, documents reuse and various combinations of these with annotations and change management for example. This paper provides only a sampling. The business needs and strategic goals within the group, business unit or business as a whole will help determine which model is most effective for the project or organization.

Is Requirements Reuse Right For Your Organization?

Requirements reuse is not for everyone. There is a broad spectrum of need in terms of requirements management tooling in the market today, and organizations first need to know where they lie on the requirements maturity curve.

¹ The requirements maturity curve is not really a curve at all but a measurement of the current process and tools used and/or needed within an organization when it comes to requirements management. As organizations evolve along the curve, the need for more capabilities – such as change management, process and workflow, traceability, reuse, etc. – within their requirements management framework exists.

Many companies are still in the infancy of requirements management. They have not yet adopted a requirements management tool, and are currently using business productivity applications such as Microsoft Word or Microsoft Excel to capture and track requirements. They may look for capabilities such as ease of document import, rich text support, and downstream traceability to ease business adoption. These organizations are not yet at a point of requirements sophistication where reuse support is necessary – or maybe they are but have not found a tool to support their needs.

However, if an organization has progressed on the maturity curve with respect to requirements management, and is managing multiple projects and thousands of requirements in parallel and seeking to reduce complexity, lower cost of development, and shorten innovation cycles, then requirements reuse is a concept that should be investigated.

Let’s face it, regardless of where an organization falls on the curve, reuse in its most basic form will provide a boost to productivity. Rather than re-writing requirements, copy them and modify them for the needs of each project – you will save keystrokes as well as leverage the structure and organization these requirements were managed under in the past. After all, how many different ways can the requirements for logging in to an application be specified really? Ok, likely quite a number, but within any one organization the need to standardize and streamline application access exists and leveraging requirements from one application to another to provide this similar type of functionality can only be a good thing™ (Martha Stewart).

In any case, concentrate on the problem domain before jumping into the question “is requirements reuse right for me?” What challenges is the organization facing in terms of requirements management? Here is a list of sample questions an organization can ask to determine if reuse is a concept that could be leveraged and if it is, which flavor of reuse is best suited to the need.

Doug Akers is a Product Manager at MKS Inc., (www.mks.com) the global application lifecycle management (ALM) technology leader, that enables software engineering and IT organizations to seamlessly manage their worldwide software development activities. through a single enterprise application, resulting in better global collaboration and higher roductivity. MKS supports customers worldwide with offices across North America, Europe and Asia. Doug Akers can be reached at [email protected]

Business Process; A Thing of Beauty

Written by Suzanne Jane Maxted on March 3, 2009. Posted in Articles.

The English romantic poet John Keats wrote in the poem Ode on a Grecian Urn ‘”Beauty is truth, truth beauty,” – that is all/Ye know on earth, and all ye need to know.’ This article proposes that, by recognising and reflecting on how a business behaves, we can find, cultivate and hone its beauty by clearly seeing the culture and behaviour that will make that business uniquely successful in its chosen field.

The previous articles in this series looked at seeking out good by setting the scene using a business context model, and at finding the truth within a business by understanding what real things exist and are true at any time of the day, however the business behaves, using a business domain model. This article looks at why we model the dynamics of a business and its people.

Unless we can see how the business behaves, it is very hard to understand it. It is therefore important that we can encapsulate what the business does so that we can refine and streamline its behaviour, reduce unnecessary complexity and focus on purifying its business offering. As an analogy, an athlete will develop a process to maximise performance, eliminating all unnecessary activity. There may be a small measure of uniqueness in the process depending on the physical and mental nature and build of the particular athlete, but most athletes will follow a similar process for their sport.

There are two main camps nowadays when choosing a notation for modelling business process. I like to use the Unified Modelling Language (UML) because my business customers tell me that it is easy to pick up and read and because it covers all the types of business modelling that I require (dynamic and static). The Business Process Modelling Notation (BPMN) covers only business behaviour (both notations are owned and managed by the Object Management Group). In addition, many government bodies and industry groups such as the United Nations, the World Customs Organisation and the Telemanagement Forum set standards and industry patterns using the UML.

There is another faction – those who describe the business without a notation – the textual modellers who have the genuine concern that their business people will not like or understand the standard notation.

I have only ever experienced positive feedback on the notation, willingness and enthusiasm from the business and an immediate understanding of a few simple symbols, but, it is our job to create and communicate understanding, not the notation’s job. The notation is simply a language with a ‘dictionary’ and some ‘grammar’ rules. It is our job to ask all the right questions in the workshop (remembering we should always model with the business), to apply logic to a number of jumbled verbal descriptions of what is going on and to label each model element in a meaningful way in order to communicate the understanding reached. Otherwise the business will not understand the result! It is the combination of analytical skill and of the UML notation which won the following accolade. Recently during a domain modelling session (please see the article “The Importance of Business Domain Modelling“), a fellow business analyst, new to the UML, told me that he had looked down to think about something, then had looked back up at the whiteboard and exclaimed to himself how well the entire discussion had been recorded in a matter of seconds.

Most business analysts are familiar with modelling the business process at some level. If we can answer the question “what happens next?” then we are dealing with a dynamic view of the world, i.e. depicting the behaviour and activity of the business area of interest. For example, the following (simplified) UML activity model of an outdated UK government business process to do with the international trade of food, specifies the business activity requiring automated support.

Note that a business process always has a starting point, a finishing point and directions on where to go when there are several paths to choose from. These are three of the most frequent review comments I make. Apply rigour and logic! For instance, I can only trade goods if a certificate was issued. Also note that the activity swimlanes (Goods Trader and Certification above) can be derived from the business context model (please see the article “The Business Context Model: As Good as it Gets“) by reusing the actors and business services or areas of interest already identified. The most frequent review comment I make is about the words used to name an activity. Each element in any model must be labelled in a meaningful way. I often see activities labelled like this – “Do Administration” or worse “Enter Data”. These have no meaningful business goal and therefore we cannot hope for good understanding.

Incidentally, it is useful to model at a higher level as we learn about the business; the business use case model is an ideal way to model disjointed business processes that do not logically flow one to another. For example, in international trade, we might identify the processes that are important to our piece of work in the following way, perhaps including a description (in a good modelling tool of course) before we model each process. They should be named to express an important result of value to the business or a major goal. We could even use the strategic business objective as the business use case name.

A business use case is also a useful container for business policies, business rules and constraints which can later be inherited by any software specified.

While some people think that specifying software requirements is the only aim of a business analyst, my view is that this activity should be regarded as a possible end goal depending on the findings of analysing the business. While the focus of this series is on business analysis, I will diverge a little to help refocus our attention on the business when we do step further into software specification i.e. to specify structured functional software requirements as system use cases (because a use case describes a single interaction between a user and a system that meets a goal of the user). There is misunderstanding about why we have use cases. Briefly, a system use case exists to partially or wholly automate and support a business activity in a business process. Therefore, we should not invent use cases from thin air. They should be derived. I have just read an article giving guidance on how to choose whether to model use cases or business process. I claim that we cannot know which use cases we need without studying the business process they are there to support. Otherwise, it’s like administering medicine without knowing what’s wrong with the patient.

How do we derive use cases? By studying the current behaviour of the business and improving it to a more desired state and then by looking at which activities we can enhance and support further. Please reference the Capability Maturity Model Integration [CMMI] which is an open framework for business process improvement describing five levels of business maturity: Level One is otherwise known as the ‘Beast’, and we might nickname Level Five as ‘Beauty‘. This begs the question – how do we know when we have found a system use case? The answer is when the goals of the business process are understood. What I mean is that we must model goal focused activities and those goals, once recognised, will guide us in informatively naming those activities in Verb + Noun format. When we understand the goal we have a system use case – possibly with the same name. If we don’t understand the goal of an activity, then we must look closer, like we do when showing a bee on a flower to a child – what is the bee doing and why? It may be that the activity identified is too ‘big’ or too ‘small’ and we need to ask many more questions.

Only by deriving use cases from a good logically thought out business activity model can we be sure that our software requirements analysis will be fit for purpose. How else would we know? By writing down the wish list of our business people, hoping that everyone can remember exactly what they said in the requirements meetings so that the 300 pages of free text that resulted are not subject to an endless round of revision? In addition, praying that the statements made can act, in a timely manner, as an accurate specification that really does meet the subset of business goals and objectives assigned to the piece of work from the overall business strategy?

Many business process modellers like to model in ‘layers’ and I am often asked how many layers one should model and what level of detail is required at each level. Some industry standards also model in layers, such as the Telemanagement Forum’s eTOM business process model. My preference is not to layer the business process, because I want the model to be public and exposed, say on my business owner’s wall, and I want the model to be useful as a focus for meetings and discussions. This means that it must fit on one page if printed! I have often seen four walls completely covered by a single layer process, or layers upon layers of business process never used again after the model is “completed” – incidentally the model can never be completed in my book. It is really a judgement for each modeller to make depending on their piece of work, but I prefer a single layer with exceptions modelled on further pages so that I can keep the main process on one page (“main” = what happens most of the time with exception activities shown to indicate when something goes wrong). This may mean that I must keep the goal of each activity quite ‘big’.

Of course, the best businesses are never complacent, always proactively striving for enduring beauty: measuring and optimising business objectives and activities; and visualising the business economics (cost, revenue, benefits). Therefore a model of the business process can never be complete – it is a snapshot of an ever evolving set of activities.

With a smoother running process, we can focus our attention on what really counts – the value chain; designing and pricing products and services. It can be a painful realisation when we know we must actively go looking for inefficiencies in our daily business life. After all, beauty is pain, so the saying goes.

ITIL for BAs – Part VIII; What is Design?

Written by Terry Longo on February 24, 2009. Posted in Articles.

A colleague of mine who is much wiser than I (that could be pretty much anyone!) defined “design” as “the art of tradeoffs”.

It is easy to “design” an IT solution for 100% availability, more than enough capacity, extremely secure, with all the functionality currently desired, etc. – and such a design would surely meet business needs! But in most cases such designs are neither practical nor feasible and are thus empty exercises. True design replaces thoughtless overkill with a prioritization of the dimensions of a solution in a way that reflects the solution’s intent. That prioritization informs tradeoff decisions driven by the realities of cost and schedule.

In earlier posts I had discussed ITIL’s general coverage of Quality of Service (QoS) requirements. In ITIL V3, the Service Design book covers five specific QoS-related processes that should be considered during design. (The book also covers Service Catalog Management and Service Level Management, which we discussed earlier). During elicitation, analysis, and solution investigation, it is quite important for the BA to engage IT, through these processes, to ensure that

those QoS characteristics are properly prioritized relative to the solution’s desired business outcome (not just the business requirements, but the outcomes that ought to be realized by meeting those requirements), and
tradeoffs between these various QoS requirements, functional scope, cost, schedule, and risk are rigorously rationalized

Capacity Management ensures “that cost-justifiable IT capacity in all areas of IT always exists and is matched to the current and future agreed needs of the business, in a timely manner”. The consideration of “current and future needs” is at the level of specific applications and solutions as well as the overall IT infrastructure and organization itself (e.g., the possibility of mergers and acquisitions).

Availability Management ensures “that the level of availability delivered in all services is matched to or exceeds the current and future agreed needs of the business, in a cost-effective manner.”

IT Service Continuity Management supports “the overall Business Continuity Management process by ensuring that the required IT technical and service facilities (including computer systems, networks, applications, data repositories, communications, environment, technical support and Service Desk) can be resumed within required, and agreed, business timescales.”

Information Security Management seeks to “align IT security with business security and ensure that information security is effectively managed in all service and Service Management activities.”

Supplier Management’s goal is “to manage suppliers and the services they supply, to provide seamless quality of IT Service to the business, ensuring value for money is obtained.”

ITIL V3 defines a “manager” role for each of the above processes. The more mature these processes and roles are in IT, the more IT is able to participate effectively with BA in

requirements elicitation and analysis
negotiation (since there will undoubtedly be times when the business asks for more than IT is presently capable of delivering)
solution rationalization

Furthermore, IT in and of itself is not in a position to make tradeoff decisions but needs the BA’s involvement in and knowledge of the requirements and desired business outcomes, in order to make those tradeoffs.

There is of course much more to design than is covered here, such as designing for manageability and supportability, planning the solution’s retirement, etc., and the Service Design book covers all of that and more.

The key takeaway from today’s post is (a) QoS requirements can and should be reflected in the IT’s organizational structure and capabilities and (b) omitting consideration of these QoS characteristics can open the business to significant risks.

How mature is your IT organization with respect to these design activities? Do you and your fellow BAs engage IT early on in the requirements process? Are there past cases where in retrospect that did not happen but should have?

Please feel free to share your comments with your fellow readers.

Enterprise View of the Business Analyst Role

Written by Cynthia Low on February 24, 2009. Posted in Articles. 1 Comment on Enterprise View of the Business Analyst Role

BAs Tend to Have a Narrow Focus on Project Related Work

All too often, the BA is unable to focus upon the right areas during a project due to a lack of enterprise analysis prior to the project. Because of this lack, the BA is forced to do requirements elicitation at too many levels at once rather than having focused requirements analysis at the business level leading to requirements elicitation and subsequent analysis at the functional level. This leads to several dangers.

Danger #1

The BA is put behind the curve from the beginning of the project.

If there has not been sufficient elicitation and analysis effort at the business level before the project, the BA is trying to define the business level requirements while simultaneously building the functional and system level requirements that will deliver/support those business requirements. Most of us have been in projects like this and we know that the pain level is high.

Danger #2

The BA is very likely to make discoveries during the project that should radically redefine the project; however, promises have been made and no one wants to explain why this was not anticipated. This leads to projects that deliver what they promised but are perceived as unsuccessful because expectations have changed during the project. One solution is to manage expectations; another is a better use of the change control process.

A Wider and More Appropriate Focus

The Business Analyst’s Body of Knowledge (BABOK) v1.6 has a visual in section 1.6.1 (shown below) that shows the relationship between the knowledge areas. I find the picture is effective in conveying a message that the real role of the business analyst is in project related requirements activities.

One way to look at the BA role is to view Enterprise Analysis as encompassing the other BA activities shown in the BABOK. If you take that view, then the BA has a much clearer set of duties and activities before, during and after any project activity.

Using Enterprise Analysis as the Driver

The following graphic allows us to look at the BA’s role more holistically.

If we look at the role of the business analyst as primarily enterprise focused, we can use distinct phases leading from opportunity identification to solution definition to development to implementation and finally to the analysis of new threats/opportunities surfaced from the solution’s existence. This allows greater clarity in the business analyst’s role and deliverables.

Strategic Phase (the first column in the picture)

Clearly there is (or should be) a phase where the business analyst is working with business management to create and maintain the business architecture, identify opportunities to pursue, and develop a portfolio or projects from which business management selects those most beneficial to the long-term goals of the organization. These deliverables are listed in the BABOK as associated with Enterprise Analysis (EA).

The BA is definitely using all the project management fundamentals here, but the objective is not to produce a specific new application or process. The focus here is to act as a consultant/support arm to the business management so that opportunities can be identified, explored and selected or deselected. I find that most of my clients have too many projects going at once. In addition, many of these projects have conflicting goals and measurements. We, the BAs, have an opportunity at this stage to establish our credentials as a business partner by helping the business management define a portfolio in which projects are prioritized and staged to maximize business benefit. This would also have additional benefits to organizations such as HR and IT that are stretched too thin under the current approach.

This strategic phase is where the BA has the opportunity to elicit and analyze the business requirements so that the portfolio decisions can be made as to which projects are worth pursuing. In addition, the BA has the opportunity to include parties who will be affected by any projects initiated from this phase. This would include, but not be limited to, groups such as project management, quality assurance, and training

The BA at this point should be producing a set of deliverables some of which are listed below. We use the balance as the symbol in the list to reiterate that each is a narrowing of focus and more detailed analysis of a subset of the deliverable which preceded it. These deliverables include:

A set of opportunities from which management decides those to be pursued,
For those selected opportunities, the BA develops alternative solutions with associated trade-offs. Management decides which alternatives to pursue, if any.
For selected alternatives, the BA would be doing a detailed analysis that will be the business case for projects to be done. This will include the business level requirements that will be addressed by specific projects.

Project Phase (middle column)

This phase has received the most attention in the general literature and this is not meant to be a complete coverage of the phase. The intent here is to show how the usage of the strategic and operational phases improves the project phase.

The strategic phase leads to project work. In the project phase, a set of selected business requirements should be used as the base to initiate the requirements effort at the next lower levels. A key point that I am trying to emphasize in this document, however, is that the likelihood of this phase being successful is substantially improved if the business analyst has had the opportunity to produce those products identified in the strategic phase.

Similar to the strategic phase, the BA’s deliverables during the project tend to build upon each other. These include, but are not limited to:

Testing/Acceptance criteria for the business requirements being addressed by this project.
Functional and non-functional requirements that need to be accomplished to support the business requirements.
Trade-offs between different approaches for project delivery
Test strategies that will be used during the project to demonstrate that requirements have been delivered.

Frequently, there has not been sufficient work done in the strategic phase (i.e. the EA work has not been done). If so, the business analyst must retro-fit that work into the project. This puts us right into Dangers 1 & 2, identified earlier. Since we have already launched the project and committed to a delivery/completion date, the business analyst doesn’t have the time needed to produce those work products with enough rigor. Worse yet, the project manager who has been driving the planning and execution efforts based upon the approved project scope will be frustrated when/if the business analyst’s detailed work shows that the project should be redefined.

Operational Phase

In any case, a solution is eventually delivered. Once any solution is in place, the BA enters a new analytic phase. The solution, by its simple existence, opens up new ideas. Once people are dealing with the solution, they start thinking about what could be. This will include high level and low level ideas.

High-level

These will be a mixture of threats and opportunities that the BA should identify by working with all levels of the organization. These ideas can be brought to the attention of senior management and becoming input to the strategic phase.

Low-level

No solution is ever complete or perfect. The BA, working with the solution users and customers, can identify a set of improvements, fixes and general changes that will allow the next version of the solution.

Closing the Loop

The BA needs to be looking at a lifecycle which starts before and lives after the project. We can better acknowledge this by adding the strategic and operational phases to the view of our work. It also institutes a feedback loop to that life cycle which will allow us to establish and build upon the role of BA as a consultant/business partner.

John Slack is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. John has over 30 years of experience in business development, project management, business analysis, and professional development. For the past decade he has focused his time on a mixture of active project management and analysis of business operations as well as the development of training for project management and business analysis. His projects have ranged from the retail to high tech sectors including the planning and rollout of business strategy for companies such as Digital Equipment Corp and Intel, to the development and rollout of software applications for companies such as DirectTV, Motorola and American Airlines. 02/09

Harness the Power of the PM/BA Partnership

Written by Cynthia Low on February 17, 2009. Posted in Articles. 1 Comment on Harness the Power of the PM/BA Partnership

Projects play an essential role in the growth and survival of organizations today. It is through projects that we create value in the form of improved business processes and new products and services in response to changes in the business environment. Since data and information are the lifeblood of virtually all business practices, projects with significant IT components are often the key mechanism used to turn an organization’s vision and strategy into reality. Executives have their eye on the project portfolio to ensure that they: (1) invest in the right mix of projects, (2) optimize their resources, (3) develop expert capabilities to deliver flawlessly, and ultimately, (4) capture the expected added value to the business. In the 21^stcentury we are bombarded with constant change brought about by the Internet, the global economy and the prevalent use of technology. As a result, there appears to be a never-ending demand for new business solutions supported by IT products and services. Executives across the spectrum are adopting the practices of superior project management and business analysis to increase the value projects bring to their organizations.

The Project Performance Partnership

In the spirit of high-performing teams, project managers align themselves with professional business analysts, expert technologists, and business visionaries to understand business problems or new opportunities, and determine the most appropriate, cost-effective, fastest time to market, and innovative solutions. As this core team forms, a project performance partnership emerges that rivals the world’s great teams, (e.g., tiger teams, special operations teams, professional sports teams, parametric teams). At the center of the team is the dynamic twosome: the project manager and the business analyst. The project manager keeps an eye on the management of the project, ensuring the project delivers on time, on budget and with the full scope of the requirements met. While the business analyst focuses on management of the business need, business requirements, and expected business benefits. The wise project manager welcomes this teaming trend, understanding that inadequate information relating to business needs leads to poor estimates, and makes time and cost management virtually impossible.

Business analysis and project management have become central business management competencies of the 21^st century. These competencies are essential because requirements play a vital role in engineering business solutions, and projects are essential to organizational success. In addition, organizations are realizing that the reasons projects fail are almost always tied to poor requirements and ineffective project management. (The Standish Group International, 1994-2006). The table below depicts the resolution of 30,000 applications projects in large, medium, and small cross-industry U.S. companies tested by the Standish Group from 1994 to 2006.¹³

Year	Successful Projects	Failed Projects	Challenged Projects
2006	35%	19%	46%
2004	29%	18%	53%
2000	28%	23%	49%
1998	26%	28%	44%
1996	27%	40%	33%
1994	16%	31%	53%

Source: The Standish Group Project Resolution History, CHAOS Research Reports (1994–2006)

Clearly there has been a steady improvement in project performance since 1994. According to the Standish reports, the reasons for the overall improvement include: smaller projects (the average cost of a project had been downsized more than half by 2001); better skilled project managers; and better methods and tools to manage changes. The Standish Group continues to recommend minimizing project scope, reducing project resources, and downsizing timelines to improve project success. The Standish Group also predicts that the number of critical projects wills double each year; therefore, we must continue to work vigilantly to improve project performance, paying particular attention to the elements it calls the Recipe for Project Success: The CHAOS Ten, which are listed here grouped by category. Notice that many of these elements relate to business analysis and the remaining are about better project management.

Recipe for Project Success: The CHAOS Ten

Project Management	Business Analysis
Executive support Experienced project managers Standard infrastructure Formal methodology Reliable estimates Small milestones, proper planning, and competent staff	User involvement Clear business objectives Minimized scope Firm basic requirements

It is the project manager who owns the Business Solution Life Cycle, and the business analyst who owns the Systems Requirements Life Cycle, from understanding the business need to ensuring that the delivered solution meets the need and adds value to the bottom line. (See Figure 1, below) For complex 21^stcentury projects, the business analyst has a critical role throughout the Business Solution Development Life Cycle, not simply during the requirements phase. Business requirements analysis differs from traditional information systems analysis because of its focus, which is exclusively on adding value to the business. In particular, project managers rely on business analysts to assist in providing more detailed project objectives; business needs analysis; clear, structured, useable requirements; trade-off analysis; requirement feasibility and risk analysis; and cost-benefit analysis. Poor requirements definition emerges without this key liaison between business and IT departments, resulting in a disconnect between what IT builds and what the business needs.

Figure 1 – Business Solutions Life Cycle Mapped to the Systems Requirement Life Cycle

Combining Disciplines Leads To Success

For organizations to achieve strategies through projects, a strong partnership between the project manager and the business analyst is essential. Indeed, when this partnership exists, and they both embrace the contributions of expert technologists and business visionaries, collaboration, innovation and far superior project performance is realized. For an in-depth discussion of the project manager and business analyst partnership, it is helpful to frame the dialogue in the context of a generic project cycle. Refer to Figure 1 once again, the Business Solution Life Cycle Mapped to the Systems Requirements Life Cycle, to provide context as we examine the nature of the partnership. The diagram shows a sequential development approach, from strategic planning to the business requirements to the delivery of a complete business solution. This is a simplistic model that guides the development process through its typical phases.

Strategic Planning and Enterprise Analysis

Strategic Planning

Strategic planning is the first phase in the Business Solution Life Cycle. During this phase the current state of an enterprise is examined and the desired future state is determined and described by a set of broad goals. The goals are then converted to measurable objectives designed to achieve the strategy.

Project managers and business analysts may not contribute directly to strategic planning activities since it is the responsibility of the senior leadership team. However, senior business analysts and project managers may be asked to conduct market research, benchmark studies or competitive analysis surveys to inform the executive team as input to the strategic planning process. In some organizations, senior business analysts and project managers help plan and facilitate strategic planning sessions. Nevertheless, business analysts and project managers should have a full understanding of the strategic direction of the enterprise to determine how new initiatives fit into the long term strategy and/or mission of the organization, and to help build and manage the business case and other relevant information regarding business opportunities.

Enterprise Analysis

The enterprise analysis phase of the Business Solution Life Cycle consists of the collection of activities for depicting the current and future views of the business to determine the gap in organizational capabilities needed to achieve the business strategies. Enterprise analysis activities then determine new business opportunities to close the gaps.

Enterprise analysis activities begin after the executive team of the organization develops strategic plans and goals. The core activities center on: (1) identifying new business opportunities or solutions to business problems, (2) conducting studies, gathering information and determining the solution approach, (3) developing a business case or project proposal document to recommend a new project to the leadership team for their decision whether to select, prioritize and fund a new project. If the new change initiative is selected, a new project is formed and requirements elicitation and project planning commence.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the enterprise analysis activities.

Deliverables	Description
Business Architecture	The business architecture is the set of artifacts that comprise the documentation about the business.
Feasibility, Benchmark, Competitive Studies	Conducting formal or informal studies prior to proposing a new project helps to discover very important information about the business opportunity.
New Business Opportunities	As an outgrowth of strategic planning, the business analyst and project manager review the results of feasibility, benchmark and competitive analysis studies, and the target business architecture to identify potential solution alternatives to achieve strategic goals.
Business Case	A business case should be developed for all significant change initiatives and capital projects.
Initial Risk Assessment	Once the business case is developed, the project manager and business analyst facilitate a risk management session using the same set of experts.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration to complete the enterprise analysis activities, including:

Conducting feasibility, benchmark and competitive studies
Creating the business case, scope statements, preliminary time and cost estimates
Conducting risk assessment and risk response planning
Establishing project priorities
Managing stakeholders
Getting the right people involved and excited about the potential project
Partnering with senior IT architecture team to create the solution’s “vision”

Requirements and Design

During the requirements and early design phases the business need is discovered, analyzed, documented and validated and the solution concept begins to come into view.

Requirements Elicitation

Requirements are always unclear at the beginning of a project. It is through the process of progressive elaboration that requirements evolve into maturity. Requirements elicitation involves conducting initial requirements gathering sessions with customers, users, and stakeholders to begin the specification process. Requirements gathering techniques include: discovery sessions and workshops, interviews, surveys, prototyping, review of existing system and business documents, and note taking and feedback loops to customers, users, and stakeholders.

Requirements Analysis

Requirements are first stated in simple terms, and are then analyzed and decomposed for clarity. Requirements analysis is the process of structuring requirements information into various categories, evaluating requirements for selected qualities, representing requirements in different forms, deriving detailed requirements from high-level requirements, and negotiating priorities. Requirements analysis also includes the activities to determine required function and performance characteristics, the context of implementation, stakeholder constraints, measures of effectiveness, and validation criteria. Through the analysis process, requirements are decomposed and captured in a combination of textual and graphical formats. Analysis activities include:

Studying requirements feasibility to determine if the requirement is viable technically, operationally, and economically
Trading off requirements to determine the most feasible requirement alternatives
Assessing requirements feasibility by analyzingrequirement risks and constraints and modifying requirements to mitigate identified risks. The goal is to reduce requirement risks through early validation prototyping techniques
Modeling requirements to restate and clarify them. Modeling is accomplished at the appropriate usage, process, or detailed structural level
Deriving additional requirements as more is learned about the business need
Prioritizing requirements to reflect the fact that not all requirements are of equal value to the business. Prioritization may be delineated in terms of critical, high, average, and low priority. Prioritization is essential to determine the level of effort, budget, and time required to provide the highest priority functionality first. Then, perhaps, lower priority needs can be addressed in a later release of the system.

Requirements Specification

Requirement specifications are elaborated from and linked to the structured requirements, providing a repository of requirements with a completed attribute set. Through this process of progressive elaboration, the requirements team often detects areas that are not defined in sufficient detail, which, unless addressed, can lead to uncontrolled changes to requirements. Specification activities involve identifying all the precise attributes of each requirement. The system specification document or database is an output of the requirements analysis process.

Requirements Documentation

Requirements documentation must be clear and concise since it is used by virtually everyone in the project. Transforming graphical requirements into textual form can make them more understandable to non-technical members of the team. Documentation activities involve translating the collective requirements into written requirements specifications and models in terms that are understood by all stakeholders.

Requirements Validation

Requirements validation is the process of evaluating requirement documents, models, and attributes to determine whether they satisfy the business needs and are complete enough that the project team can commence work on solution design and construction. The set of requirements is compared to the original initiating documents (business case, project charter, statement of work) to ensure completeness. Beyond establishing completeness, validation activities include evaluating requirements to ensure that design risks associated with the requirements are minimized before further investment is made in solution development.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the requirement deliverables:

Deliverables	Description
Stakeholder analysis and communication needs	Interviews are conducted with individuals and small groups to find out what business functions must be supported by the new solution.
Elicitation Workshops	Requirements workshops are an efficient way to gather information about the business need from a diverse group of stakeholders.
Surveys	Surveys can provide a valuable tool to collect a large amount of information from an array of stakeholders efficiently and quickly.
Document Reviews	The business analyst and project manager review all existing documentation about the business system, including policies, rules, procedures, regulations, process descriptions.
Test Plan	Typically a document that describes the scope, approach, resources and timing of test activities.
Business Requirements Documentation and Validation	Structured, validated, archived and accessible requirements are the functional and performance needs for the new solution, captured in: documents, tables and matrices, models, graphics, prototypes
Requirements Management Plan	A document that describes how changes to requirements will be allocated, traced and managed.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during requirements activities, including:

Conducting requirements elicitation workshops
Determining the number of iterations of requirements elicitation, specification, and validation
Determining the appropriate life cycle choice (e.g., waterfall, Agile, Spiral)
Developing the project management plan
Conducting trade off analysis for the requirements and solution trade-offs
Balancing the competing demands
Validating requirements
Prototyping
Updating the business case
Planning and facilitating the control gate review, signoff on requirements, and go/no decisions

Solution Construction and Test

During the solution construction and testing, the business analyst and project manager collaborate to ensure changes to requirements are identified, specified, analyzed for impacts to the project (cost, schedule, business value add), and dispositioned appropriately. The goal for both the business analyst and the project manager is to reduce the cost of changes, and welcome changes that add business value. Requirements management activities include: allocating requirements to solution components, tracing requirements throughout system design and development, and managing changes to requirements.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the solution construction and test activities.

Deliverables	Description
Solution Verification and Validation	Validating requirements to provide evidence that the designed solution satisfies the requirements through user involvement in testing, demonstration, and inspection techniques. The final validation step is the user acceptance testing. Verifying requirements to provide evidence that the designed solution satisfies the requirements specification through test, inspection, demonstration, and/or analysis.
Business Policies, Procedures, Rules, Education	For new business solutions, there are almost always changes to business rules, policies, and procedures.
Testing	Including integration, system, and user acceptance testing.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during solution construction and testing phases including:

Developing the test plan and test approach
Validating activities to ensure the solution meets the business requirements (customer reviews, product demonstrations)
Reviewing test results and dispositioning identified defects
Conducting defect root cause analysis and determining the appropriate corrective action
Managing issues
Managing stakeholders
Facilitating the go/no go decision to deliver

Solution Delivery

Planning for the organizational change management that is brought about by the delivery of a new business solution is often partially or even completely overlooked by project teams that are focused mainly on the IT application system. While the technical members of the project team plan and support the implementation of the new application system into the IT environment, the business analyst and project manager are working with the business unit management to bring about the benefits expected from the new business solution by:

Assessing the organizational readiness for change, and planning and supporting a cultural change program;
Assessing the current state of the knowledge and skills resident within the business, determining the knowledge and skills needed to optimize the new business solution, and planning for and supporting the training, retooling and staff acquisition for skill gaps;
Assessing the current state of the organizational structure within the business domain, determining the organizational structure needed to optimize the new business solution, and planning for and supporting the organizational restructuring;
Developing and implement a robust communication campaign to support the organizational change initiative; and
Determining, enlisting and supporting managements’ role in the championing the change.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the solution deployment activities.

Deliverables	Description
Deployment plans	Developing and communicating the plans to implement the new business solution.
Business policies, rules, procedures	Implementation of business policies, procedures, rules, etc.
Education and training	Training of business customers, stakeholders and users to accept and operate the new business solution efficiently.
Post-implementation support	The business analyst and project manager provide support to the business customers, stakeholders and users to help them learn how to operate the new business solution efficiently, and to resolve any issues that arise.
Lessons learned	The business analyst and project manager conduct lessons learned sessions with the project team, the business customers, stakeholders and users, and the technical team to determine what went well, and what needs improvement for future projects.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during solution deployment activities including:

Developing, communicating, and getting approval for the deployment plan
Approach (deploy to all business units or use a phased in)
- Which business units are affected?
- When will the business units be implemented?
- When will training be delivered?
- When will post-implementation support by the core project team end?
Making the decision to move to O&M
Conducting lessons learned sessions

Operations and Maintenance

The business analyst and project manager contribution to the success of the project does not end when the business solution is delivered and operational. There are key responsibilities during Operations and Maintenance (O&M) that must be filled. O&M is the phase in which the system is operated and maintained for the benefit of the business. Maintenance services are provided to prevent and correct defects in the business solution.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the O&M phase.

Deliverables	Description
Solution benefits measurement	The actual business benefits that are realized are captured, analyzed and communicated.
Identification, prioritization, and planning for solution enhancements	Maintenance and enhancements projects are: identified, prioritized by business value, planned, executed
Decision to deactivate	At some point, the solution will need to be replaced. The decision to do so often involves the enterprise analysis activities described above.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during O&M including:

Prioritization of enhancements
Root cause analysis of performance and value attainment issues

Final Words

Gaps in technology, techniques, and tools are not the fundamental reasons why projects fail. Rather, project failure most often stems from a lack of leadership and poor choices made by people. Undeniably, the business analyst and project manager are evolving into strategic project leaders of the future. The key issues are no longer centered on control and management, but rather collaboration, consensus, and leadership. Team leaders develop specialized skills that are used to build high-performing teams. When building software-intensive systems, well managed teams undoubtedly accomplish more work in less time than do poorly managed teams (Bechtold, 1999).

References

Bechtold, R. (1999). Essentials of software project management. Vienna, VA: Management Concepts.
Hadden, R. (2003). Leading culture change in your software organization. Vienna, VA: Management Concepts.
Mooz, H., Forsberg, K., & Cotterman, H. (2003). Communicating project management: The integrated vocabulary of project management and systems engineering. Hoboken, NJ: John Wiley and Sons.
The Standish Group International, Inc., “2007 First Quarter Research Report,” The Standish Group International, Inc. (2006–2007).
The Standish Group International, Inc., “Extreme CHOAS,” The Standish Group International, Inc. (2001), Online at http://www.smallfootprint.com/Portals/0/Standish%20Group%20-%20Extreme%20Chaos%202001.pdf (accessed January 2008).
Stevens, R., Brook, P., Jackson, K., & Arnold, S. (1998). Systems engineering: Coping with complexity. Indianapolis, IN: Pearson Education, Prentice Hall PTR.

Kathleen B. Hass, PMP

is Senior Practice Consultant for Project Management and Business Analysis, and Director at Large and Chapter Governance Committee chair for the International Institute of Business Analysis (http://www.theiiba.org/). She is the author of Managing Complex Projects: A New Model (Management Concepts, October 2008). Since 1973, Management Concepts, headquartered in Vienna, VA, has been a global provider of training, consulting and publications in leadership and management development. Management Concepts is a Gold International Sponsor and an IIBA Endorsed Education Provider For more information, visit http://www.managementconcepts.com/ or call 703 790-9595.