Skip to main content

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

Written by Richard Lannon on . Posted in Articles.

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]

Defining Roles Cycle in the BA Life

Written by Terry Longo on . Posted in Articles.

Last time I asked “Can a senior BA really be skilled in all aspects of the solution life cycle?”. My humblest apologies to those of you who have shown such capability – hats off to you! I did not mean to imply impossibility, just that it is a long haul to get to that point.

I’ve always thought end-to-end ownership of an initiative, by a single person, results in a high level of “conceptual integrity” – having a single BA own a set of requirements and its corresponding solution(s) has great benefits. However, finding those BAs who are strong in all areas of the BABOK poses a challenge for many organizations, especially when so many BAs (by other names, to be certain) have specialized in a particular solution area.

It is easy to envision multiple roles with the BA life cycle, allowing someone to focus on a particular set of tasks/techniques, for example: 

  • Enterprise Analyst 
  • Business Case Specialist 
  • Elicitation Specialist 
  • Survey Designer and Psychometric Analyst 
  • Validation Specialist

If those activities and others were carried out by BAs with special focus, there would still be value (indeed, a need) for a BA with overarching responsibility for the team of BA specialists.

What about your organization? Do you have BAs who specialize in a particular aspect of the requirements life cycle? If so: 

  • What are the specialties? 
  • What is in place to ensure continuity in their handoffs from one phase of the life cycle to another, and how sophisticated are the tools underpinning that process? 
  • Has your organization defined career paths that manifest those specialties?

Even if your organization does not distinguish such specialties but you have given it some consideration, we’d love to hear your thoughts.

Creating Motivation through Discovery

Written by Richard Lannon on . Posted in Articles.

I am often asked by business analysts, consultants, supervisors, managers and leaders, how do you motivate people? Motivation is an endless process. People, teams and organizations are motivated for different reasons. Your job as business analysts, supervisors, managers and leaders is to leverage your own business skills to understand what motivates the people around you.

The reality is people are motivated because they are motivated. Not because you just rewarded them a date night movie pass for two, popcorn and coke included. One size does not fit all. Motivation is all about asking the right questions, listening and understanding – and then, to the best of your ability, facilitating the needs of that person, team or organization.

Consider it requirements gathering and documenting. Take these ten questions into consideration.

  1. What are the primary objectives of your organization? The people around you, your clients and resources might show more motivation if they understood what is going on. Ask clear questions of the organization to establish clarity of mission, values and objectives. Specifically, what is on the strategic agenda of the organization? You should know the answer to that question. 
  2. What obstacles inhibit us from moving forward, getting the information we need, without which people are hindered from doing their best? People have lives, professional and personal. Consider inquiring about what people are tolerating personally and professionally. Maybe you can destroy motivation-sucking activities. 
  3. What motivates the people you are dealing with? Interestingly, they will tell you that they are motivated by a whole range of different things. Motivation could include tending to family needs, reward and recognition, freedom from structure, competition, security, community service or maybe financial reward. The potential list is huge, but on an individual basis, it is most likely only a handful of items. 
  4. How empowered do people, teams and the organization feel? Do people feel like they have autonomy, independence, room to make decisions or are they controlled, manipulated and have the life sucked out of them? These are important considerations. 
  5. What changes have you proposed or put into place that just killed motivation? Maybe you are investigating the feasibility of implementing a new system that will increase efficiency for management but give administration more work. People are just not interested in helping. In this case, go after the FUDs (fears, uncertainties and doubts) about the future or present event. Give people the freedom to express their concerns with respect. Ensure they feel heard and understood. You may not be able to leverage or act on anything they say, but if they feel you are listening to them and you have captured their needs and requirements, it goes a long way towards motivation. 
  6. What are the motivational patterns of your people and teams within the organization? Check out motivation from the perspective of your best people and teams. Start to develop some lessons-learned data that can be leveraged to perform gap analysis, best practices and training opportunities. 
  7. Are the goals of the individual, team and organization aligned? As a professional, you need to recognize where the organization wants time spent. Establish the valued focus areas. Then consider whether resources are focused on those items and their motivation levels based on their activities, whether right or wrong. 
  8. What do people think about this place they hang out at for 40, 50 or 60 hours a week? This is a loyalty and commitment question. Take generations into consideration when answering this question. 
  9. When it comes to individual, team and organization involvement, how involved are your people in the strategic, tactical and operational development of the organization? Do people get randomly transferred or assigned to committees? When they talk or tell you something, do they feel listened to and heard? When putting a program together are they consulted? Consider this stuff – you may have to leverage the leadership skills and attributes of your business analysts or a person who is recognized as a leader to find out. 
  10. How consistent is the organization internally and externally? Maybe externally you are the “green technology company” and people joined because they thought it was true. If the internal reality is inconsistent with the external appearance, this will cause motivation problems. Again gap analysis is needed to determine the problem and challenge ahead.

These are just some areas to consider when it comes to motivation. I recall a situation when I was a senior manager some years ago in a large international company. I had an employee whose performance was suffering. I knew the person had the talent and knew their job but the drive was missing. Unfortunately, they received poor performance reviews for a few years due to this. It took several one-on-one discussions regarding their performance and, more importantly, their personal life circumstances and interests for us to discover that they loved to travel. Once we clued into the travel option we set up a career path where the person was able to travel about twice a quarter to help the organization on various initiatives. The best part is that we dove-tailed their professional development with another senior person who hated to travel but loved to develop other people using telecommunication technology. In the following two years, both people flourished and were promoted two levels above their original.

Ask questions and discover the needs of the individual, team and organization and facilitate it. That is how motivation is created.

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

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

Written by Cynthia Low on . Posted in Articles.

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.

The Cost of Validation

Written by Jonathan Malkin on . Posted in Articles. 1 Comment on The Cost of Validation

Initial Analysis $100,000
Development and Execution $500,000
Validation Priceless

 

It is amazing, a client pays 100K to 2M or more to develop a system and $0 to make sure the system works. How do we ensure the system meets our needs?

Solution Assessment and Validation

Solution Assessment and Validation is one of six knowledge areas defined in the BABOK (Business Analysis Book of Knowledge). I recently helped a government client document and execute validation under FDA 21 CFR Part 11 rules.

FDA 21 CFR Part 11 Computer Systems Validation outlines validation methods to ensure the system works as expected and meets the business need. All systems must have a Validation Plan, User Requirements, Functional Requirements, and Test Scripts.

User Requirements are general requirements concerning the use of a system.

Functional Requirements break down User Requirements into how users will specifically interact with the chosen system.

Test Scripts are written for each Functional Requirement.

Test scripts are executed, witnessed, and counter-signed. After execution the organization has a fully documented and auditable trail to show the system was properly installed and qualified to meet the business need and technical requirements.

In addition, a validated client documents Standard Operating Procedures for use of the system. This step forces the organization to take a close look at how the system will be used and why it is being implemented. Any time people spend to think through how and why they use a system is a good thing!

Downside?

The downside is less flexibility in making system changes. A COTS system that is highly configurable and easily changed is now subject to a multi-level change control process. A simple configuration change may take days or weeks to propose, authorize, document, and implement.

Conclusion

21 CFR Part 11 Validation is worthwhile where the cost of deviation from process greatly exceeds the cost of change. In the case of manufacturing pharmaceutical drugs or vaccines, minor deviations in process can impact the lives of millions of people with drastic consequences. It’s in these very cases that validation is indeed worthwhile to ensure systems meet the safety and security concerns of all.

Jonathan Malkin is a Business Analyst at Plateau Systems. Jonathan provides configuration, integration, documentation, and deployment support services for a leader in Talent Management Systems. Jonathan’s areas of support include 21 CFR Part 11 Validation and customizations to COTS software for which he has won multiple awards. His experience includes work in the federal government, telecommunications, mortgage and banking, and custom software development industries. Plateau Systems is a leading global provider of adaptable, unified web-based talent management software, content and services to onboard, develop, manage and reward talent.