I was looking for something on the SEI website and came across a piece about Brooks’ Law that caught my attention. Brooks’ law is a principle in software development which says that “adding manpower to a late software project makes it later”. It was coined by Frederick P. Brooks, Jr. in his 1975 book The Mythical Man-Month. You may have already experienced it but never put a name to it.
I would fall under that category. I’ve seen Brooks’ Law happen first hand but didn’t know it had a name.
The vendor was doing predictive versus adaptive planning. They did a very poor job of estimating. Since the customer accepted the estimate, it was just a matter of time that the house of cards would come crashing down. As time progressed through the period of performance, we saw the vendor reach each milestone later and later. (They were following a waterfall approach) At each status meeting the vendor was pressed for an answer to the question of how they were going to recover the schedule. When it was painfully clear that the vendor could not complete the scope of work (within the alloted time), even if they convinced their people to work nights and weekends, they proposed to bring on more people to take care of the backlog of work. That’s right, they were going to bring on a small army with no experience with the customer, the program, or the product. They were going to blow the budget, in the hopes to recover the schedule on the currently agreed upon scope of work.
One stakeholder was very candid when he said, during a status review
It sounds like the plan is to throw as much [something] at the wall as you can and see what sticks.
It’s rather sad that the vendor looked at this as such a simple equation.
Team A (Input) + Team B (Input) = Team A + Team B (Output)
In reality, the equation looked more like this:
Team A (Input) + Team B (Input) = [(Team A * .75) + (Team B * .50)] Output
Have you seen Brooks’ Law on your project? What was the outcome?
I just reviewed an Integrated Master Schedule (IMS) comprised of almost 5000 lines. I didn’t write the thing. I was just asked to review it. You might be saying to yourself that must be an absolutely awesome schedule, detailing every nuance of a project. Counter to that, you might be saying to yourself that is the most overdeveloped schedule ever creating, complicating the most trivial of work.
In the business of project management or leadership, you should always be asking yourself, “does this make sense?” If it doesn’t, you should be looking for the Goldilocks approach to documentation or process. Do something that is not too complicated or simple. Do something somewhere in the middle.
As I read through the IMS, I started to think of a Rube Goldberg machine and the OK Go video titled This Too Shall Pass. Rather than reading a very straightforward schedule, identifying all of the deliverables and a decomposition ad nauseam, I saw a schedule that both inveigled and obfuscated. A Rube Goldberg machine is the perfect analogy for this schedule.
A Rube Goldberg machine is irreducibly complex. It is a single system which is composed of several interacting parts, and where the removal of any one of the parts causes the system to break down. If one component is missing, the machine doesn’t work; the whole system is useless. This is NOT how an IMS should be written. I see a schedule as a tool of transparency. It is a way to communicate if a project is on time in a passive manner. A fully resource loaded (properly decomposed) schedule can help you do a lot of other things. But 5000 lines? I don’t think so, not in this case.
Upon reviewing a vendor’s Integrated Master Schedule, created in MS Project, I noticed something very peculiar. Where some tasks could clearly be marked as Fixed Duration, everything was Fixed Units. I think there are two answers for this. Either there was a misunderstanding about the work to be performed or the person doing the schedule needs some help understanding task types. I believe working with MS Project can make your eyes bleed if you’re not used to it. But if you’re armed with just a little information about task types, it can be a whole lot easier.
I would love to go into a detailed explanation about Fixed Work, Fixed Units, and Fixed Duration. If I did, however, you’d probably leave my site never to return. Instead, I found a very helpful video on YouTube. Why go hunting for this stuff when you can just find it here?
When I was studying for the PMP exam, a few years ago, I remember memorizing a group of formulas. One of those was the “Variance of Activity.” At this point, don’t remember if it was even referenced in the exam. There were no direct questions asking “what is the formula for…” On my exam, I remember having numerous questions resulting from schedule variance calculations and cost variance calculations. To my surprise, I went searching for the Variance of Activity formula in the PMBOK (4th Edition) and I can’t find it! So as not to lead people astray when giving PMP study advice, I’m now researching each formula I was once told to memorize. I’m very surprised PMI didn’t save us a lot of trouble and list known formulas in the back of the PMBOK.
Are you studying for the PMP exam and struggling with the concept of Schedule Performance Index (SPI) and Cost Performance Index (CPI)? Are you just bored and want to impress your friends with your knowledge of SPI and CPI? Well, I’m going to try to make it easy for you.
To the left you’ll see two charts. Both are displaying variances on a monthly basis. The first chart is displaying variances in thousands of dollars, both in schedule and cost. The second chart is displaying the variances as they relate to a performance index.
Definitions and Formulas
Earned Value (EV) – The estimated value of the work actually accomplished
Actual Cost (AC) – The actual cost incurred from the work accomplished
Planned Value (PV) – The estimated value of the work planned to be done
[Chart 1 – Variance (In Dollars)]
Scheduled Variance (SV)=EV – PV
a NEGATIVE schedule variance is behind schedule and
a POSITIVE schedule variance is ahead of schedule
Cost Variance (CV)=EV – AC
a NEGATIVE cost variance is over budget and
a POSITIVE cost variance is under budget
[Chart 2 – Variance]
Schedule Performance Index (SPI)=EV ÷ PV
You are progressing at __% of the rate originally planned
Cost Performance Index (CPI)=EV ÷ AC
You are getting $_____ worth of work out of every $1 spent
So, where does that leave us? Your goal is to have a $0 (zero dollar) cost and schedule variance, resulting in a SPI and CPI of 1.0. That would mean you estimated correctly, leading into your project. Going into the PMP exam, you should know these formulas and how to calculate all of the above. Here are a 2 simple questions you should be able to answer:
1. Is a 1.3 CPI a good thing or a bad thing? Why?
This is a good thing! A 1.3 CPI translates to you getting 1.3 dollars of results for every dollar you put into the project.
2. Is a 0.90 SPI a good thing or a bad thing? Why?
This is a bad thing! A 0.90 SPI translates to your project progressing at 90 percent of the rate originally planned.
Here is the moment of truth. What kind of question is going to be on the PMP exam?
Example Question: Based on the charts listed above, what would you be more concerned with, schedule or cost, if you were taking over this project from another project manager?
Answer: The answer is cost. As of August, CPI is closest to 1.
The number one search on the Critical Path website is for a Critical Path and Float worksheet. Though you should be using software to calculate a critical path, if it is mission critical, it is important to understand the concept for the PMP exam.
Rather then go into the specifics on how to calculate the critical path and float in this post, I’ll merely say a free worksheet template and PowerPoint presentation are available and you can download them at any time. (see links below)
•Remember the Critical Path tells you the activities that can not slip a day without increasing the total duration of the project or moving the project completion date. It is the longest path of logically related activities through the network which cannot slip without impacting the total project duration, termed zero float.