Skip to main content

Tag: Lean

In this Edition: Managing Requirements, Getting Motivated, IIBA News and New Blogs

sept15-time.pngOnce again we have a mix of the latest part of a continuing series requirements management plus plenty of other new and interesting contributions about the business analysis world – what’s going on now and what to look for in the future – that are sure to give you something to thinks about. Plus we have an update about what’s new at the IIBA. And, of course, our bloggers are back, including one new one.

  • I Don’t Have Time to Manage Requirements: My Project is Late Already! Part III. In this, the third in their series, Elizabeth and Richard Larson discuss the appropriate requirements management process for different projects; too much can be as bad as too little. 
  • Creating Motivation through Discovery. Richard Lannon talks about the importance of motivating people. He says it’s all about asking the right questions, listening and understanding – and then taking the appropriate steps. 
  • Will the First CBAPs Be a Credit to the Profession? Well Will You? Marcos Ferrer bills his blog as one of the world’s shortest blog. But he puts a very important question to all CBAPs. We hope you’ll answer him! 
  • The Cost of Validation. New blogger, Jonathan Malkin takes a look at how much is invested in developing systems but often nothing to ensure the system works, yet, as he points out, Solution Assessment and Validation is an important area in BABOK.
  • IIBA Launches Computer Based Testing of the CBAP Exam and a Letter from the President September 2008 are two important information pieces from The IIBA section of this site.
  • Defining Roles in the BA Life Cycle. Terry Longo asks if a single BA can be skilled in all aspects of the solution life cycle. He thinks single BA ownership makes sense but finding the right individual can be tricky – but not impossible.

Also don’t forget to check out our webinars and the Business Analyst Times book shop. And let us know what you think about this edition of BA Times.

Many thanks.

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]

I Don’t Have Time to Manage Requirements; My Project is Late Already! Part III

Getting to the Right Amount of Requirements Management

Choosing appropriate requirements management processes is critical. It is important to find the balance between the extremes of a burdensome process and no process at all. All levels of rigor can be appropriate, depending on the project and the organization where the process is followed. On some projects, following a great deal of rigor is required; on others little is. Scott Ambler, a proponent of the Agile approach, stresses the importance of “just-in-time JIT requirements elicitation.” Alan Davis supports “Just Enough” approach.

Some of us remember the pre-process and pre-methodology chaos of the 1970s. It was not uncommon for developers to sit down by themselves or at best with a single “user” to hammer out features of a new piece of software. Those of us who lived through that time remember some of the issues of the “users” who articulated their own needs, but who didn’t represent all the stakeholders. Or management who pitted one developer against another to try to get the software developed sooner, or the developers who dictated to the business what was in and what was out of scope.

Nevertheless, too much rigor can become overly-burdensome. Here are some pitfalls to avoid:

  • Misaligning the amount of rigor required with the size of the project with. One example of misalignment is having inappropriate levels of approval, such as requiring a formal Change Control Board for a small, well-understood, low-impact, and well-accepted change. 
  • Developing a requirements management plan that takes more time to create than developing the product • Requiring the creation of a requirements management plan “because that’s the process we follow here.” 
  • Handling all projects with the same degree of requirements management.

The “right” amount of requirements management occurs when there is enough rigor to: 

  • Reduce business and product risks 
  • Communicate effectively with all stakeholders. Communications becomes more complex with more stakeholders, so formalizing the communications on larger, more complex projects is usually appropriate. 
  • Help ensure that a quality product is delivered at the end of the project. 
  • Ensure the production environment is not jeopardized during deployment.

To this end, some applications of requirements management may need more emphasis than others. For example, one of the authors of this article was the project manager on a new retail application where the risk included the possibility of having incorrect prices on all the items in all the retail store locations. The project team spent several months planning traceability, testing, implementation, risks, communications, and other aspects of requirements management, and we implemented a three-year project within days of the projected date, only to have performance so poor, that holiday sales were in jeopardy. She also managed a project that she thought was “small,” ignoring requirements management completely. The team spent several months in “stabilization,” which was a nice term for cleaning up the mess that had been created.

Negotiating the dates

In all likelihood there will be stakeholders who want to complete the business analysis planning more quickly than seems reasonable. Because business analysis is not always perceived as value-added, some stakeholders will attempt to shorten the process. Here’s an approach to follow: negotiate not the deadline, but the deliverables. Trying to change the projected date is fruitless without negotiating the scope, which is comprised of the deliverables that will be produced. If the sponsor wants to bargain to reduce the business analysis time, here are some tips to try: 

  1. Make sure your sponsor is aware of the requirements process and/or methodology and why it was chosen. This implies that thought has been given to that requirements approach and that it was chosen with care. For example, a sponsor may have heard of “agile” projects and may want to dictate that your project be done “agilely.” Emphasize the benefits of the chosen approach. 
  2. Show the sponsor the deliverable Work Breakdown Structure, which serves as a “picture” of the scope of business analysis work. Explain why each deliverable is important to the project outcome. Give the sponsor a choice of removing deliverable(s), but for each one the sponsor wants removed, explain the risks and impacts of discarding it. You can also recommend which deliverables to remove. The sponsor will appreciate your understanding of the impacts and ability to present alternatives and the associated benefits and risks. 
  3. Be prepared to quickly re-estimate the effort with the removal of deliverables. You will lose credibility if the planning process drags on with iterations of estimating, reviewing, and changing, without solid agreement. 
  4. Be sure to be prepared when meeting with the sponsor. Talk to key stakeholders before the sponsor meeting to understand which deliverables really are negotiable, and which are essential to the end product being delivered. Work with the key stakeholders to obtain as close to a consensus as possible, so that you can present your recommendation neutrally thus truly representing the client perspective. 
  5. Be sure that you absolutely understand the business problem that the sponsor is trying to solve. Any deliverables that do not help in solving the problem should be removed from the WBS. In addition, explain how managing requirements can actually save time. Explain how using requirements management tools, such as the traceability matrix, can save time because it ensures there is a clear linkage between a requirement and the business problem being solved. By tracing requirements we not only help ensure that every requirement adds value, and that every approved requirements will actually be produced, but also that scope creep is less likely to occur.

If during requirements planning new deliverables are uncovered, or changes to deliverables are desired, it will be necessary to modify the WBS, create new tasks, re-estimate the amount of time it will take to produce the new or changed deliverable, and discuss what changes in the schedule are required. Negotiating with the sponsor, as described above, is important whenever there is a change. Sponsors typically want to know what every new requirement will cost, so be prepared with estimates when discussing them.

References: Ambler, S. Agile Modeling, http://www.agilemodeling.com/essays/changeManagement.htm and http://www.agilemodeling.com/essays/examiningBRUF.htm 
Davis, A. Just enough Requirements Management Part 1
http://conferences.codegear.com/article/32301


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.

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

sept2_school_fall_150x100.pngSummer 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 Don’t Have Time to Manage Requirements; My Project is Late Already! Part II

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.

idonthave1.png

 

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.

A New Series about Requirements Management and Much More

calendar-deadline-aug15.pngMore 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.