Control limits, PERT & standard deviation… a bit more
In lesson 6 last night about Project Time Management, I introduced the concept of control limits and Sigma (σ - that’s the Greek symbol for Sigma). So what was that about? I observed a deafening silence when I asked for questions, but the first time I saw this as a candidate, I was totally “what just happened?”
Ok, so let’s take another look at standard deviation and how it applies in Project Management. As I said, standard deviation is usually used in manufacturing as a quality management tool.
Statistically speaking, if you were to do nothing and simply watch output from a production line, heuristics say that you would observe a normal distribution curve, that 68.3 percent of output would fall within certain quality parameters. This 68.3% is called Sigma (σ) and it is represented as part of a bell curve. If you’re using σ as your quality standard, then you know that 68.3% of your production will be within that quality standard, meaning that 31.7% of production will be of unacceptable quality.
But what if you want less wastage? There are three alternative standards, which are increasingly expensive to achieve, +/- 2σ (2 standard deviations, or 95.46%) +/- 3σ (3 standard deviations, or 99.73%) and +/- 6σ (6 standard deviations, or 99.99985%).
How does that apply to time (or cost) management? Well, as I said, if you provide stakeholders with a one point estimate, it tends to be a noose that can hang you, because they will believe you. Can you accurately predict the actual day your project will end? Probably not. So instead of providing a number, we use PERT, which indicates a range, worst case scenario, most likely and best case scenario (P, M, O). And the formula we use to calculate our timeframe takes all three into account.
(ự) = (P+4M+O)/6
Example: If P=30, M=7 & O=6
(30+(4x7)+6)/6 = 10.667
So what we’re doing using PERT is factoring risk into our timeline, mathematically. Remember how Rita said the first option for reducing the schedule is re-evaluating risk? If you can eliminate the risk, you reduce your timeline because you remove the (P) and potentially optimize the (O).
(0+(4x7)+6)/6 = 5.667
So what about standard deviation (ự)? Ok, let’s assume you’ve established your baseline – this is what we plan will happen, but realistically; things will change during execution – and this is normal. So we use standard deviation to create upper and lower control limits. Looks like this :
So in Monitor & Control Project we measure progress against the baselines to watch for deviation. In the Project Cost Management lesson we’re told we take corrective action if the measurements we take show a breach of the control limit.
Let me make this quite clear – NO. We watch for trends and take action BEFORE you reach the control limit (Shewart’s rule of 6). So in the above image above we can see a trend away from the baseline toward the upper control limit, then we have taken a corrective action (change request) which has successfully brought things back into line. Think of control limits like you’re Scotty on the USS Enterprise, in charge of the Warp Core. Hit the lower limit and the thing shuts down, the upper one and, uh, oh…. So understand you need to establish control limits and act to remain as close to the baseline as possible.
Can a Project have multiple sponsors? & Should the client be in charge of Change control?
Hi all, I wrote this way back after the second session but due to technical issues was unable to post it until now.
George asked the question about whether a project can have multiple sponsors and the answer from a PMI perspective as I said, is no. The Sponsor can be within the organisation performing the project or if the project is on behalf of another organisation, then the sponsor could well be the customer.
However, like Highlander; there can only be one, because a single individual needs to be ultimately accountable for the project. Their role is to protect the project and provide the Project Manager with the resources necessary to successfully guide it to completion. Yes, you can have steering committees, Project Boards, etc; but hierarchically speaking they sit below the sponsor (which is also true of a Prince2 environment).
Something else George said in the same question concerned me. “The customer is in charge of change control”… Should this happen? In my opinion, ABSOLUTELY NOT.
Let me explain why not. Think about the process and the purpose of Integrated Change Management in your project. The process is that you gather your requirements and have the complete set of requirements signed off by the client and Sponsor. Then you create your scope, which is the features that will satisfy the requirements. So that is what you’re going to build and it’s agreed. You then finish planning your project and with approval, proceed with execution.
During execution, you will find through Monitor & Control Project process that various parameters diverge; and this is normal. You might detect a trend away from the schedule or cost baselines, perhaps there’s a technical issue with a feature or some other element that requires corrective action. That’s when you raise a change request. But the key point is that CR’s are used to control production of the scope which has been agreed to.
Change Management should be kept internal because the client’s interest is in progress, which you will report to them on agreed periods (and alert them to issues or potential delays via the sponsor) but they don’t need - and shouldn’t, know about every corrective action you take to control the project.
So, what happens if the client is in charge of change management? They become privy to the internal workings of the project, which could raise unnecessary alarm if they don’t understand that variance and change is normal during execution. More importantly, there would be an overwhelming temptation by the client to add scope. That from a PMI perspective, is a big no-no and it has a name – scope creep.
To be clear, a client can request replacing one agreed feature with another due to a change in requirements during execution. For example, if a requirement is that the new CRM you're building needs to interface with their customer database, but during execution they retire their database system and replace it with a new one, they can redact the original requirement and replace it with a new one saying "the CRM must interface with the new database management system". Yes, change to scope, likely impact on time and cost, but a legitimate change request.
But if a client forwards a change request to add additional features during execution, that's scope creep. The only appropriate response is to decline the CR and your justification is because the new feature isn’t tied to any agreed requirement.
You can suggest that we start a new project after completion to create the new features, but the client CANNOT add features after the scope has been agreed. If you want to know what happens if the client is allowed to add scope willy-nilly, Google a NZ government project called INCIS.
Incidentally, this is why Agile exists; to embrace change by producing small, incremental deliveries of working software fast and then planning the next sprint based on customer feedback (remember Kaizen?). In an Agile environment, the client can request new features at any time. They simply get added to the Product Backlog and prioritised for a future sprint.
Following last week’s module about Stakeholder Management I want to clarify a point brought up by George. He intelligently asked “why are Issue logs not an input to “Manage Stakeholder Engagement”.
Great question. Short answer is you’re in the wrong process group. Understand that knowing the process groups, processes and Knowledge areas are critical to passing the exam.
Let’s look again at the processes.
Here’s the execution bit. Note the input called “Change Log”. What is this? It’s the output of Integrated Change Management, or a record of things that have changed and need to be/have been, addressed. Ok, so that means we have received an approved CR and we need to/have executed a change. Remember, we’re in Executing Process Group, that’s the “doing it” bit. (In fact there should be an additional input to Execution in the diagram, the Change Requests themselves which are included in, but usually disparate to the Change Log).
Where do the CR’s come from? Look at the outputs. We’re doing it, and something unexpected occurs. Ok, so something’s happened that we didn’t anticipate. So we log it in the issue log or create a CR if it’s directly related to execution – such as a problem with a feature which might require a workaround or a fix.
The issue log is an input to Monitor and Control. The result may generate a CR, particularly where it concerns a change to one of our Management plans.
So where do we create the fix? Let’s look at the inputs to Monitor and Control Project. In Execution we’re following the plan to create the project result. In Monitor and Control we’re watching what’s going on and taking action to keep things on track. So in M&C we’re changing the Project Management plan, which then requires the changes to be executed (which happens in Executing Project Process Group).
To reiterate, in Monitor and Control we’re not doing it, we’re watching it. From the information provided during execution (work performance data) we may see a discrepancy and in Execution there may have been an issue logged. In M&C (the Control part) we address the issue by creating a change which is fed back in the form of a CR. The approved CR goes back to the Executing Process Group as a Change Request to be done. It’s an approved change we’ve decided to make via Integrated Change Control (and we all know Integrated Change Control is an M&C process).
The Project scope, or one of the Management plans is then updated along with the relevant documents (scope, schedule or cost baselines or other documents).
The point? In Execution we do it, in Monitor and Control we watch what’s going on and when necessary, make changes to the plan. Those M&C changes feed back to Execution and are done as per the updated plan. So the issue Log is an output of Execution and an input to Monitor & Control.
The Simplilearn community is a friendly, accessible place for professionals of all ages and backgrounds to engage in healthy, constructive debate and informative discussions. Get your pressing questions answered,
participate in monthly contests, create polls to get a feel for the market, build your network, and more! Pull up a chair and come join the discussion -today!