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
How to Control Change Requests
By Dave Nielsen
Changes are an important part of any project. There are 2 factors at work that guarantee the generation of change requests: changes that happen to the marketplace the project is aimed at and an unclear understanding of the goals and objectives of the project. The first factor is immutable, we can’t stop the world outside our door changing whether we like it or not. Successful projects are agile enough to respond to those stimuli and re-invent themselves so that when the product or service of the project hits the marketplace it’s the right thing delivered at the right time.
Change requests that are a result of a stakeholder’s unclear understanding of the goals and objectives of the project are easier to avoid. Clear communications about the project’s overall goals and objectives will place the project on a firm footing. Ensuring that the right stakeholders review project requirements and that the right decision makers approve them is also helpful in avoiding change requests that arise from an unclear understanding of project goals, objectives, and requirements. Read the Complete Article
Start Every Project with a Detailed Description of the Project
By Richard Morreale
Too many times I have seen Projects go bad because there wasn’t a common understanding at the beginning of what the Project was supposed to deliver – poor communication. People assume, even on small Projects, that everyone has a common understanding of the deliverable and too late everyone realizes that they don’t.
I suggest that the Detailed Project Definition should be completed before or at the start of the Project. In fact, ideally, this should be the initial definition used to brief the Project Manager as to what the Project is all about. What usually happens, though, is that the Project Manager will have to produce this as the first Deliverable and will get it agreed by whoever is sponsoring the Project. In addition, once this Detailed Project Definition is written and agreed, it should be used as the foundation to everything that follows. Read the Complete Article
Do You Understand Project Scope Management?
By Harry Hall
Project managers have difficulty managing project scope. Many project managers encounter scope creep, but don’t know what’s happening or what to do about it. Why? Frankly, some individuals don’t grasp the core principles.
Do you understand project scope management? Test your understanding. Try this quick quiz before reading the terms below.
Let’s review key terms for managing scope.
Read the Complete Article
- Project. A project is “a temporary endeavor undertaken to create a unique product, service, or result.” Every project is temporary. It’s not perpetual. Each project has boundaries in terms of a definite beginning and ending.
Program. A program is “a group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them separately.” The scope of a program is the sum of its related projects and program activities.
Product. A product is “an artifact that is produced, is quantifiable, and can be either an end item in itself or a component item.” A product may be a building, a software application, or a golf course, to name a few.
Project Scope and the Question of Quality
By Ben Snyder, CEO of Systemation
When the subject of project scope comes up, many people immediately think of the features and functions of a product or service, and maybe the results that are expected. But one key aspect that’s often overlooked is the level of quality each of the features and functions requires. A well trained project manager will need to understand the connection between the quality and scope of a project.
Quality is a critical component of project scope, because the cost and amount of resources to deliver the set of specified features and functions will depend on what level of quality is needed. And the quality doesn’t always need to be high.
The simplest example to illustrate this point is a hamburger. By definition, a hamburger is some ground beef between a bun along with maybe some cheese, onions, pickles, and condiments. Read the Complete Article
How to Keep Your Project From Being a Runaway Train
By Harry Hall
Have you ever been handed a project with too many requirements right from the beginning?
How many times have you experienced feature creep? You know the drill – you elicit and document the requirements – you receive sign off – you continue to see changes to the requirements with no controls. Many projects experience 10, 20, 25-percent change in requirements over the life of the project.
If you are successful at avoiding too many requirements or feature creep, you may still encounter developer gold-plating. Developers love to try new things even if the features were not requested, especially when they have new tools. These experiments cause adverse impacts to the schedule, budget, and quality.
Project managers pay a big price when failing to understand and manage project scope. Projects turn into runaway trains. Let’s define some terms and look at some practical steps to get you the results you’re looking for. Read the Complete Article
Product Scope vs. Project Scope
By Claudia Vandermilt
For those seeking certification in project management, there are two terms that can sometimes cause confusion: product scope and project scope. While “scope” refers to the overall goals of a project, or how we get to the point where we consider a project complete, the two constituent forms of scope are less clear-cut. Any confusion for the project management beginner is understandable, particularly since the two forms of scope do work together in some ways. This article highlights the similarities and differences between the two forms of scope with an example to help clarify the two concepts.
Product scope can be defined as the features or characteristics of a product itself. Whether considering design, function or component parts, the key point is that product scope refers to the actual tangible product. In the case of a good, questions of product scope would address how it works, how it is physically made and how it can be improved in future iterations. Read the Complete Article
Making Change Control Easy
By Andrea Brockmeier
If you struggle with a lack of sustained discipline in your project change control practice, one opportunity may be to clarify the distinction between controlling performance and managing change.
As we move through a project, two types of triggers prompt us to reach for that change management plan and tap into our change control process. To effectively respond, we need to be clear as to what type of change are we responding to and what it is we are trying to control.
Why Control Performance?
On the one hand, change control is required as a result of performance variation. In this case, we may discover that our project is not progressing as planned, so we make changes to the schedule, resource allocation, or some other variable. That is, change control is needed in response to how the project or team is performing. Here we are controlling project performance due to variations from plan. Read the Complete Article
The Charter Document – Scope
By Robin Vysma
The charter is the document you have to do before you agree to begin a project. It might be a bound glossy publication with covers and company logos or it might be in the body of an email. What it looks like and what you call it depends on the culture of your organization and the profile of your project but what’s not negotiable is that you translate decisions and the commitments required for success into an unambiguous universally agreed record of your mandate.
Today I want to talk about the scope. In a mega-project this might be a document in its own right but mostly it can be incorporated into the charter as a section. That it is done poorly is often the reason so many projects fail.
‘Scope’ refers to the boundaries of the project, ie what’s in and what’s out. Read the Complete Article
One Great Tip to Help Control Scope
By Christian Bisson
As project managers, controlling scope can be very challenging.
You’ll want to avoid scope creep but if managed properly, scope changes can mean more budget. At first glance, this seems like a good thing, and in a way, it is. But there are a few others aspects to verify.
For example, you can negotiate more time to the schedule, but this can result in the project dragging over a long period of time, and actually never end.
Another aspect to watch out more is as scope changes, team motivation diminishes. People need to close down projects and move on to the next challenge.
Still in the subject of team members, depending on how your organization work with resources, team members may not be available past the initial deadline planned. This may result in resource switches that add risk or cost to your project. Read the Complete Article