The Money Files

by
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from GirlsGuideToPM.com.

About this Blog

RSS

Recent Posts

Project Scope Management Part 5: Validate Scope

3 Ways to Think About Risk [Video]

5 Non-Financial Benefits for Your Business Case

Stage Budgets (for Project Board Members)

Project Scope Management Part 4: Create WBS

Project Scope Management Part 5: Validate Scope

Categories: scope

It’s time for part 5 of our journey through the Scope Management Knowledge Area from the PMBOK® Guide-- Sixth Edition, although it does feel like once I’ve got through the whole PMBOK® Guide we’ll be on the Seventh Edition, as I know that will be with us before we know it.

Anyhow, today, we’re looking at the Validate Scope process.

You can find the previous parts here:

This will be a super-short look at the process, because there haven’t been many changes and it’s a pretty simple process.

The Validate Scope Process

This is the fifth process in the Knowledge Area. We have moved from the Planning process group to the Monitoring and Controlling process group.

What we’re doing at this point in the project is formalising the process of acceptance. As we’re in Monitoring and Controlling, we’ve got to the point in the project where something has been delivered. Now we have to check whether we’ve delivered the right thing.

Basically, you review the deliverable with the person responsible for approving it, and receive formal sign off. When you’re doing this process in real life, it’s likely to overlap with with the Control Quality process, because you have to check the deliverables match the defined quality standards before you ask a sponsor to sign them off.

So now we know what this process is all about, let’s look at what we need to perform it.

Inputs

There isn’t much that has changed from the Fifth Edition. Instead of requirements documentation and requirements traceability matrix, we just have project documents. No biggie. That means the inputs to this process are:

  • Project management plan
  • Project documents
  • Verified deliverables i.e. ones that have been through the quality processes
  • Work performance data – personally I think it’s a bit vague as to why you would need this, but it could overlap with quality requirements and the example given in the PMBOK® Guide is that of documenting number of validation cycles and nonconformities. So you could find it useful in a discussion with a project sponsor, I suppose.

Tools & Techniques

Group decision making techniques has dropped off the list of Tools and Techniques, to be replaced by generic decision making (which includes, of course, techniques for groups to make decisions like voting).

Personally, I can’t think of many (any?) situations where my project quality would be assessed by vote. The deliverable either meets the criteria or it doesn’t. However, the PMBOK® Guide does list voting as a way to reach a conclusion when “the validation is performed by the project team and other stakeholders.”

Alongside that, we also have inspection (as previously in the Fifth Edition).

Outputs

Once again, there are no new or changed outputs to this process.

The outputs are:

  • Accepted deliverables
  • Work performance information
  • Change requests
  • Project document updates.

Of these, the most important for me is the accepted deliverables. The formal documentation for sign off of a deliverable is used later in the process for closing down the project, because you can’t close a project if the deliverables haven’t been accepted.

Next time I’ll be looking at the sixth and final process in this Knowledge Area: Control Scope.

Pin for later reading:

validate scope management

Posted on: November 11, 2019 08:59 AM | Permalink | Comments (4)

Project Scope Management Part 4: Create WBS

Categories: scope

project scope management

It’s time for part 4 of our journey through the Scope Management Knowledge Area from the PMBOK Guide®-- Sixth Edition. Today, we’re looking at the Create WBS process.

You can find the previous parts here:

The point of this process is to move from having the scope statement (from the Define Scope process) to a scope baseline. The Work Breakdown Structure (the WBS of the process name) gives you the baseline for what the project is going to create. It’s scope, but in a lot more detail than a scope statement.

Personally, I don’t often use the full WBS process. If you are on a small project, or leading a project where you have done similar work in the past and are working with an experienced team, or you have a scope that isn’t easy to button down, then approach the WBS process with an open mind. I have lost too much time in the past creating a full WBS and WBS dictionary, with lovely descriptions of everything, only to find that the next week the scope changes due to the whim of senior management, and all my work is rendered pointless. So this is definitely a process where tailoring comes into play, especially if your ‘predictive’ environment isn’t really that predictive!

You need a scope baseline in order to exercise change control, but you might not need to follow this process to the letter to get it. Just sayin’.

Create WBS Process

This is the fourth process in the Knowledge Area. We are still in the Planning process group.

While I might not use the full WBS process and terminology, the overall objective of this process is to break down the work into smaller components that are more manageable to deliver. You take your scope statement and basically turn it into chunks of work that people can actually do.

This is a process you can do at various points in the project so you might not be able to decompose everything at the beginning and that’s fine. Repeat the decomposition effort as you move through the project and more scope is known, or you find out you have to break it down further to get where you want to be.

Inputs

There isn’t much that has changed from the Fifth Edition with this process, and in fact the only small changes are here with the inputs. The inputs to this process are:

  • Project management plan – instead of the scope management plan (the same change as we saw in the Define Scope process).
  • Project documents – these were also added to the Define Scope process, and here replace the project scope statement and requirements documentation, which are now out. We’ve seen this trend towards more generic terminology across the whole Fifth-to-Sixth rewrite, and it is to be welcomed. While the scope statement, for example, is no longer specifically mentioned, you would want to refer to it (obviously). However, there’s now the explicit understanding that there might be other documents beyond the requirements documentation and scope statement that could be useful to you at this point.
  • Enterprise environmental factors – no change here, it was on the list before.
  • Organisational process assets – again, this was previously on the list so isn’t a change.

Tools & Techniques

Nothing has changed with the Tools and Techniques. The list still remains:

  • Expert judgment
  • Decomposition.

Although if you want to get picky I think they were listed in the other order in the Fifth Edition. Frankly, I don’t think the order of techniques matters much. I have never thought they were listed in priority order.

Outputs

Once again, there are no new or changed outputs to this process.

You still end up with the scope baseline, which was the ultimate goal of doing the WBS and ‘project documents updates’, which is so broad it could include anything. However, it’s really talking about updating any documents that need a reference to the final scope.

People often think of the WBS as a diagram, but it’s much more than that. The graphic is useful, but on larger projects they can get so complicated they are difficult to interpret. Also, I’m not a visual thinker – I expect that’s another reason why me and the WBS have never really got on.

The scope baseline includes:

The scope statement – you probably won’t need to amend this much from previously, but you might want to check it over as you work through the detail of the scope, to make sure it remains consistent.

  • The WBS
  • The work packages
  • The planning packages, if you need to describe work without schedules (because the work package should have schedule information in)
  • The WBS dictionary – a summary of all the work packages so you can easily reference them.

I do like the idea of work packages, and I do use this concept on my projects. If the language of work package isn’t understood, I create a terms of reference which covers the same main elements as a work package, and this can go to workstream leaders.

Next time I’ll be looking at the fourth process in this Knowledge Area: Validate Scope.

Pin for later reading:

Posted on: October 08, 2019 09:00 AM | Permalink | Comments (2)

Deep Dive: Project Scope Management Part 3: Define Scope

Categories: scope

define scopeIt’s time for part 3 of our journey through the Scope Management Knowledge Area from the PMBOK Guide®-- Sixth Edition. Today, we’re looking at the Define Scope process.

Check out the previous parts:

The Define Scope process happens early in the project so that everyone has clarity on what the project is supposed to deliver. Unclear scope means unclear expectations. And that nearly always leads to confusion, dissatisfaction and conflict on the team.

So take the time to actually define what is in and out of scope – that’s what this process is all about.

Define Scope Process

This is the third process in the Knowledge Area. We are still in the Planning process group.

Inputs

The inputs have changed slightly from the Fifth Edition, but it doesn’t feel major. The inputs to this process are:

  • Project management plan – instead of the scope management plan.
  • Project charter – which was there before.
  • Project documents – again we see the generic terminology that can basically include anything about the project. In this case, we’re talking really about the assumptions log, requirements documentation and the risk registers, as there can be useful things included in there that need to be transferred to the project scope.
  • Enterprise environmental factors – this wasn’t there before and covers things like infrastructure that might affect what systems you can install, marketplace conditions, staffing and culture.
  • Organisational process assets – this was previously on the list so is not a change. It refers to items like historical information and lessons learned that could shape the scope, along with any internal relevant policies and procedures.

The objective of this process is to create the scope statement. You are trying to take the requirements from the previous process, prioritise and review them and make a final list of what you will actually be delivering as part of this process.

It is different from the Collect Requirements process because you may have collected requirements that you cannot deliver (or choose not to deliver) in this phase. The work that you are currently doing may not extend to all the requirements that were discussed and documented. You may have to prioritise what you can deliver.

It’s the final list of requirements, plus anything else that needs to be considered and included, that ends up as your scope statement.

Tools & Techniques

Not much has changed with tools and techniques. We have:

  • Expert judgment
  • Data analysis
  • Decision making
  • Interpersonal and team skills
  • Product analysis.

Alternatives generation and facilitated workshops have dropped off the list. However, interpersonal and team skills is pretty broad and would cover running a workshop, or any kind of meeting.

Data analysis is also a broader technique than what was there before. Alternatives generation is one way of analysing data, but not the only the option. We’re seeing throughout this refresh that the terminology, tools and techniques have got broader to allow for more tailoring and personalising. I’m of the opinion that’s a good thing.

Outputs

There are no new or changed outputs to this process.

We still have the project scope statement and the project document updates.

The objective at the end of the process is to have a statement of scope. It should include what’s in scope, what’s specifically excluded from scope, and anything else you feel the need to document to ensure everyone is on the same page about what is going to be delivered.

Scope statements come in various formats, and while you’ll be able to find templates, and may even have one from your PMO, feel free to tweak and amend the document so it suits the needs of your project.

Aim for your scope statement to be really detailed, so that people can’t misinterpret what is going to be delivered. Think about what users, processes, tools, technologies, policies and so on are going to be impacted or changed as a result – and which ones won’t.

You can also include items for the scope of future phases (useful so they don’t get forgotten). However, these should be reviewed and revised at the point that the future phase is initiated, just in case the business has moved on and the scope items are no longer relevant.

Next time I’ll be looking at the fourth process in this Knowledge Area: Create WBS.

Pin for later reading:

project scope management define scope

Posted on: September 10, 2019 08:59 AM | Permalink | Comments (3)

Deep Dive: Project Scope Management Part 2: Collect Requirements

Categories: scope

collect requirements

It’s time for part 2 of our journey through the Scope Management Knowledge Area from the PMBOK Guide®-- Sixth Edition. Today, it’s the turn of the Collect Requirements process. This process happens early in the project so that everyone has clarity on what the project is supposed to deliver. It also has the output of the requirements traceability matrix, which, if you are working on a project with many requirements and moving parts, is really helpful.

I’ve only used the matrix properly on one project – much of what I do doesn’t require a full traceability matrix. So don’t feel you have to use one if it will not make your life easier and add value to the whole process.

Collect Requirements Process

This is the second process in the Knowledge Area. The term ‘collect’ doesn’t sit very well with me. I know, from talking to business analyst friends, that the language has moved towards ‘eliciting’ requirements.

Requirements aren’t simply lying around waiting to be collected. There needs to be some active involvement in finding them, understanding them and collating them into a format and structure that can be used by the project team. You could argue that elicitation is only part of this process, but personally, I prefer to talk in the round about eliciting requirements.

Inputs

The inputs have changed from the Fifth Edition, but not substantively. The inputs to this process are:

  • Project management plan (instead of the requirements management plan, scope management plan and stakeholder management plan, all of which are part of the larger project management plan.
  • Project charter (which was there before).
  • Project documents – nice and generic. Can include pretty much anything that could be useful for requirements elicitation but a starting point to look would be the lessons learned register, the stakeholder register and the assumptions log.
  • Business documents, which again covers a wide range of paperwork but PMI means the business case, I believe. As this is created outside of the formal project lifecycle i.e. before the project existed, it can’t technically be counted as a project document, but frankly I think that’s splitting hairs.
  • Agreement – contract-related project paperwork is, I think, what the PMBOK Guide® is getting at here. Any agreements you have would include requirements for products and/or the project management requirements.
  • Enterprise environmental factors (how did they manage to forget these the first time?) – covers things like infrastructure that might affect what systems you can install, culture and environment that the project needs to operate in.
  • Organisational process assets – covers things like historical information and lessons learned that could shape the requirements, along with any internal relevant policies and procedures.

The objective of this process is to create the requirements documentation – in other words, to arrive at a position whereby everyone has a clear understanding of the agreed project scope.

Tools & Techniques

While the list of tools and techniques looks quite different, I don’t think they are substantively different.

The new tools and techniques for the Sixth Edition are:

  • Expert judgment
  • Data gathering
  • Data analysis
  • Decision making
  • Data representation
  • Interpersonal and team skills
  • Context diagram
  • Prototypes.

Tools that have dropped off the list include:

  • Interviews
  • Focus groups
  • Facilitated workshops (all of which fit under interpersonal and team skills, with an overlap into expert judgment – you’d get an expert facilitator involved, for example, for a facilitated workshop)
  • Group creativity techniques
  • Group decision making techniques (which fits under ‘decision making’)
  • Questionnaires and surveys
  • Observations
  • Benchmarking
  • Document analysis (these last four fit under data gathering and analysis).

You can see why I think the lists are different, and yet… not really that different.

These are all things you can do to elicit requirements and gain consensus on what really should be in the scope of the project. You wouldn’t want to use them all, but you would pick and choose different tools and techniques to ensure you were making progress towards getting that final list.

Outputs

There is nothing new in the outputs to this process.

At the end of working through this process, you’ll have the requirements documentation and the requirements traceability matrix prepared and written (and approved). There’s nothing formal that defines what format your requirements documentation should be in. I tend to use work package description documents, product breakdown structure documentation, and sometimes simply a list of bullet points. You could use user stories.

Your requirements paperwork can be as detailed and formal as you like. Do what’s required based on the level of commitment you seek to get and the need to be specific at this point in the project. Trends and tailoring is something we’ll come to at the end of this process, but remember it applies the whole way through – you can make the process as big or small, as simple or involved as you want to.

Next time I’ll be looking at the third process in this Knowledge Area: Define Scope.

Pin for later reading:

collect requirements

Posted on: August 08, 2019 08:59 AM | Permalink | Comments (6)
ADVERTISEMENTS

"One of the symptoms of approaching nervous breakdown is the belief that one's work is terribly important."

- Bertrand Russell

ADVERTISEMENT

Sponsors