Tag: BABOK

10 Ways to Use Requirements to Melt an Executive’s Brain

Written by Keith Ellis on May 19, 2009. Posted in Articles.

So you’ve been tasked to get requirements on a strategic project, and you’re thinking to yourself, “How can I make my business requirements documents as incomprehensible as possible?” Going this route may not be just a job security thing. Making yourself indispensable as the interpreter of requirements seems to be the traditional route of delivery and getting buy-in. Just keep running the requirements process until someone gets desperate and finally signs off on the spec in the vain hope of getting something useful for their effort before the end of Q4 2014.

So, some tips and traps for those of you looking to truly perplex and bafflegab your bosses:

Just give a list of “the system shall …” statements. Having a few hundred of these statements with no accompanying business process descriptions as a common point of reference to help navigate the swamp will keep the average executive bogged down for days. Their paranoia that something critical got missed might just match your paranoia when they show up at your desk to have requirement 143 explained to them.
Experiment with similes when describing data objects. No one wants to hear about ‘customers’ repeatedly. Why not make the document more dynamic and talk about prospects, or accounts, or valued relationships, or partners, or something more interesting. You just shouldn’t be overusing simple words repeatedly … it’s boring!
The use of UML sequence diagrams and class diagrams will help prove to that doubtful executive that you truly understand systems development and have a deep understanding of industry standards. Just loading up their inbox with hefty documents packed with these pretty pictures will have them panting for more.
Remove all evidence of traceability between one set of requirements and the next. The idea is to produce a set of business objectives and scoping documents in one format and using one set of techniques. Then get your business requirements using something completely different. Go for something truly unique in the system specs. The idea is to show your diverse understanding of ALL the different approaches available to the business analyst. Besides, they are signing off on each document separately anyway… there is no real need to look back at what came before.
Be snappy with solutions. No matter what the request. Within three minutes of the executive’s starting to the grand vision, cut him or her off and begin explaining how the solution is easily delivered by looking at the existing legacy applications. Your attention to promoting existing corporate assets will be well received.
Tell your CFO that you want to use Xtreme programming on the Basil II financial compliance project. The idea of a programmers eagerly jumping into the breach to resolve important issues for the business should be warming to her heart.
Tell your outside sales force they need to be dedicated to a requirements discovery session for three weeks. Your attention to thorough detail will be appreciated by the SVP sales.
Adopt PowerPoint as your primary documentation engine. A few simple screen mock-ups to show the user interface will immediately grab everyone’s attention as delightfully artistic. Besides, the workflow behind it should be entirely self-evident to any self-respecting programmer that’s been with the company for a few dozen years.
Make sure the first dozen pages contradict the second dozen pages. Every executive should be presented with options. How could they not like alternatives for the business?
Drop out key sections of the document and pop these into secondary or tertiary documents. Then refer generally to the existence of these other documents, but don’t put in the actual page, or a hyperlink. This is a great way to ensure they read the whole thing.

Hey guys – have fun and add your own. I wish you all great success.

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

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

Group Dynamics and Requirements Elicitation

Written by Richard Lannon on June 16, 2008. Posted in Articles.

As an information technology professional, developing your business acumen is important. One of the skills you need is the ability to facilitate. In your case, it is all about “facilitation for elicitation of requirements” to solve business problems. In working with groups, there are a number of dynamics that the facilitator needs to be aware of. It is helpful if you consider the different group characters and how to deal with them.

The Isolator
This is that one person who remains outside the group or is thinking about previous topics. Consider spending time helping people get acquainted or have discussions using pairing and triads. Provide opportunities for debriefing or summarizing what was discussed. Get the participants involved.

The Monopolizer
We all know this person. They monopolize the time and focus of the group. Be clear on your expectations, use your body language to hurry the speaker or, when they take a breath, say “thank you” and ask for other comments. You can also use a parking lot to write their points down. It is best not to interrupt. However, it is OK to watch for the talkers to draw a breath, and then attempt to regain control by leaping into the instant of silence this creates. Move fast, but speak softly and gently.

The Facilitator as Expert
As the facilitator, you should never set yourself up as the expert. You are there to understand the requirements and help establish direction. Consider avoiding answering every question yourself by letting group members respond to each other. Do not feel obliged to comment on everything that everyone says. Reduce your own authority by sitting down with the group.

Group Sharply Divided
This is where the groups are together physically but not together in interests or point of view. Mix the group up and get people to move around the room. Put them in new requirement work teams and assign the groups a specific relevant task to complete. Have team members present and then debrief. If a solution cannot be reached, get agreement to park it! Make sure you ask the group if they feel comfortable moving on even though the issue dividing them is not settled. Be prepared with several group exercises, tools and techniques. Most important; keep cool, detached, and unhurried. Use a light touch.

Antagonistic Duo
These are the two people exchanging negative vibes and making everyone uncomfortable. Confirm that the conflict is positive and ask them to continue their disagreement. Set the stage by moving them closer together, arrange other group members as observers, and establish a scribe. Most importantly make explicit ground rules for conflict. Ask group members for feedback. Get everyone involved by taking the issue away from the duo by saying, “You have highlighted an important issue for us.” Here is an exercise for the entire group to participate in that continues exploring these issues, but in a different way.

The Cozy Duo
Here two friends are choosing to give each other comfort. They are making side conversations. This is not alright. The best solution is change the teams and rearrange the seating locations at a break to split the cozy duo up. Position the change as an opportunity to get a different perspective.

Unresolved Members
People are not engaged. It happens. Sometimes people do not understand why they are participating; they never wanted to participate; they just do not care or maybe they are bored. Break time! Check the thermostat and drop the heat in the room. Maybe change things around. Consider a group exercise, a short controversial video on the topic, Have the group brainstorm on a new agenda and create consensus. Be brave and leave the room while they do it. The break may help you to refocus and help them to become more active.

Highly Defensive Group
In this case the group members have erected barriers to protect their personal or professional images. This is about self-preservation. You need to get people talking and sharing in a low threat way. Move slowly with no pressure. Focus on facts and intellectual work for a time, gradually introducing small amounts of selective attitude. Avoid role-playing. Be open to revealing more about yourself. Sometimes this sets the stage for other people to reveal information.

The Big Group
If the group has many members and no sense of inter-relatedness, be prepared to use pairs, triads and work groups. Rearrange the group into round tables so they can see one-another. Get people discussing specific related topic. Make sure you walk around the room making contact with people. Establish “associate facilitators” to manage the different groups. The larger the group the more ground rules, definition of roles and leadership required. Avoid feeling and attitude work with large groups. Keep people on track.

The most important thing as a senior professional, business analyst, manager or leader in developing your facilitation skills is to have fun and enjoy the process. Find ways to enhance being a facilitator and applying requirements elicitation best practices. Develop your group dynamic skills along with the tools and techniques of requirements elicitation. Remember to leverage the group’s unique character and get the members engaged.

Richard Lannon is an international business and technology industry veteran turned corporate speaker, facilitator, trainer and advisor. He specializes in aligning the enterprise and technical skills to common business objectives. Richard helps organizations and professionals identify what’s important, establish direction and build skills that positively impact their bottom line. He provides the blueprint for your organization to be SET (Structured, Engaged and Trained). His clients call him the SETability Expert. He can be reached at [email protected] or 403-630-2808

Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM

Written by Cynthia Low on May 15, 2008. Posted in Articles. 1 Comment on Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM

In my previous article, Is it Time for the BA and the PM to Get Hitched? I set the stage for additional comments on the inevitability of the morphing of the business analyst (BA) and project manager (PM) into a single professional that I labeled the BA/PM for lack of an appropriate title. Along with that I promoted the idea of a World Class Business Project, Program, Portfolio and Process Office or BP⁴O, for short, to support this new professional.

In this article I would like to discuss requirements gathering and management. I believe it is the area of greatest overlap between the BA and the PM. Both the PM and the BA face the same challenges here. Even under the best of circumstances, it is very difficult if not impossible to identify and document complete requirements during the Initiation Phase of the project. The reasons are many and well known to both professional groups. There are at least a dozen approaches you might use for requirements gathering and it is not my intention here to present a tutorial on their use. Rather my focus will be on the need for a more collaborative effort between the BA and the PM in the process of effectively managing those requirements throughout the entire project life cycle. I have defined the Requirements Breakdown Structure (RBS) as an artifact in the Initiation Phase of the project. It is the infrastructure that supports requirements management throughout the project life cycle, the choice of a life cycle model and the choice of best fit project management tools, templates and processes.

Requirements Breakdown Structure

The RBS is a hierarchical description of the client’s needs. There are at most four levels of decomposition in the RBS:

Level 1: Client statement of a requirement
Level 2: Major functions needed to meet the requirement
Level 3: Sub-functions (for larger more complex functions)
Level 4: Feature(s) of the functions or sub-functions

The RBS defines what is to be done and can be thought of as a deliverables-based WBS which defines what will be done. Further decomposition of the RBS produces a deliverables-based Work Breakdown Structure (WBS), which defines not only what must be done but how it will be done. There is, however, a fundamental difference between the two. The RBS may not be a complete decomposition of what will be done whereas the WBS must be complete in order for the traditional linear approaches to project management to be appropriate. There is an obvious disconnect here. The temptation is to speculate on the future to fill in the gaps in the RBS. If you take this approach, you are planting the seeds for failure.

It is this lack of completeness that drives the choice of Systems Development Life Cycle (SDLC) and the supporting Project Management Life Cycle (PMLC) tools, templates and processes. The two life cycles are inextricably linked. Any project that produces an incomplete RBS at the outset must use some type of agile approach to managing the project. In these situations the obvious conclusion is that the professional who manages requirements gathering and management over the life of the project must be expert at both business analysis and project management. The learning and discovery of heretofore unidentified requirements occurs in the iterations that make up an agile approach. In other words, requirements discovery takes place throughout the entire project life cycle and is fully integrated into management of the project. This is not a situation where a hand-off from a BA to a PM will work. The complexity and uncertainty of the solution and the processes for its discovery negates that approach. A BA/PM is needed for maximum impact.

Project Landscape

At the risk of over-simplifying a complex and uncertain project environment, consider Figure 1. It is one way to envision the project landscape. Two variables define this landscape: the goal and the solution requirements.

Figure 1: The Project Landscape

Each can take on one of two values: Clear or Unclear. Traditional Project Management (TPM) approaches are used in situations where both the goal and solution are clear. These projects should use life cycles that are Linear or Incremental. TPM Projects, because of the clarity of goal and solution identification, can effectively use a BA and a PM with the requirements hand-off fairly straightforward. Agile Project Management (APM) approaches are used in situations where the goal is clear but the solution is not. These projects should use life cycles that are Iterative or Adaptive. And finally, Extreme Project Management (xPM) approaches are used in situations where the goal and solution are unclear and should use life cycles that are Extreme.

As I travel around the planet speaking to BAs and PMs at conferences and workshops, I always ask my audience what percentage of their projects fall in each of the TPM, APM and xPM quadrants. I’ve asked that question to over 5,000 BAs and PMs in the US, Canada, England, Germany, Switzerland, Czechoslovakia, China and India. The results are remarkably consistent:

Linear or Incremental 20%
Iterative or Adaptive 70%
Extreme 10%

I suspect that a major contributor to project failure is the force fitting of a Linear or Incremental approach when an Iterative, Adaptive or Extreme approach should have been used. The fourth quadrant where the goal is unclear but the solution is clear is not a viable choice. That is not unlike a solution out looking for a problem. Maybe you know of some consulting firms that act like that. I sure do.

I’ve made my point. We say that every project is unique: That it has never happened before and will never happen again under the same set of circumstances. It would be naïve to think that one project management approach would work for every project. We have already noted how goal and solution clarity and completeness of requirements drive the choice of development model and project management approach, but there are several other project characteristics that should be considered. I have had occasion to consider risk, cost, duration, complexity, market stability, business value, technology used, business climate, degree to which you expect to have meaningful customer involvement, number of departments affected, the organization’s environment and team skills/competencies.

Putting It All Together

I believe in and have always presented a one-stop-shopping experience to my clients. It is critical to project success that a strong sense of teamwork be created between the client and their team and the project manager and her team. The BA/PM professional is better equipped to do that than if a BA and PM were separately involved. The BA, PM and client structure requires three communication links, all working in harmony, while the BA/PM requires only one. With people-to-people communication being the major reason for project failure, we need to give serious thought to creating the BA/PM professional for those APM and xPM Projects. There is much to discuss about the preparation and development of the BA/PM and I hope to present that information in subsequent articles.

The first article in this series drew a large response, and I would certainly like to hear your further thoughts on the BA/PM professional. I’m sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles.

Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3^rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

Enterprise Requirements Alignment: The Top Three Challenges

Written by Terry Longo on March 31, 2008. Posted in Articles.

1. Change Management as an enterprise core competency. Consider any particular requirement. At any point in time, one of the following is true:

The requirement is valid but not being met – in which case some aspect of the solution must be changed.
The requirement is not valid (even if it used to be) – subjecting it to further iterations of the requirements life cycle and corresponding changes to the underlying solution
The requirement is being met and will remain valid for the foreseeable future – in which case attention will turn to changes to the solution for increased efficiencies. (This means, by the way, that even the “as is” operational elements of an enterprise are as subject to change as the transformational elements.
In other words, if the requirement is not being met, change is necessary. And if the requirement is being met, change is necessary. Earlier posts to this blog have said plenty about the position that everyone in an enterprise is carrying out requirements management within their respective domains. But what is requirements management but a specific form of change management?

2. Financial Fluency as an enterprise core competency. It is easy to construe scenarios in which the failure of even a single small-scope technical component of an IT based business solution can totally eliminate the solution’s business case. That means that senior management’s view of the solution’s status throughout the life cycle would ideally assimilate the status of that component, requiring the component’s owner to be able to express status in senior management terms of cost, risks, and trend. In other words, each contributor to a solution needs to be financially fluent within his or her domain. And, every time a change must be accommodated, contributors to the solution must reflect how that change impacts the financial picture for their own contributions.

3. The Business Analysis Center of Excellence (BACOE). Enterprise-wide consistency in managing changes to requirements and solutions, along with consistency in measuring, monitoring, and status reporting across, up and down the enterprise requirements hierarchy, demands an enterprise-level entity. This would serve to define and drive the implementation and continuous improvement of best practices in change management and financial management.

You might notice that I have not included in the top three the selection of a tool to underpin enterprise-wide change, requirements, and financial management. Tools are easy. The real challenge is driving the enterprise culture to the point where an understanding of one’s job in terms of requirements management, change management, and financial management is second nature.

Terry Longo has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through http://www.hp.com/education/sections/pm_bus_analy.html or at [email protected]