A High-Level Program for Enhancing Skills in Requirements Teams

Organizations around the globe are improving the success rate of their software projects by focusing on the quality of their requirements. In a recent CIO article, Thomas Wailgum points out that CIOs are investing in software requirements, though actual definitions of the requirements team that handles them remains somewhat vague.[1]

In so doing, internal IT teams have begun to manage internal software much like externally facing development groups manage their products – like product managers. This trend supports company objectives, improves ROI, and, most importantly, helps IT develop software that their internal customers love to use.

So it is not surprising that more and more individuals are interested in performing the job of product manager. Fortune 500 companies are consolidating their requirements groups. Plus, organizations like the IIBA and resources such as the BABOK lend credence to what was previously an unrecognized profession. There is no doubt that individuals and companies alike are benefitting from the standardization of the role.

Creating and harnessing the power of a great requirements team is challenging because the skills associated with requirements analysis are complex. There is a breadth and diversity in the skills and knowledge required that are alien to other positions, including:

• Understanding poorly defined problems

• Conflict resolution

• Scope definition

• Facilitation

• Understanding people’s behaviors

• Working with a variety of types of people

This white paper aims to outline a high-level program for improving the skills of a requirements team, based on several years of experience working in the Fortune 500 trenches. If you manage a team of requirements analysts or if you write requirements yourself, this paper will guide you through a process for developing the skill set that will help create software that your customers love to use.

Start With a Diverse Team

Most requirements analysis teams have a blend of people, who range from beginners to experienced managers. Plus they may have varying professional backgrounds. The following are the most common types of individuals on a team:

• Beginners with a technical degree – these people are typically inexperienced in the professional arena; however have analytical capability that has been refined through schooling. In the perfect situation, they have developed software in college and will quickly learn that element of the role. These people are likely to come from engineering or computer science backgrounds. Their initial learning process should be focused on understanding basic requirements skills and the soft skills associated with working with people in a professional organization.

• Beginner without a technical degree – these are the people who may have no training in the software development lifecycle and may not even understand what requirements are. However, they likely still will have an analytical degree. They can be very successful though because they bring a fresh perspective to the role. Examples of this type of person include someone with a degree in English, Journalism, Physics, or Chemistry. These people will need to learn the same things as those with technical degrees, and they should have an added component to their program to teach them about the software development lifecycle.

• Experienced professional coming from a different field – these people are inherently beginners at requirements work; however many of their experiences from other professional areas of work will translate well to this role, thereby accelerating the learning process. Oftentimes these people may have been sitting on the other side of the fence, either as subject matter experts in software development or users of internal software. The bulk of the learning process for these people will be in requirements skills and possibly in the software development lifecycle.

• Experienced professional at requirements analysis – these people have done requirements work in the past, perhaps in another organization. For these people to be successful, it is important to align their ways of thinking with those of the organization they are working in. It is equally important to listen to their ideas to improve the organization’s methodology from past experiences. Ultimately, they should be quickly moved into the role of mentoring less experienced co-workers.

A diverse team can be an incredibly powerful tool. When planning to grow the analytical skills of these people, first understand which category they fit into. Recognize that they will need different types of training and mentoring to round out their skill sets and tailor their learning path accordingly.

The Requirements Analysis Job

The professional who performs requirements analysis is often called different things, including requirements analyst, business analyst, project manager, requirements engineer, and product manager. Whatever your company calls it, the actual activities and objectives of the role are very similar across organizations.

With the growing number of organizations refocusing on internal requirements, the internal product manager seems to be the most apropos title for someone who manages software requirements. Product managers are responsible for end user adoption, end user satisfaction, and return on investment of the products they work on. There are common interim goals of minimizing missed requirements, scope increase, and unclear requirements. They perform activities including scope definition, eliciting requirements, documenting requirements, communicating requirements to development, and performing user acceptance testing.

Requirements Analysis Skill Set

With many activities in their job description, it is not surprising that there are a diverse set of skills and knowledge that a product manager needs to have or develop in order to create requirements that are easily understood by both users and IT.

Product managers must understand:

• The language used to talk about requirements

• The requirements lifecycle

• A generic requirements methodology

• The software development lifecycle

They also must understand and be able to perform activities including:

• Different methods to elicit requirements, such as questionnaires, observations, and facilitating groups

• Writing clear requirements

• Modeling requirements

• Reviewing and validating requirements and managing the change process

• Managing a room of people

• Facilitating decision making

• Resolving conflicts and gaining consensus

In addition, there are “intangibles” that go along with every job. Some of the capabilities necessary for requirements analysis include being thoughtful, likable, able to think on one’s feet, passionate, detailed, and finally, they must enjoy working with people. These are traits that one may not be able to teach, but they can function as a checklist during the hiring process.

Building the Team’s Skill Set

Ultimately, all product managers have a similar top-level growth goal, which is to be able to create software that your internal customers really want to use. The IIBA is putting some structure around the skill set, but certification for the sake of certification does not create great software. Our guidelines are intended to help you understand what can be done to create successful results in software, independent of the job titles of the team members.

Unlike in a university setting where there is a hard and fast set of courses that one must take to receive a degree, there are many paths to become a product manager. However, our experiences demonstrate that there are really five stages to building a strong requirements analysis team – get management support, assess, train, mentor, and re-assess – and you customize within each of those to fit the needs of the individual team members.

1. Get Management Support

The requirements analysis skill set is challenging to learn because of its diversity and breadth; therefore you should expect to dedicate significant time and budget to a serious learning program. It is important that management is committed to the importance of the job, the skills associated with the job, and the people they have in positions to do the job. They will have to dedicate time and financial resources to training these resources.

To gain management support:

1. Provide them with past costs associated with project failure and proof of return on investment in requirements. It would be best to use specific metrics from within your organization; however there are standard industry metrics that can be used.

a) Over two-thirds of companies follow requirements practices which make project success unlikely.[2]

b) The top 3 reasons projects are failing are all related to requirements – a lack of user input, incomplete requirements, and changing requirements.[3]

c) After the project gets to deployment, the cost to fix the project due to these issues is anywhere from 40 to 1000 times more costly than fixing them upfront.[4]

2. Supplement the metrics with anecdotal stories from the organization to demonstrate the industry findings apply internally.

3. Prepare a plan that lays out expected training and mentoring, associated costs, and time allocations.

2. Assess Skills

Ideally, you should start by evaluating the skills of the individual product managers on the team for a baseline. It is critical that this is communicated as a baseline for improvement, not as grounds for any discipline, unless the intent is to move the team members around. An assessment might include formal written tests on product manager skills, having someone experienced do a review of the product manager’s documentation, and collecting feedback from the audience of the product manager’s work (i.e. developers, testers, and users).

The audience will provide feedback in the form of whether requirements were consumable, complete, and whether the product manager was able to elicit requirements in a way that made the audience feel comfortable. This baseline can be used to determine what training and mentoring is most useful to each product manager, then the product managers in the team can be grouped and go through training paths together.

3. Train Them

There are two primary direct learning experiences you might use with product managers: formal training courses and self-study programs.

There are many formal training courses available for product management skills. You can put students in courses that vary from primarily lecture-based to those that are highly interactive. Our research shows that courses with interactive activities allow the students to experience using the requirements skills with immediate guidance. This improves retention and changes behavior so that you are getting an instant return on your training.

An important realization in helping product managers get started is to make sure they know the basic language of requirements and software development, the basics of how to elicit requirements and how to model information. Finding some basic requirements skills courses is an excellent introduction to the knowledge a product manager needs to perform the job. There are additional courses on elicitation and visualization techniques that are available. Other courses to consider are those specific to requirements management tools you might be using, advanced courses related to managing requirements in various methodologies, or more in-depth courses on specifics like writing use cases or interviewing techniques. Often courses can be customized to your company’s way of doing things, but for basic training, it is probably not necessary.

In addition to formal training courses, product managers can learn through self-study by way of reading books, using online resources, and looking at examples of work products from other product managers. A suggested list of reading materials include:

• Software Requirements, Karl Wiegers

• Requirements by Collaboration: Workshops for Defining Needs, Ellen Gottesdiener

• Writing Better Requirements, Ian Alexander

• The Software Requirements Memory Jogger: A Pocket Guide to Help Software And Business Teams Develop And Manage Requirements, Ellen Gottesdiener

• Writing Effective Use Cases, Alistair Cockburn

When creating a self-study program, create an online collaborative resource that has templates, how-to guides, and links to external resources. There are several blogs and portals devoted to the requirements discussion:

• ArgonDigital blog
  https://www.argondigital.com/blog

• Free tools from Karl Wiegers
  https://www.processimpact.com/goodies.shtml

• Tyner Blain
  https://tynerblain.com/blog/

• Pragmatic Institute
  https://www.pragmaticinstitute.com/resources/

• Cauvin
  https://cauvin.blogspot.com/

• Modern Analyst
  https://www.modernanalyst.com/

• Business Analyst Times
  https://www.batimes.com/

It can be helpful for new product managers to look at work products from other experienced product managers. This should help them learn how to complete a template, create diagrams, relate information in a document, and decide what types of information go into the various fields of a requirements tool.

Similarly, it can be very helpful to a product manager to observe another product manager in the process of elicitation, noticing how that experienced person is applying the skills the product manager is learning about.

4. Mentoring

Training courses are well suited to learning facts, the basic skills, and tips or tricks to do the job. However, the best retention occurs when students are actually performing the skills they are learning. Mentoring programs are a good way to accelerate the adoption of new techniques, and to stack the decks for the best chances at success. New product managers should be closely mentored by one or more experienced product managers. These product managers work with the mentees on specific project work, both people producing outputs, but discussing the newer product manager’s experience in trying to do the activities.

Their work products should be reviewed frequently for any major issues and to provide suggestions to help them improve. At frequent intervals, the mentor should talk through recent lessons learned with the product manager. This helps the product manager ferment the newly learned concepts in their mind. One final point on this, it is critical that the product manager gets to be mentored by different people and different projects as they progress through their career.

5. Evaluate Frequently

Beyond the initial assessments, it is also a good idea to frequently evaluate the learning progress of the new product managers. They should be tested throughout the ongoing learning program, meaning after any courses, any self-study programs, and periodically during the mentoring relationship. Feedback should be collected from peers and customers on their specific projects. This will allow for course- correction if the training is not working as intended. It also will give management insight into the value of the money being spent on training (or the lack of value, allowing them to change direction).

Remember It Is Challenging

When you decide to improve the skill set of your requirements analysis team, recognize that it is a challenging set of skills and that your team members will have different needs. Create a learning program that will make it easy to get full support from the management team that will provide resources. Execute that learning program, including assessments, training, mentoring, and reassessments of the team members throughout.

For additional information, a second part of this series will be a webinar about how to successfully manage requirements in a globally distributed team. There are additional posts about the skill set, the profile of a good product manager, and building a requirements analysis team on the ArgonDigital Blog page – https://argondigital.com/blog.

Case Studies On Growing Skill Sets

Alice: A beginner without a technical degree and no formal training program

Four years ago, Alice was a very junior product manager when she joined the team. She was a scientist by training, with a degree in biochemistry and some self-taught knowledge around simple software development. She fell into the category of “beginner without technical experience”. Her first project in the organization required that she become an expert in the subject matter very quickly by reading materials and interviewing other subject matter experts. Using that knowledge, she had to help create re-usable content on that subject matter.

The organization was inexperienced at working with beginners, so for the most part, Alice learned by working with the organization’s two most experienced product managers. She did not take any formal training courses. One year after starting in the organization, Alice worked with her mentors to help build a training course on basic requirements skills. In the process of building and teaching the training, she further solidified her learning experiences. Now in current day, Alice is considered one of the organization’s best requirement experts who teaches and mentors others.

Bob: A beginner without a technical degree and with a formal training program

Recently, Bob joined the same organization as Alice, as another junior product manager with a background in physics. He does have a couple of years of experience of working in the industry in a different profession, which means his primary training will be around requirements skills and the software development lifecycle.

To learn the skills, he was immediately added to a project to work with more experienced product managers. His job entailed taking co-workers’ elicited requirements and formally documenting them in a requirements management tool before the customers reviewed them. This gave him experience in interpreting requirements, understanding how they were written, and how they should be modeled in a tool structurally. It was a simple introduction to requirements. He also had the opportunity to attend three requirements courses (on the topics of requirements basics, elicitation, and visualization) in his first four months in the role. The basics class was in his first few weeks in the role, and actually, he did not do well on the post-test for that course. However, after being in the role for a month to internalize the concepts taught, he was able to pass the post-test very easily without retaking the course.

The expectation is that Bob will continue to work very closely with more senior product managers for the next year or two to further develop the skill set using a mentoring format, before being a lead product manager on a project.

Carol: An experienced professional at requirements analysis

Carol joined the organization two years ago, coming from another organization where she was a senior product manager. During the interview process, it was clear she would be a strong contributor on projects immediately. The obvious learning path with Carol is to align her skills and methodologies with those of the organization, so that she can execute on projects in the same way as others in the organization and be a mentor to the more junior product managers as soon as possible.

Carol attended all of the same courses as the junior product manager, but with a focus on both learning the same language to talk about the organization’s methodology and to learn to teach the courses. Within the first few months in the organization, Carol was acting as a mentor to other product managers to help them grow their requirements skills. Today Carol is closely aligned with the organization’s methodologies and helps to create the training courses for product managers at all levels.

References

¹ Wailgum, Thomas. “Why Business Analysts Are So Important for IT and CIOs”. CIO 16 April 2008.

² IAG Consulting. “Business Analysis Benchmark Report”. 2008.

³ The Standish Group. CHAOS Report. 2004. Available: https://www.standishgroup.com.

⁴ Boehm, Barry. Software Engineering Economics. 1981.

About ArgonDigital

ArgonDigital is a professional services company that helps companies build software that their customers love to use. Leading companies turn to us to identify and delineate their needs because of a proven approach to software requirements that saves you development dollars and maximizes resources. ArgonDigital gets the requirements right, so our clients get their software right.

For a free consultation with one of our product managers, please feel free to contact us at info@argondigital.com.

About the Author

Joy Beatty has deep knowledge of all aspects of the software development life cycle, particularly with online and offine sales applications, pricing applications and ecommerce solutions. She has been instrumental in developing a strong methodology at ArgonDigital for use case development and requirements gathering.

Print or Save to PDF