Select Page

Categories

Requirements Traceability Matrix – RTM

Requirements Traceability Matrix – RTM
By Tom Carlos (PMP)

Defining the RTM

The Requirements Traceability Matrix (RTM) is a tool to help ensure that the project’s scope, requirements, and deliverables remain “as is” when compared to the baseline. Thus, it “traces” the deliverables by establishing a thread for each requirement- from the project’s initiation to the final implementation.

The RTM can be used during all phases of a project to:

  • Track all requirements and whether or not they are being met by the current process and design
  • Assist in the creation of the RFP, Project Plan Tasks, Deliverable Documents, and Test Scripts
  • Help ensure that all system requirements have been met during the Verification process.

The Matrix should be created at the very beginning of a project because it forms the basis of the project’s scope and incorporates the specific requirements and deliverables that will be produced.

The Matrix is considered to be bi-directional. Read the Complete Article

Business Requirements: Documenting the Business Side of Projects

Business Requirements: Documenting the Business Side of Projects
By Ben Snyder, CEO of Systemation

While many business projects are IT-related, more and more are being initiated and funded by lines of business, from marketing to finance and beyond. If you’ve ever dealt with new or conflicting requirements midway through a project—or even after the project was finished (or so you thought)—then you’ll quickly see the value of a good business requirements document. It’s your best ally and tool for making sure the project that’s ultimately delivered is what the business really needs.

Business Requirements Align Projects With Business Needs

Let’s say you’ve been tasked with a finance-related project. The sponsor will be a finance leader, but there’s a good likelihood that the project will be managed by someone outside of finance.

The project manager and his or her associated organization will typically follow formal project management practices and develop a project charter and project plan. Read the Complete Article

Business Analysis – Part 2

Business Analysis – Part 2
By Keith MathisPM Expert Live

As we continue our look at the Business Analysis knowledge areas, this month we will look at the next two sections: Requirements Management & Communication and Enterprise Analysis.

Requirements Management and Communication

Requirements Management and Communication involves making sure that all stakeholders understand the nature of a solution and agree on the requirements that the solution will meet.

Requirements Management and Communication Tasks

  1. Manage solution scope and requirements – Obtaining and maintaining consensus among key stakeholders regarding the overall solution scope and the requirements that will be implemented is the first step to this knowledge area. All requirements must be assessed to verify that they fall within the solution scope. If additional requirements are invalid, the business analyst must resolve the difference.
  2. Manage requirements traceability – You will now create and maintain relationships between business objectives, requirements, other team deliverables, and solution components to support business analysis or other activities.

Read the Complete Article

Requirements Defect or Scope Creep?

Requirements Defect or Scope Creep?
By Kiron D. Bondale

If you have managed a number of projects the following scenario is likely one which you have encountered. A requirement which was not previously identified emerges after project baselines have been approved, and when you try to follow good project change management practices, your customer informs you that this was not a new requirement but rather one which was missed during the requirements gathering process?

Depending on the approach taken for your project, this may or may not be a big deal.

If you are managing a project using an agile methodology, so long as the requirement does not generate a significant change to architecture, design or delivered value, it is usually just a matter of adding this item to the backlog and then asking the customer to re-prioritize the backlog at the end of the current sprint or iteration.

But let’s say that your project was following a waterfall approach or that this recently identified requirement does severely impact foundational work completed on an agile project. Read the Complete Article

Q&A: The Project Manager as Business Analyst

Q&A: The Project Manager as Business Analyst
By Dan Stober, PMP, Global Knowledge

Attendees of last month’s webinar “The Project Manager as Business Analyst” had a lot of great questions for PMP-certified Global Knowledge instructor and webinar host, Dan Stober. So great, in fact, we decided to share them, along with Dan’s great answers.

Q: Speaking of building something that doesn’t meet the business need, can you talk about how this fits in the Scrum/Agile method?

A: Many times, especially in software development, the finished product doesn’t look anything like the original vision. Usually this comes from either expanding scope or poor initial requirements development. What we want, in the end, is to build a product that meets the business need. But, many times after every stakeholder get his/her wish list into a product, we find that many of the features/functions are not a business necessity.

Q: If the project manager (PM) writes the requirements charter, how does it give them authority? Read the Complete Article

PM and BA Roles in Requirements and Project Communication

PM and BA Roles in Requirements and Project Communication
By Dan Stober, PMP, Global Knowledge

Communication is vital within projects and contributes significantly to project success.

Project managers (PMs) know that they have to construct a robust communication management plan for the overall project. The communication management plan should be designed in such a manner that it defines how project information will be handled: how the project team collects, generates, stores, distributes, and disposes of project information. Considerations will include who gets what information, when, why, in what format, and how and where project information will be archived.

For the business analyst (BA), communication management revolves around communicating requirements, which A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) v2.0 states, “is essential for bringing stakeholders to a common understanding of requirements.” Of the primary underlying competencies of the trained BA, a thorough understanding of verbal communications, teaching skills, and written communications is among the most essential. Read the Complete Article

4 Tips for a Sustainability-driven Requirements Gathering Process

4 Tips for a Sustainability-driven Requirements Gathering Process
By Gratien Gasaba

A killer question about project sustainability is on its requirements. Project requirements are the cornerstone for sustainability. If the requirements gathering process does not include measures to ensure lasting solutions to problems, the opposite may occur. Analyzing requirements with focus on long term goals will increase chances for sustainability. Other important questions are those about the weight given to each sustainability dimension, how the requirement gathering process starts and tools used as well as the documentation of sustainability related acceptance criteria.

  • Tip 1: Have a sustainability checklist for each dimension

    Before the requirement gathering process starts, it is advised to have a checklist at hand. The checklist will guide the team involved in the requirement gathering process. A good sustainability driven checklist will consist of questions about how the project tackles the four sustainability dimensions. This checklist is a tool that can help those involved in the requirement gathering process to be more consistent with sustainability aspects.

Read the Complete Article

Requirement Management: What Did We Do Wrong?

Requirement Management: What Did We Do Wrong?
By Mohd Rizal Abu Bakar and Noor Jehan Mohd Nidzam

At some point of our projects; when our project is delayed, when our project is facing budget overrun, when our project is at the edge of failure; we will be asking this question to our selves, or our boss will be pushing this question to us; What did we do wrong?

META group (META Group, Inc., acquired by Gartner Inc., provides information technology research, advisory services, and strategic consulting services) is indicating that 60%-80% project failures can be attributed to poor requirement management. IAG Consulting, being more precise, indicating that 68% project failures are due to poor requirements. Wieger, 2001 study points that 50% of product defects originate in the requirements and 80% reworks can be traced back to requirement defects. So, high chances that the challenges to our projects are due to the quality of our projects’ requirements and how did we manage the requirements. Read the Complete Article

Project Management – Collecting Requirements

Project Management – Collecting Requirements
By Sue Cochran, Northwest University

In my opinion, defining Scope is the most difficult part of planning the project. You would think it would be fairly simple. Your sponsor comes to you with something that needs to be done. He can’t figure it out in the normal process of business so he wants you to do a project. You agree to have a meeting to talk about it.

The day of the meeting arrives and you know you need to Collect Requirements for the project. You are prepared to take notes, expecting to get a list of things so you can begin your Project Charter document or at least an initial proposal. The sponsor begins the meeting with a comment about how excited he is to see this happening, how he has waited a long time to see this happen, how it has been a “dream” of his to accomplish such a project. Read the Complete Article

Project Management: Da Vinci’s Requirements

Project Management: Da Vinci’s Requirements
By Andrea Brockmeier

Leonardo da Vinci has been described as the archetypical renaissance man. He was a man of unquenchable curiosity, unmatched imagination, and is arguably the most diversely talented person who has ever lived. Certainly known for his painting skills (The Mona Lisa, The Last Supper), his appetite for knowledge did not stop there. He branched out into other professions as well: sculptor, mathematician, inventor, writer, engineer, musician, and cartographer to name just a few. I would add to that distinguished list the role of business analyst. I believe there are a few lessons we can learn from Leonardo both in his approach to life and work.

The most obvious connection of Leonardo and business analysis is his documentation. It has been found that he did over 100,000 drawings and 6,000 pages of notes. He was thorough, detailed, and he used a combination of approaches; text, models, diagrams, sequences, stories, prototypes, all things that we do today. Read the Complete Article

Recommended PM App

Recommended PM App

Categories