Project Estimating Techniques

You will definitely see project estimating techniques mentioned as part of the PMP exam, so it’s good to know the four main different types and the differences between them.

Throughout your project you’ll be asked to make those estimations of future performance, and that could be in your Schedule, it could be in the Cost of the project, it could even be in the quality of your project. The four main methods that you will come across as part of the PMBOK guide are:

Parametric estimating
Bottom up estimating
Analogous estimating, and;
3-point estimating.

They might sound a little bit funny at first, so let’s go into them in more detail.

First of all we’ve got parametric estimating. This is where we’re actually using a parameter to estimate per item. So it’s a simple parameter, for example 55 meters or $55 per square meter or square foot. We might have a thousand dollars per roll of metal, or twenty days per delivery in our schedule for example, where it might take to get something to another country. We might be looking at two-week sprints per each feature that we’re delivering in a software project, or a team might take an eight-hour workshop to complete a risk assessment. All of these are parameters that we might assign to the activities so that we can estimate for those activities.

Next up we’ve got bottom up estimating. This is where we’re estimating project resources by assigning a value to the lower-level components of the Work Breakdown Structure. We’re starting from the bottom and we’re working our way up. And when we say the bottom we mean the the lower level tasks that have been assigned to our teams. Now these of course go up in the work breakdown structure to the larger tasks or features, and then to an overall delivered feature (and this is where we start getting into Agile potentially or Feature Driven Development) but the idea of that is that this team can estimate on their piece of work, this team can estimate on their piece of work or their single task or one or two tasks, and that might be say $10,000, this one might be $20,000, this one might be $5,000, and then we take all of those items and we bring them up into the feature so the total there could be $50,000 and then the total for the overall feature could be $100,000 for example. But the key is that we’re starting at the very lowest level of the activity, we’re starting from the bottom.

Next up we have Analogous estimating. This is where we’re finding an analogy, something similar to what we’re currently doing. We’re estimating the duration or cost of an activity or a project using historical data from a similar activity or a similar project. Of course this is frequently used to estimate project duration when there is a limited amount of detailed information, so we haven’t gotten down into the Work Breakdown Structure yet at the team level, we only have a really high-level idea. Using Analogous Estimating we can get a rough idea of how much it will cost, or how long it will take by looking at another similar project. It’s like an analogy, it’s similar to what we’re currently doing. Generally it’s less costly and less time-consuming than our other techniques, but also it is less accurate because we’re not really delving into the detail.

Last but not least there is 3-point estimating. This uses an average of three points – we might have the Optimistic estimate, the Pessimistic estimate, and the Most Likely estimate. The way that we end up working it out is: Let’s say our Optimistic schedule (O) is five days, our Most Likely (M) is seven days and then our Pessimistic (P) is ten days. We add each of them together and then we divide that by three, and that gives us the answer.

In fact here’s a better version that doesn’t take as much math or any decimals – let’s say we’ve got five, nine and ten divided by three – because 24 is a nice round number – we divide that by three and we get eight. And that’s how we do three-point estimating.

You might see a variation of this which is “Beta” or “PERT” (Program Evaluation Review Technique), where we’ve got Optimistic, then four times the most likely, and then our pessimistic as well, all divided by six instead.

And those are the project estimating techniques we will come across in the PMP Exam.

– David McLachlan

– See All Project Management Key Concepts –

The Four Value-Driven Delivery Principles

December 26, 2020Agile Certified PractitionerDavid McLachlan

– See all the Agile Certified Practitioner Videos –

What is it?

An Agile Certified Practitioner focuses on Value Driven Delivery – delivering value to the customer as soon as possible. There are four parts:

Define positive value
Avoid potential downsides
Prioritisation
Incremental development

Define Positive Value

This means project requirements (features) are prioritized based on value. This prioritised list forms the backlog of work. Then the development team works to deliver the most-valuable items first.

Define Positive Value: Step-by-Step

Define a customer-valued list of deliverables or features that can be produced incrementally in order.
Refine the requirements for these features by gathering their acceptance criteria – the “definition of done”.
Work to improve the team’s process over time through retrospectives, in order to optimize value delivery.

Avoid Potential Downsides

This means delivering in increments of value, so the customer can provide feedback, changes in priority, and address risks in the project incrementally too.

Avoid Potential Downsides: Step-by-Step

Organise requirements into “Minimum Viable Products” (MVPs) – small, releasable increments – in order to deliver value early.
Solicit customer and user feedback by reviewing these increments often.
Limit increment size and review with the customer frequently to confirm business value, and identify and respond to risks early and at minimal cost.

Prioritisation

This means we prioritise the backlog of requirements from most value to least value (in the customer’s eyes), and we periodically update and reprioritise with the customer or product owner so the team is always working on the most valuable items.

Prioritization: Step-by-Step

Prioritize the increments or features by collaborating with the customer (or customer-based stakeholders such as the Product Owner).
Perform frequent reviews of the backlog list to ensure it has the most value delivered first.
Continuously the team process to ensure quality deliverables.

Incremental Development

This is where the work gets done. By delivering in increments the team addresses the most valuable requirements first, addresses risk in smaller doses, ensures features are reviewed and deliver what the customer wanted, and future features are still in the right order.

Incremental development: Step by Step

Create periodic checkpoints with stakeholders to gain feedback to current and future work, by performing inspections, reviews, and/or testing .
Incorporate both value-producing and risk-reducing features into the backlog.
Elicit relevant non-functional requirements (such as operations and security) as well.
Re-prioritize requirements periodically in order to reflect changes in stakeholder needs or preferences

These four domains are the key for the Agile Certified Practitioner. Understand that the goal of Agile is to identify value, rank the value based on the customer’s needs, protect the value, and deliver value through increments.

– See all the Agile Certified Practitioner Videos –

Six Ways to Prioritise Requirements in an Agile Team

December 24, 2020Agile Certified PractitionerDavid McLachlan

– See all the Agile Certified Practitioner Videos –

What is it?

Agile project management is largely based on the development team completing the requirements from most important to least important, as picked by the customer.

We may need to help or work with the customer to prioritise these requirements, using the following tools.

MoSCoW

Must have: Needs to be included for the project to be successful.
Should have:This will add value but isn’t essential for the project to be successful.
Could have:Would be nice but we could ultimately do without.
Will not have:We can leave these until last (if there is budget or time remaining) or not at all.

Kano Analysis

Kano analysis operates on the idea of:

Delighters or attractive quality: That provide an extra special (above and beyond) experience but no dissatisfaction if not there.
Satisfiers or one-dimensional quality: Where a customer is satisfied if there, and dissatisfied if not there.
Dissatisfiers or must-be quality: the most basic requirements that customers take for granted, where the customer is dissatisfied if they are not present, but not additionally satisfied if present.

Fist of Five

The Fist of Five is a voting technique that allows the team or stakeholders to vote on requirements when a clear decision can’t be made.

The team facilitator asks the team to show their level of support for an item.
Each team member responds by holding up the number of fingers that corresponds to the level of support (five is the most).
If a team member holds up fewer than three fingers, she is given the opportunity to state their objections and the team may respond.
The fist of five continues until everyone holds up three or more fingers or agrees to move on.

Multi-Voting

Also “Voting with Dots”.

Sum up the number of requirements
Give each person 20 percent of that number in dots (for example, if you have 10 potential items to vote on, each participant receives 2 dots)
Participants put a dot next to the items they think are most important.
Sum up the dots for each requirement and rank the requirements by their votes.

You can also make the second step private, so people don’t follow the crowd or be afraid to vote on items that have received smaller numbers of votes.

Spending Monopoly Money

Spending Monopoly money gives each stakeholder an equal amount of pretend cash to spend on the different items in the requirements backlog.

Participants can put all their money on one feature or item, or they can spread it out over the items they believe are most valuable.
You then sum up the amount spent on each feature and rank them accordingly.

Lean Customer Benefits

A Lean method of prioritising requirements against the customer driven metrics can also work. Rate each requirement from one to five against the following:

1. Quality

How much will it reduce defects, reduce rework, or increase longevity?

2. Delivery

How much will it reduce the time from order to fulfillment? Or, increase the speed.

3. Cost

How much will it reduce the cost to produce the item?

Making a list of requirements and prioritising them according to customer value is a core component of Agile. Use these tools to your advantage!

– David McLachlan

– See all the Agile Certified Practitioner Videos –

Decomposition

December 23, 2020Project Management Key ConceptsDavid McLachlan

– See All Project Management Key Concepts –

Decomposition

What is decomposition in your project? It’s a technique that’s used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. You’re taking something high level and turning it into more manageable pieces, and then maybe those pieces are turned into more manageable pieces as well – that’s decomposing, we’re breaking down that item into smaller pieces.

The level of decomposition is often guided by the degree of control needed to effectively manage that project. For some projects maybe that high level description is enough, and someone can go away and work on that. But in other cases you will need to break it down so that multiple teams will work on these different items and deliver those separate pieces.

Here’s where a work breakdown structure comes into it, and decomposing from a work breakdown structure. Basically we’ve got some branches of the WBS decomposed down through the work package level. We start with the first high level idea, we’ve got a value management system project and then we have the needs assessment, we’ve got standards development, systems engineering, project management as well. As part of that needs assessment we might have a current system ordered, we’ve got requirements determination and we’ve got alternatives development. All of these things need to be done as part of that needs assessment – we’re breaking it down into smaller and smaller parts, pieces that people can actually work on.

Now of course you could do this for an organizational structure as well. You might have an executive and they might have managers at their different levels and then they might have team leaders at levels further down, and you need you might need to know this as part of your stakeholder mapping for your project.

So decomposing things and breaking things down is a very useful way to do your work as a project manager.

Decomposition of the total project work into work packages generally involves the following activities. First of all, we’re identifying and analyzing those deliverables and the related work to those deliverables. We’re structuring and organizing the work breakdown structure, breaking things down into smaller pieces. We’re decomposing those upper layers and levels into the lower detailed components, then we’re developing and assigning identification codes to the WBS components similar to our requirements traceability matrix.

We need a code just to identify that – is it 101, or is it R55? Whatever the code is that makes sense or that you have assigned to these particular items and deliverables. Then we need to continue on as part of our WBS or work breakdown structure. As we’re breaking it down, we need to verify that the degree of decomposition for those deliverables is appropriate. We do that by either assigning it to the appropriate team and making sure that they have enough information to be able to work on this. If we’re using an agile methodology then we would break it down to enough work that could be done usually during a two-week sprint, and we might have multiple two-week sprints. Can they get that done? If not then maybe we need to break it down into smaller pieces of work that we know we can get done in that two-week sprint, so that we’ve got something to deliver at the end of that iteration.

And that is the idea of Decomposition.

– David McLachlan

– See All Project Management Key Concepts –

Validate Scope versus Control Quality

December 23, 2020Project Management Key ConceptsDavid McLachlan

– See All Project Management Key Concepts –

Validate Scope versus Control Quality

The reason we’re looking at these two in particular is because validate scope and control quality can be confused during your PMP exam. So this is really quick outline of both and what the differences are when you use them so that you will know this specifically for when you get questions about these two items in the PMP exam.

Now, one of these is concerned with having the deliverables signed off (Validate Scope). We’re validating that the scope is okay, and we’re able to sign it off but the other is concerned with ensuring the deliverables are working as they should (Control Quality) – we’re controlling that quality, and we’re testing and were ensuring that they’re working in the way that we wanted them to work.

Here’s where they sit in the project management process groups. They’re both monitoring and controlling processes, and the first one is under scope because we’re validating that scope. We’re signing off that scope and it’s going back to our product sponsor or stakeholders. They’re saying “Yes, I can see that everything is fit for purpose,” and they’re giving it the tick of approval. But before it actually gets to that stage, we are controlling that quality.

With Control Quality, we’re testing it, we’re wanting to make sure that it’s OK, and that it meets the requirements that we had. As we control that quality, once that is complete then that will usually feed into the validation and the sign off of those deliverables. So as you can see deliverables are verified for quality during the control quality process, but they become the input into the validate scope process where we’re signing it off and giving that final tick of approval by the stakeholders.

So Control Quality is the testing and checking of that deliverable to ensure it meets the requirements, we’re usually testing fit for purpose. But Validate Scope is that process of formalizing the acceptance of the completed project deliverables signed off and approved by the authorized stakeholder.

And that is the difference between Control Quality and Validate Scope.

– David McLachlan

– See All Project Management Key Concepts –

The Psychology Behind Kanban

December 23, 2020Agile Certified PractitionerDavid McLachlan

– See all the Agile Certified Practitioner Videos –

What is Kanban?

Kanban in an Agile team focuses on minimising “Work in Progress”. It uses a board, where task cards are placed, and move across each column from the “Backlog”, to “In progress” to “Done”.

Kanban gives a team a feeling of Progress.

Professor Teresa Amabile

Teresa Amabile and Steven J. Kramer found in their study of more than 12,000 employee journal entries over a prolonged period of time that it wasn’t money, perks, recognition or time-off that contributed to their happiness.

It was a sense of progress, specifically progress in meaningful work.

People were also 50% more likely to find creative solutions on the days they reported their most positive moods, that came from making progress.

Dr Jason Fox

Dr Jason Fox took the idea of progress one step further, specifically:

To make progress visible.

So everyone can see it, and everyone is on the same page. It is the “Kanban Board” of a team.

Kanban gives a team Clarity on the work and what is expected.

Mihaly Csikszentmihalyi

Released a study outlining three things in place when a person experienced the “flow state”, a state of ease and happiness.

Those were:

When the person knew what to do every step of the way
The person could tell clearly and immediately if he or she had made a mistake
The skills of the person were more or less in balance with the challenges that the activity provided

Gallup

In 2015 the Gallup Business Journal studied more than 190,000 employee engagement responses and found that 50% of employees were not clear on what was expected of them at work.

Of these, only 4% were “engaged” in their work.

Companies where employees were clear on what was expected of them saw a 34% jump in engaged employees.

– David McLachlan

– See all the Agile Certified Practitioner Videos –

The Requirements Traceability Matrix

December 22, 2020Project Management Key ConceptsDavid McLachlan

– 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 –

The Psychology Behind Scrum

December 22, 2020Agile Certified PractitionerDavid McLachlan

– See all the Agile Certified Practitioner Videos –

What is Scrum?

Scrum is one of the largest parts of Agile, and involves clear roles (below), time-boxed work deliverables (two-week iterations) and a daily scrum meeting (15 minute stand-up).

The Product Owner
The Development Team
The Scrum Master

The Daily Scrum is checking in for a 15-minute stand-up progress meeting.

Stanford Health Care

Stanford Health Care struggled with losing talent in a highly competitive market and an Employee Engagement score of 42%. They had leaders focus checking in – frequent, light touch conversations about near-term future work. The more they checked in, the higher engagement was.

Fully Engaged staff members increased by 10% after just three months, and increased 14% in 7 months.

Gallup

In 2009 the Gallup Business Journal asked a random sample of 1,003 U.S. employees whether their manager focused on their strengths or weaknesses.

They found that there was a 59% drop in engagement when team-mates felt ignored by their manager. 06-Scrum-Engagement

Clarity of Roles and Work

Gallup

In 2015 the Gallup Business Journal studied more than 190,000 employee engagement responses and found that 50% of employees were not clear on what was expected of them at work.

Of these, only 4% were “engaged” in their work.

Companies where employees were clear on what was expected of them saw a 34% jump in engaged employees.

Google

In 2012 a Google project called “Aristotle” studied 180 project and engineering teams. They found the highest performing teams all had this trait in common:

“Structure and clarity: An individual’s understanding of job expectations, the process for fulfilling these expectations, and the consequences of one’s performance are important for team effectiveness. Goals must be specific, challenging, and attainable.”

– David McLachlan

– See all the Agile Certified Practitioner Videos –

The Project Scope Statement

December 21, 2020Project Management Key ConceptsDavid McLachlan

– 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 –

PMP Practice Exam Questions and Answers | 25

December 21, 2020PMP Exam Question PracticeDavid McLachlan

– See all the PMP Exam Questions –

PMP Exam Question Session 25

In this series we will walk through five PMP Practice Exam Questions each day – a great way to set up your morning as you prepare to pass the PMP Exam. It is also useful for the CAPM exam, as the content is very similar.

We will also figure them out together, and you’ll see the thought process behind solving these PMP exam questions.

I hope you enjoy!

Question 1

Communication Channels are the number of communication paths among the team members working on the project. For a project with a team of 3 people, the total number of communication channels would be:

A) 3
B) 5
C) 2
D) 4

Question 2

You are scheduling a meeting with your project team to share their viewpoints and expertise in the project work. Which of the following is NOT one of the rules of effective Meetings?

A) Schedule recurring meetings in advance
B) Set a time limit and keep to it
C) Ensure flexible time limits
D) Stick to the agenda

Question 3

You need to make a decision with your project team on how to move forward with a particular feature. You decide to take a vote, but you need to know how to ensure the outcome is valid. Which of the following is NOT one of the types of Group Decision Making Techniques?

A) Unanimity
B) Majority
C) Plurality
D) Duopoly

Question 4

You have hired a Business Analyst specifically for your project, and have asked them to create a plan of how the project will document, record and manage all the requirements. What are you asking them for?

A) Scope Management Plan
B) Requirements Management Plan
C) Integration Management Plan
D) Resource Management Plan

Question 5

The Scope Statement of your project provides a baseline of the project’s scope and deliverables and the work required for all stakeholders to see. Which of the following is NOT one of the elements of a Project Scope Statement?

A) Project scope description
B) Acceptance criteria
C) Project Selection
D) Project Assumptions

– See all the PMP Exam Questions –