It's finally time to expose the biggest myth as I close out my taking-on-the-myths series, hopefully generating plenty of lively responses.
Myth 2: Comparing your project's budget to actual costs is a natural way of assessing cost performance.
Truth: Comparing budgets to actuals is not only useless, it's misleading.
To back up this little piece of iconoclasm, I will invoke the widget example I use when teaching the subject of cost performance measurement.
Imagine you are a project management assigned to a project to make 2,000 widgets in two months with a budget of US$2,000.
You time-phase your budget US$1,000 in month one and US$1,000 in month two.
At the end of the month one your accountant tell you that you've spent US$1,100. How are you doing?
If you said "poorly" based on the fact that you have spent US$100 more than you budget, go to the back of the class.
If you said, "It depends on how many widgets you've made," go to the front of the class.
Because if you've made 1,300 widgets, and each widget is worth US$1, then the proper comparison is obviously the US$1,300 in earned value against the US$1,100 it took to make them.
A very simple example, I grant you, but it starkly supports my assertion.
The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry.
Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted.
My take is that the most lethal practice to project health is to allow informal changes to the technical baseline without changing the cost of schedule baselines--a practice commonly known as scope creep.
The IT industry is particularly susceptible to this, since changing the size of a building or the speed of a ship is hard to miss and affect. But changing the look, feel and capability of a software package may require little more than adding a few lines of code--and how hard that can be.
What started happening within the IT industry, on a common and costly basis, was that seemingly small changes in the various code modules created a configuration management nightmare.
So, we see the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda.
But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary.
So what do you think? Myth or reality?
Editor's note: PMI members who are interested in agile should check out PMI's new Agile Community of Practice.
Myth 2: Comparing your project's budget to actual costs is a natural way of assessing cost performance.
Truth: Comparing budgets to actuals is not only useless, it's misleading.
To back up this little piece of iconoclasm, I will invoke the widget example I use when teaching the subject of cost performance measurement.
Imagine you are a project management assigned to a project to make 2,000 widgets in two months with a budget of US$2,000.
You time-phase your budget US$1,000 in month one and US$1,000 in month two.
At the end of the month one your accountant tell you that you've spent US$1,100. How are you doing?
If you said "poorly" based on the fact that you have spent US$100 more than you budget, go to the back of the class.
If you said, "It depends on how many widgets you've made," go to the front of the class.
Because if you've made 1,300 widgets, and each widget is worth US$1, then the proper comparison is obviously the US$1,300 in earned value against the US$1,100 it took to make them.
A very simple example, I grant you, but it starkly supports my assertion.
The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry.
Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted.
My take is that the most lethal practice to project health is to allow informal changes to the technical baseline without changing the cost of schedule baselines--a practice commonly known as scope creep.
The IT industry is particularly susceptible to this, since changing the size of a building or the speed of a ship is hard to miss and affect. But changing the look, feel and capability of a software package may require little more than adding a few lines of code--and how hard that can be.
What started happening within the IT industry, on a common and costly basis, was that seemingly small changes in the various code modules created a configuration management nightmare.
So, we see the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda.
But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary.
So what do you think? Myth or reality?
Editor's note: PMI members who are interested in agile should check out PMI's new Agile Community of Practice.