– See All Project Management Key Concepts –

The Requirements Traceability Matrix

What is the Requirements Traceability Matrix? It’s a grid or a matrix that links the product requirements from their origin to the ultimate scope we’re going to deliver. It’s a list of the requirements that we’ve gathered from our stakeholders and our customer, and it links those to the deliverables that we are ultimately delivering as part of our project. We’re seeing that those deliverables satisfy the requirements we gathered.

It also provides a structure for managing any changes to the product scope as the project goes along. So why do we do this with this requirements traceability matrix and why do we create this? Well, it helps us ensure that each requirement adds business value by specifically linking it to the business and project objectives that we are delivering. It also provides a structure for managing those changes as we go along.

The process of tracing those requirements will include a few different things as you go along your journey. First of all, we’re gathering the business needs, the opportunities that we have the goals and the objectives of the project, the project objectives and the project’s scope and work breakdown structure deliverables. So we’ve got our requirements with the project scope which is broken it down further into the actual small deliverables that each individual team will be working on and delivering. That’s the most we can break it down to make it nice and easy for people to work on, in small increments.

We’ve got the product’s design – what is it going to look like? The product development test strategy and test scenarios, because we’re looking at the acceptance criteria. How does that link back to those requirements? That’s a very important part of the test strategy, to make sure that those requirements are validated and those deliverables are validated by our customers.

Lastly, the high-level requirements to the more detailed requirements. There are a few attributes that we will put into this Requirements Traceability Matrix, and that will basically help define the key information about those requirements. So these attributes will include a unique identifier – maybe it’s number 103 for example or F75 whatever the actual identifier is that makes sense for the project that you’re working on.

We’ve got a textual description – so an actual description of that particular requirement, and the rationale for its inclusion, who owns that requirement and where it’s come from, the priority 1 to 5 is usually a good measure, the version of that requirement or the version of that deliverable, the current status and the date. Then when we’re looking at that we still also need to match that to the deliverables.

And that is the requirements traceability matrix.

– David McLachlan

– See All Project Management Key Concepts –

– See All Project Management Key Concepts –

The Project Scope Statement

What is the project scope statement? It is probably one of the most important documents that you’ll find in your project management plan for a couple of reasons.

The project scope statement is the description of the project scope, and the description of the major deliverables that we’ll be delivering as part of this project. It includes any assumptions that we have made in the idea of finding the scope, and also any constraints that we know about.

It’s a really clear picture of what we’re going to be doing as part of our project. The detailed project scope statement includes these things:

The scope description, which is progressively elaborated. That means we could iteratively improve this as time goes on. We might find more items here or there and ultimately then we’ll have our scope statement, but we will have iteratively worked on it and improved on it over time.

Once it gets to a certain stage that we’re happy with, and our stakeholders are happy to lock that in its locked in as a baselined document, which means that any future changes need to go through an official change control process, usually signed off by the project sponsor.

We have the project deliverables, so what are we actually delivering? The acceptance criteria – what is the definition of done for these particular deliverables? How do we know when they’re complete?

Then any exclusions that we have in that scope. Maybe we’re not delivering a certain part, and defining that upfront really helps us so that we don’t have any scope creep as that project goes along.

Now why are we creating this? The scope statement basically enables a product team to perform more detailed planning on the scope, and it guides the project team’s work during the execution of the project. It provides the Baseline once we’ve locked it in, for evaluating whether requests for changes or additional work are contained within or outside of the projects boundaries. You will see this a lot in your project management career.

In any project there are many different stakeholders. If you have a baselined scope statement and all of a sudden a customer or a stakeholder says “I really want this item, and I want this item too,” if we’ve got a really solid scope statement so we know what is in scope and what’s out of scope then we can say “Yes, we can definitely work on this piece, maybe we can even work on this piece, but this one is specifically excluded.”

If you want to make a change, you have to raise that change request and go through our configuration management process. That is why it’s so important to have a project scope statement and work with that as we’re going along on our project.

– David McLachlan

– See All Project Management Key Concepts –

– See All Project Management Key Concepts –

Product Analysis

Product analysis, which is also the solution analysis because the product is what we’re going to be delivering, is the solution from all the requirements that we’ve gathered from our stakeholders. This is how we analyze and start creating that product and the idea of that product and solution.

What is product analysis?

First of all it can be used to define the products and the services that we’re going to be delivering as part of our project. Being a project manager it includes asking those questions about the product or service and forming answers to describe the use and characteristics and other relevant aspects of what is actually going to be delivered. Keep in mind we’ve already gathered the requirements, or what our customers want. But that doesn’t mean that we actually have a solution or a product in mind. We have to turn those requirements into a solution that ultimately a customer can see, feel and touch.

There are a few different techniques to product analysis techniques, and these might include product breakdown, which is breaking down the idea of the product into smaller pieces.

Requirements analysis which is going into those requirements and really breaking those down and matching those up to key pieces of our solution.

Systems analysis, which are the systems that we’re working with – do we have any limitations there?

Systems engineering, where we’re looking at the architecture behind things, and how we can actually engineer this product.

Value analysis, so are we might be rating from one to five and this is where the key concept of voting comes into it as well. Maybe we’re voting for the value of the particular requirement that we’re wanting to put into this solution.

Value engineering, or how can we engineer the most value out of this particular product with the least amount of effort?

As you can see there is more than one accepted method for translating these high-level product or service descriptions into meaningful deliverables. When we’ve got the idea of our solution, we still actually have to break these down into smaller pieces so that our teams can start working on those smaller pieces, and deliver those smaller pieces bit by bit. Requirements are captured at the higher level and they’re decomposed, which you’ll see is a project management body of knowledge key concept as well. They’re basically broken down into the level of detail that is needed to design and deliver the final product.

And that is the idea of product or solution analysis.

– David McLachlan

– See All Project Management Key Concepts –

– See All Project Management Key Concepts –

Voting

What is voting? You’ll come across this in your project management career when we’re gathering requirements, and in other project process group areas as well. Voting is a very common way to get to a decision when a decision is need needed to be made. The way it’s described in the PMBOK guide is a “collective decision-making technique”. It’s an assessment process where we’re able to assess a few different options and see which option we actually want to move forward with.

When we have multiple alternatives, those are our options, with an expected outcome in the form of future actions. In other words, what are we going to do in the future? If we can’t all agree (and sometimes that’s totally fine) but there are other ways that we can move forward, and that’s what we use voting for.

These techniques can be used to generate, classify and prioritize your product requirements in the early days as you’re gathering these requirements for your product and your project. There are a few voting techniques that you’ll come across and that you’ll see in the PMP exam and the CAPM exam.

We’ve got unanimity, where where everybody agrees – so you’ve got the a hundred percent of people and everyone is happy, everyone agrees that they’re going forward. You have unanimity, they’re unanimous.

But you may not have that in your case, so the next step down from that is where we have the majority of people. This is where a decision is reached where and more than 50% of the members of the group agree. Instead of a hundred percent now we have more than fifty percent, and we’re able to move forward because that is the majority of people.

Now even then if you’ve got a large group of people, or maybe there’s a lot of different decisions to be made, you may not have the majority. So the last one is plurality.

Plurality is a decision that’s reached where the largest block in your group decides. Maybe you have 30% of the people agreeing for that particular decision and then all of the others are 20%, 10%, 5%, another 20% and whatever else it takes to make up the hundred percent. But none of those are a large enough block to get to that thirty percent, which is the largest block. And that’s the one that you’re able to move forward with.

There is a variation of voting. Voting is used throughout many different projects life cycles including the agile, iterative or incremental life cycles. One variation that they use is the fist of five.

The Fist of Five

The fist of five is where the project manager simply asks the team to show their level of support for a decision (i.e. your future actions, what are we going to be doing) and holding up a closed fist which would be no support, or five fingers which would be full support for a particular decision, or any fingers in between. The power of doing it this way is that if a team member holds up fewer than three fingers, then that team member is given the opportunity to discuss their objections with the team, and that gives them a voice. Maybe they advise of some risks or some ideas that other people have not thought of, that we need to consider as a team. The project manager can continue that until the team achieves a consensus or they agree to move on to the next decision, because maybe they haven’t agreed. They have achieved a majority for example or a plurality.

And that is the idea of voting in your project.

– David McLachlan

– See All Project Management Key Concepts –

– See All Project Management Key Concepts –

Prototypes

What is a prototype? Prototyping is a method of obtaining early feedback on our requirements. Looking at the requirements that our customers have given us, we’re actually building a small model, providing a model of that expected product before actually building the big product where all of the dollars are spent. It might be very expensive to build the actual product itself, but it might only just cost a tiny bit to build a model of that product so that we can get feedback on it and see what it’s actually like.

So why do we build a prototype, or why do we do prototyping?

It allows our stakeholders and the project team and the project customers who we’re delivering the business value to, to experiment with a model of that final product rather than being limited to just discussing those ideas. How many times have you sat in a meeting where you’ve got dozens of people and they’re all saying this and that – this way is the best, that way is the best. But now we’re actually just building a small model of those ideas so that we can see, feel and touch it. Now we can really understand whether it’s fit for purpose instead of just talking about it.

When it’s only talk, maybe someone who was just the loudest voice in the room might get their way instead of us actually seeing whether it’s fit for purpose or not.

In an agile environment or an iterative environment, prototypes also support that concept of progressive elaboration. We’re mocking up the item, we’re allowing our users to experiment with the item and then we’re getting that feedback. Ultimately that helps us refine the prototype. We’re putting that feedback back into the prototype instead of spending all that money on revising the final product itself.

There are a few examples that we can use for prototypes. We might build a small-scale product, we might do a computer-generated 2D or 3D model that we can see and move around and change. We might have floor plans or a model of a car or a house that we can see and actually walk through with computer-aided drawing for example.

We’ve got mock-ups of websites or the flow of something using storyboards, and ultimately we’ve also got simulations, potentially 3D simulations or even just experiences that we can talk through or walk through. One of the most common ones that you’ll see in a software environment is a storyboard. You can mock up a website in a small form and call it a Minimum Viable Product (you will see this term a lot) that’s from the Lean Startup and also an Agile terminology that you’ll see. We can storyboard that product which is a prototyping technique. It shows the sequence or navigation of our item through a series of images or illustrations. In software development storyboards use mock-ups of those screens to show the navigation paths through various web pages, screens or other interfaces. We can actually click on on this thing even though it’s just a picture, and then it will take us to the right place so we can understand the flow, how it will look on a very basic basis. But still it’ll give us an idea, and we can use that to adjust before spending all our money on the final product.

And that is the idea of Prototyping.

– David McLachlan

– See All Project Management Key Concepts –