Tag: Requirements

In this Edition: Implementing BA, Managing Requirements, Service Management

Written by Cynthia Low on September 2, 2008. Posted in Articles.

Summer tends to become a bit of a habit, doesn’t it? And it’s a habit that’s often hard to kick. But no excuses! We have some articles that we feel sure will provide food for thought and help get you back into the business swing of things. I think you’ll find them a mix of pretty sophisticated business analysis ideas and techniques coupled with some getting the job done in general. Take a read and let us know what you think because that’s what helps us continue to run a website that is for and about you and your profession. And, talking of reading, don’t miss our new Bookstore that we set up just last month. It’s got a wealth of great BA books by leaders in the field.

Implementing Business Analysis; Three Distinct Phases. Victor Teplitzky believes that introducing business analysis to an organization is something that has to be carefully planned if it is to be effective. He write about the three phases involved.
I Don’t Have Time to Manage Requirements; My Project is Late Already! Part II. In the first article in this series, Elizabeth and Richard Larson looked at the framework for requirements management. Here, they discuss the relationship between the requirements management plan and the project management plan.
Random Thoughts on Service Management. Regular blogger Terry Longo gives us his take on service–oriented management and business analysis – and other random BA thoughts.
Labor Day is Here. Publisher, Adam Kahn, is sad that Labor Day 2008 has come and gone and the dying days of summer with it. But he’s also looking forward to winding up to take on everything that business can throw at him in the coming months.

And we hope you had a great summer and that you’re ready for and looking forward to new BA challenges and achievements in the busy days ahead.

I Dont Have Time to Manage Requirements; My Project is Late Already! Part II

Written by Elizabeth Larson on September 2, 2008. Posted in Articles.

Now that we have looked at the framework for requirements management, let’s delve deeper into requirements planning.

The Requirements Management Plan

Planning the business analysis work effort is part of the overall effort to plan the project, and the resulting Requirements Management Plan becomes part of the project management plan. Below is a table with some of the key planning activities, the sub-processes associated with each, and the final deliverables that are produced. As stated earlier, these deliverables are rolled into the requirements management plan, which in turn, is a subsidiary plan within the overall project management plan.

Because of the interrelationship of the project and the product, of the project manager and the business analyst, most of the activities below, while focusing on the product or activities to produce the product, are part of the larger project. The effective project manager, in planning for the whole project, seeks input from a variety of team members to create scope, schedule, and cost baselines. One of these team members is the business analyst, who provides input on the business analysis phase or phases. In other words, the business analyst plans which activities will be needed to define the product requirements completely and correctly. The information from business analysis feeds into the overall project.

Below is a table which expands on the activities in the knowledge area of business analysis planning and monitoring, the processes within the broader tasks, and the key deliverables that are output from these processes.

Exhibit 3 – Requirements Planning Activities and Deliverables

It is helpful to remember that each of these activities and sub-processes should be considered and performed, although not with the same amount of formality. For example, identifying project roles can take place in a formal, facilitated session with cross-functional representation, or it can occur when the project professional informally touches base with a limited number of stakeholders. Likewise, the deliverables may be permanent and stored in a repository or they can be temporary, a by-product of an informal conversation. In the latter example, the deliverable may be produced on a whiteboard and erased at the end of the discussion, kept in notes until the end of the project, or archived indefinitely. What is important is that these decisions be made purposefully and before the execution of business analysis has occurred.

Clarifying Roles

One of the first tasks in requirements planning is completing stakeholder analysis, during which time it is important to clarify the project professional’s role and associated responsibilities. Because of the interrelationship of the project and product, the roles of project manager and business analyst tend to blur in some organizations and on some projects. Here are several considerations to help clarify these two roles:

The difference between the function of managing the project and that of managing both the requirements and the business analysis phase(s). Although the same person can certainly manage both functions, they are different and the associated roles are also different. Skills required and characteristics of effective performance differ for each role, so giving thought to each during stakeholder analysis is important. For example, it is even more important for the project manager than the business analyst to have human resource management skills, and it is even more important for the latter to be an expert facilitator.
The consultative nature of the project professional’s role. In establishing roles and responsibilities it is important to view the project professional as a consultant who makes recommendations, rather than either as an owner or as an order-taker. One of the required skills is the ability to influence without authority. A responsibilities assignment matrix, such as a RACI, can help with this clarification.
The importance of distinguishing between requirements management and product ownership is also critical. We need to remember that managing requirements does not mean owning them. When clients are not available, it is rarely in the best interest of the project to continue without executive and business client support. Since it is the sponsor who has a business problem needing a solution, the sponsor needs to assign people who can define what they want in a timely manner. The project professional can have input and can certainly make recommendations, but the final decisions and acceptance of the requirements need to rest with sponsors. Therefore it is necessary to clarify the sponsor’s role as the ultimate owner, even if they have chosen to designate a day-to-day project owner.
Finally, project professionals need to keep asking why the stated business problem is worth solving and to explain why it’s in the sponsor’s best interest to provide available resources who can define the requirements that will solve the business problem.

The next article in the series explores the consultative nature of the project professional and provides tips for negotiating to ensure there is enough project time for requirements management.

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com.

I Dont Have Time to Manage Requirements; My Project is Late Already!

Written by Cynthia Low on August 15, 2008. Posted in Articles. 1 Comment on I Dont Have Time to Manage Requirements; My Project is Late Already!

An Overview

For those of us who have been given imposed deadlines that often seem arbitrary and unreasonable, managing requirements is one of the last things we want to do on a project. We worry about getting the product built and tested as best as we can. And we feel fortunate to gather any requirements at all. However the lack of a well-managed requirements process can lead to common project issues, such as scope creep, cost overruns, and products that are not used. Yet many project professionals skim over this important part of the project and rush to design and build the end product.

This is the first in a series of articles providing an overview of requirements management. It emphasizes that the discipline of requirements management dovetails with that of project management, and discusses the relationship between the two disciplines. It describes the requirements framework and associated knowledge areas. In addition, it details the activities in requirements planning, describes components of a Requirements Management Plan, and explains how to negotiate for the use of requirements management tools, such as the Requirements Traceability Matrix to “get the project done on time.”

The Case Against Requirements Management

It is not uncommon to hear project professionals and team members rationalize about why requirements management is not necessary. We commonly hear these types of statements:

“I don’t have time to manage their requirements. I’m feeling enough pressure to get the project done by the deadline, which has already been dictated. My team needs to get going quickly if we have a hope of meeting the date.”
“Our business customers don’t fully understand their requirements. We could spend months spinning our wheels without nailing them down. I doubt if all the details will emerge until after we implement!”
“My clients are not available. I schedule meetings only to have them cancelled at the last minute. They don’t have time. They’re too busy on their own work to spend time in requirements meetings. And my clients, the good ones, are working on other projects, their day-to-day jobs, fighting fires, and their own issues.”
“Managing requirements, when they’re just going to change, is a waste of time and resources. It creates a bureaucracy. It uses resources that could be more productive on other tasks, such as actually getting the project done!”
“They don’t think we’re productive unless we’re building the end product. They don’t want to pay for us to spend a lot of time in requirements meetings or doing paperwork!”

For many requirements management equates to bureaucracy and “paperwork,” because the discipline has not yet stabilized and evolved. The International Institute of Business Analysis (IIBA) in their body of knowledge, the Business Analysis Body of Knowledge (BABOK), establishes a requirements framework for the discipline of requirements management.

This series of articles discusses requirements management, emphasizing the planning and the requirements management plan.

Requirements Management Overview

The Project Management Institute (PMI, 2004, p 111), the International Institute of Business Analysis (IIBA, 2006, p 9) and the Institute for Electrical and Electronics Engineers (IEEE, 1990, Standard 610) all define a requirement as a condition or capability needed to solve a problem or achieve an objective that must be met by a system or system component to satisfy a contract, standard, or specification.

Requirements management includes the planning, monitoring, analyzing, communicating, and managing of those requirements. The output from requirements management is a requirements management plan, which on large projects can be a formal set of documents with many subsidiary plans. Examples of subsidiary documents are a business analysis communication plan, metrics for measuring business analysis work, key deliverables and estimates for the business analysis work effort, and many more. On smaller efforts this requirements management plan can be an informal roadmap. In either case, it is subsidiary to the overall project management plan, created, executed, controlled, and updated by the project manager.

Below is an exhibit showing the relationship between the requirements management plan and example set of plans that are subsidiary to the integrated project management plan. As indicated, the requirements management plan is incorporated into the project management plan, and all the subsidiary requirements management plans are incorporated into the subsidiary plans, within the overall project management plan. We will have a deeper look at requirements planning later in this series.

Exhibit 1: The Requirements Management Plan in Relation to Project Management

If care isn’t given to planning business analysis activities, the entire project could go awry. Lack of requirements management is one of the biggest reasons why 60% of project defects are due to requirements and almost half of the project budget is spent reworking requirements defects. (Software Engineering Institute (SEI’s) Square Project updated 5/12/05).

In the upcoming articles of the series, we’re going to focus on requirements planning. But, it is also important to understand the overall requirements management framework, which is based on the BABOK. The remaining parts of the series includes: Part II – BABOK Overview, III-Requirements Planning, IV-The “Right Amount” of Requirements Management.

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.

A New Series about Requirements Management and Much More

Written by Cynthia Low on August 15, 2008. Posted in Articles.

More interesting and informative articles and blogs again, this month! A couple of new articles, one of which is the first in a new four-part series. Our bloggers are back and there are a couple of news items in our IIBA section we’re sure will get your attention.

Introducing the new BA Times bookstore and library!

We are pleased to announce that the BA Times bookstore and library is now live! You can review and buy books, suggest new ones to add to the library, and write reviews and ratings!

I Don’t Have Time to Manage Requirements; My Project is Late Already! Elizabeth Larson and Richard Larson take a look at how imposed deadlines can really have a negative affect to requirements management and, ultimately, the project itself.
Documents; The Neglected Side of Business Information Automation. Many companies are working to acquire or develop high tech business solutions. Mark Crandall believes that people, processes, paper and technology must work together to achieve success.
The Need for Speed. Adam Kahn worries about the fact that so many of us are having to do more with less, but he offers some practical tips to make your time go further.
Will PMI Agree that BA Must Precede Projects? It’s a lot easier to make project estimates and plans if a BA has been there first. That’s the view that Marcos Ferrer shares with us in his blog.
The Value of CBAP Certification and IIBA Monthly Webinars Start August 26, 2008. Two important announcements from IIBA that are well-worth checking out, especially if you’re considering CBAP certification.

When is the BA’s Work Finally Finished?

Written by Cynthia Low on July 15, 2008. Posted in Articles.

The business analyst’s work is not finished when the requirements document is signed off. Although other experts are responsible for the project activities, the BA remains involved to ensure that decisions made have no adverse impact on the business stakeholders. As the project progresses, the BA should collaborate with the solution team (for example, development, procurement) to ensure that the agreed solution will satisfy the requirements.

After the solution has been built, the BA collaborates with many people on activities such as testing, conversion, cutover, and training. Depending on the roles defined in an organization and the project, the BA may collaborate with the people who are responsible for these activities, or the BA may be the responsible person. In either case, the BA ensures that all of the right things happen.

Monitor Solution Design and Planning

As the technical team derives the solution design, the BA must learn enough about the implications of that design to ensure that it supports the requirements well. For example, the BA might:

Review user classes to ensure that all of the solution functions, uses, and end users have been accounted for.
Review the developers’ functions and feature list for completeness.
Map the documented requirements (both functional and Quality of Service) onto the elements of the system design to ensure complete coverage.

When the technical team defines their phasing plan (which identifies the order in which requirements will be addressed and functionalities designed and built) for incremental development, the BA must ensure that the plan supports the stakeholders’ needs. If the plan calls for features to be delivered in a certain order, the BA should ensure that the planned order and delivery dates will suit the business stakeholders. The BA should also ensure that the phasing plan provides opportunities for any needed prototyping or validation during the project.

Tracing the requirements to the design is a good way to ensure complete coverage, and it lays the foundation for maintaining traceability throughout the project. The traceability information must be captured and recorded as the designs are being done, as trying to derive the traceability after the fact is difficult, if not impossible.

Finally, as the solution is being designed and built, the BA may identify business process improvements that are unrelated to the solution that is being built that would be beneficial. This is especially likely where those processes will be affected when the solution is implemented.

Validate the Approved Solution

As each deliverable of the project becomes available, the BA must ensure that appropriate validations take place to be sure that those deliverables satisfy the requirements and can be used by the intended end users.

System testing looks at the final system to determine if the requirements have been satisfied.
System integration testing refers to testing the final solution to ensure that it can coexist and integrate with existing systems and databases. Many organizations have an independent testing group whose main responsibility is to prepare for and perform these tests. When that is the case, the BA will usually review the test plans and the test results, and at times, the BA may help with the testing. However, in organizations that don’t have testing groups the entire responsibility falls to the BA.
Operations testing involves testing the solution to ensure that it can be installed and run without an adverse effect on the other existing systems. If the computer operations group takes responsibility for this testing, then the BA will usually review the test plans and the test results. But if this testing is necessary and no one takes responsibility for it, then the entire responsibility for this testing falls to the BA.
Acceptance testing ensures that the business need and user’s needs have been fully satisfied. If the customer takes responsibility for this testing, then the BA will usually review the test plans and the test results. Otherwise, the entire responsibility for this testing falls to the BA.

Assess Other Solution Options

The BA should collaborate with a variety of people on the project as the solution is being put together. In all cases, expect the experts in each area to be making good choices. The BA’s role in the collaboration is merely to serve as the business stakeholders’ advocate and assure that their needs will ultimately be met.

Although the technical team takes the lead in evaluating and deciding on the technologies that could be employed to build the solution, the BA should remain involved. This is because every technical choice has the potential to cause limitations in the solution that will be noticeable to the users. So, the BA must learn enough about the effects of the team’s technical choices to ensure that they actually do support satisfying the requirements, and ultimately, the business needs.

When the plan involves purchasing or leasing (as opposed to developing internally) a solution, the BA may take the lead in choosing the solution. But even if someone else has primary responsibility for this, the BA will still remain closely involved. The BA ensures that any RFP (request for proposal) or RFQ (request for quote) accurately translates the requirements. The BA should also verify that the proposals received will fully meet the business need. And, when the solution is finally received, the BA ensures that it is adequately tested to be sure that is actually satisfies the requirements.

Support Implementation of the Solution

In some organizations, an operations team takes the lead in implementation, but often the BA is responsible. In either case, the BA must remain involved to ensure that implementation and any necessary conversion meets the needs of the users.

The BA ensures that any necessary installation planning is done, and that the appropriate technical experts review that plan for correctness. This could be as simple as ensuring there is enough disk space for the new software, or as complex as replacing entire computer systems with new ones.

Conversion is almost always an issue. Since the solution is most likely changing some attribute of the business process, there will probably be data conversion; there may also be other kinds of conversions to be done. Planning for these includes identifying the rules for handling the inevitable problems that will be found.

Finally, the plan to the final cutover to the solution must be well thought out. When should it happen? Will there be downtime involved? If so, how much is acceptable? An important, but often overlooked item is the “backout” plan. If the cutover fails, what must be done so the business can resume working with the old system? If there is significant data conversion or other changes, this can be a difficult problem.

Communicate the Solution Impacts

The responsibility for communicating the impact of the solution is assigned to different people in different organizations. In any case, the BA must still remain involved. Before the new solution is implemented, the BA should work with the business stakeholders to ensure that they are ready for it by:

Ensuring that everyone who needs to know about the implementation has the information they need, when they need it, before implementation
Setting the expectations of users and other stakeholders about how the change will affect them and the business process
Making sure that any needed training and help is available to the users in a timely manner

After the implementation is complete, the BA collaborates with the appropriate people to report on the implementation. This reporting provides pertinent information to all the parties who need to know that the implementation took place, and if there were problems. A key item is the business impact that the change had. Since the project was undertaken to improve a business process, the actual impact on the business process is of major concern.

Perform Post-Implementation Review and Assessment

The final validation occurs after rollout of the solution is complete. This activity, also known as “Lessons Learned,” is designed to help the organization learn from each project, supporting continuous process improvement.

You need to capture these successes, identify why they happened on this project, and determine what can be done on future projects to make them routine. The parts of this project that worked particularly well represent opportunities for future projects.

By the same token, if there were things in this project that were problematic, they also represent opportunities for improvement. You need to capture these issues, identify why they happened on this project, and determine what can be done on future projects to avoid them.

The Lessons Learned review is one of the most potent mechanisms for organizational learning and continuous improvement, as long as you actually use what you learned in future projects.

In Summary

Solution assessment includes all the activities that the BA collaborates in to ensure that the technical and other decisions being made by the development team result in meeting the needs of the business and users. These activities include design decisions, phasing for incremental development, maintaining the traceability matrix, choosing technologies, procuring solutions, and ensuring usability.

Jill Liles has been the Marketing Manager for Global Knowledge’s Business Analysis training courses for two years. Her background is in continuing education and non-profit marketing, and she graduated Summa Cum Laude from Peace College in Raleigh, NC.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training. Visit our online Knowledge Center for free white papers, webinars, and more.