The Project Management Corner

Requirements management is a critical part of executing a project. PMI’s research has shown that poor requirements management is a major cause of project failure. Apart from defining a good requirements management process, project managers must also recruit a team of skilled business analysts. The elicitation and the management of the requirements can define the entire course of the project and the capability of the business analyst team is crucial to success. As project managers we have to be able to spot good business analysts and know the vital qualities that distinguish them.

Here are the five essential skills that a good business analyst should have.

1. Analytical skills

A Business Analyst must be able to dissect a requirement, analyze its impact on the system and understand how it fits into the overall business objectives. Analytical skills are the livelihood of the business analyst. Even the greenest BA must have some level of analytical ability to take up the role. An experienced BA should know how much to analyze and be able to establish what is needed to implement the requirement. The BA team cannot be in a state of analysis-paralysis, not knowing when to end the analysis process. They must have the ability to keep the objective in mind and set an exit point for the analysis as well as guide the business users to do the same.

2. Communication

Business Analysts must have excellent communication skills. They spend a great part of their time communicating with clients, team members and other stakeholders, from eliciting requirements to discussing solutions to building  a consensus. The BA has to be able to communicate clearly and confidently with business teams and technical teams alike. They have the responsibility of eliciting the requirements from the client which can set the entire course of the project. Any gaps in communication can lead to serious problems and have an impact on the product  to be delivered. Project Managers therefore have a responsibility to ensure that the BA team has the necessary level of communication skills for the role.

3. Ability to build relationships

As the liaison between the team and the business users the BA should be able to build relationships and share a good rapport with all parties. They have to elicit the requirements from the business users and then convey them to the technical team. For a BA to conduct both of these activities successfully they must engage and build good relationships with everyone they interact. At times the BA may even have to mediate disagreements between business users and technical teams or development and quality assurance teams and get buy-in from all groups. The BA who can develop strong relationships and work collaboratively with everybody will be a great asset to the project.

4. Technical know-how

Business Analysts should have good technical acumen and knowledge of the technology being used to build the product. Sound technical ability will help the BA to translate the requirements from the business side to the technical team easily. Having knowledge of the underlying technology will increase the BA’s ability advice the client about technical limitations and propose alternative solutions during the requirements elicitation process. Moreover it will enable the BA to work more closely with the development team.

5. Domain knowledge

Another important skill for a Business Analyst is strong domain knowledge of the relevant system and industry. Lack of domain knowledge can cause problems with the requirements which in turn will have an adverse effect on the overall project. A BA who lacks domain knowledge will usually take everything the client says as-is and will not be able to advise or provide input. With sound knowledge of the domain a BA can work confidently with the business team, understand the business objectives, ask the right questions and improve the overall quality of the requirements.

What are the other skills that you think are important for a BA to be successful? Please share your thoughts in the comments.

Creating and maintaining a requirements traceability matrix (RTM) is not a simple task. It is time consuming and requires a considerable amount of effort and commitment from the project team. In my experience, the RTM is one of the artifacts that is frequently out of date and constant reminders are needed to ensure that it is updated by the team. The RTM has its uses, but I find that project teams rarely use it. The sheer effort that is required to maintain the document deters the team and if it is not a deliverable to the client, the traceability matrix is usually ignored.

For organizations that follow enterprise quality management systems such as CMMi, it is compulsory to have traceability procedures. As a result the RTM becomes a mandatory artifact for software projects. However, whether it is actually used by the project team for its purpose is uncertain. Stakeholders generally view the RTM as something to be implemented to comply with standards. Consequently project teams spend less effort on traceability leading to an artifact that is not useful.

What are the key components of a RTM? A comprehensive requirements traceability matrix should include the following.

• Business objective
• High-level Use case / Use case #
• Requirement ID / Description / Type of requirement / Source
• Risks
• Dependent requirements #
• Design reference #
• Implementation class / module
• Unit test cases
• Integration test cases
• Implemented release / release #
• System test cases
• User acceptance test cases

Most RTM templates will not include all of these components. Organizations can customize the template according to their needs and may choose to add or remove certain elements. However, for the RTM to be complete and useful, I believe that all of the above components are required.

Given the amount of information that has to be included, it’s easy to see how cumbersome it can be to maintain the document, especially in large, complex programs. Not surprisingly, there will be resistance from the project team to keep the RTM up to date.

Here are some of the advantages and disadvantages of the RTM.

Advantages:

• Maintain forward traceability to ensure the completeness of the implementation.
• Requirement changes can be traced forward to associated requirements and all the work products that are impacted by the change.
• Reduces the effort required to do a thorough impact analysis.
• Reduces risk that one of the affected work products is forgotten which may result in an incomplete implementation of a change.
• Maintains backwards traceability to ensure that the product remains on the correct track with regards to the requirements.
• Ensures that the scope of the project is not expanded by adding design elements, code or tests that are not specified in the requirements.
• Implementation changes / new technical solutions can be traced backwards to the requirements and the business objectives to ensure that it is within the scope of the product.
• Defects can be traced back to determine if it is a code, design or requirement defect and what other work products might be affected.

Disadvantages:

• Additional effort required to create and maintain the RTM and update it regularly.
• Capturing requirements traceability becomes complex and expensive as the product grows in size and complexity.
• Maintaining traceability through changes to the system can be challenging as all changes have to be updated in the RTM.
• Manual traceability methods can lead to incorrect requirements traceability data.

In my view, the benefits outweigh the drawbacks. Investing the additional effort and cost to maintain the RTM will help to prevent problems arising from lack of impact analysis, incomplete implementation, expanded scope etc. during project execution. If the benefits of the RTM are clearly understood by the project team and other stakeholders, there would be less resistance to implementing it. I believe this can be achieved through proper training regarding the importance and benefits of the RTM. As projects become larger and more complex, maintaining traceability becomes more vital.

Have you implemented a requirements traceability matrix in your projects? What are the pros and cons that you have experienced? Please share your thoughts in the comments.

References:

1. Requirements Traceability Matrix - http://www.tutorialspoint.com/software_testing_dictionary/requirements_traceability_matrix.htm
2. Why Software Requirements Traceability Remains a Challenge - http://static1.1.sqspcdn.com/static/f/702523/9188499/1288392919397/200907-Kannenberg.pdf?token=0cOV5UTB4kPtIijp6g16fgqSAlo%3D
3. Why is it necessary to use a traceability matrix? - http://www.chiron-solutions.com/chiron-professional-journal/2011/01/27/why-is-it-necessary-to-use-a-traceability-matrix/