Voices on Project Management

> Back to Voices Home

Taking on Project Management Myths, Part 5

| | Comments (16) | TrackBacks (0)
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.

 

Bookmark and Share

 

The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

0 TrackBacks

Listed below are links to blogs that reference this entry: Taking on Project Management Myths, Part 5.

TrackBack URL for this entry: http://blogs.pmi.org/mt-tb.cgi/286

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.

16 Comments

Can we say cost accounting? It is a shame that so many project managers only look at budgets and actual and make the same assumption as pointed out in Myth 2. If only many of these project managers that have no business experience or education had taken cost accounting, they would have understood variance analysis. There is much more to being a project manager than just being an Subject Matter Expert that was thrown a new title.

Rob

It seems too me that each agile iteration can be treated as an agile project phase. These phases can be executed sequentially or can be overlapped.

Each phase needs to be initiated, planned, executed, monitored and controlled, and closed properly, which are the main process groups necessary for well controlled project management.

The agile developer that does not recognize the benefit of sound project management practice is "virgin," but in time will gain the experience necessary to appreciate the the partnership.

I see no issue with a marriage of agile and project management processes.

Mark A. Crissman, MSEE, PE, with over 20 years of software development and project management experience

Well, what a waste of a good platform. I do not agree with my colleagues here who say that this is a good article. No. It was just a blatant attempt to get the agile community riled up and get you a lot of responses. Ho, hum...

Really. Come on. I spend a lot of my time talking to the agile community telling them to stop bashing predictive methods and to do some real creative and original thinking. And here I see a predicative proponent doing the same thing, but not really making a very strong argument.

You could at least do a little research into agile and get a better handle on the benefits. You will note that I am not in this post even going to address your article directly as it doesn't really say anything.

There are good reasons to not use agile in some circumstances, and good reasons to not use predictive methods in some circumstances. Do some research and post again. Give us something meaty to dig into.

Thanks,
Peace,
Joseph Flahiff, PMP, CSM

In my opinion iterations are necessary because of the lack of precise and simple specification methods in IT projects. In my area, I know that very often projects start with a bad statement of work or poor scope specification. We don't have better models like in architecture. It's not scope creep. It's a vicious of a relatively new area of engineering. I think in the end, iterations are going to disappear but right now it's a good approach to avoid worse disasters that we obtain when we act like fundamentalists of project management.

Rodrigo Buzeta - PMP, PgMP

As a software engineer who is a strong advocate of iterative development strategies, I was at first put-off by Myth 1. But after taking a second look and reflecting, I would have to agree that it is MOSTLY accurate. However, I think it is poorly phrased.

I feel better phrasing would be: "to MANAGE all the scope creep they NEED," or "to indulge in all the scope creep they want, if they wish to retain their customers."

I know we all have different experiences, but my experience is that IT projects can be effectively managed without scope creep. However, this almost always leads to dissatisfied customers who will either initiate a contract dispute or simply not hire you for the next project.

Many of us in IT prefer to accommodate scope creep rather than risk either of the above outcomes. Thus the development of agile strategies, which allow us to indulge in (though I prefer "manage") that scope creep.

BTW ... I enjoyed the series. Thanks!

I have never heard of that before. That agile project management is the same as creep scope;-)

What do the agile fellows say?

Concerning agile and scrum, the myth is correct, but the truth misses the mark.

Agile methodologies, including scrum, are novel improvements to product management and development. They are not based on work organized as projects and effort is required to use agile practices within the context of a project.

As for the statement that agile was developed to allow projects to "indulge in all the scope creep they wanted," it shows a misunderstanding of the agile processes.

Agile processes actually have a very defined review and change control process. The reviews and change control meetings are planned and scheduled and they are defined with a higher level of detail than in most project management descriptions. Agile is especially adept at reducing information changes and has a framework for regularly rebaseling the effort. Agile permits rapid changes in scope, but it is the organization that determines whether to accept these scope changes.

Agile promotes periodic reviews of progress and disciplined analysis of potential changes and scope. This type of discipline is precisely what an effective project manager needs to embrace.

I respectfully suggest that your "very simple example" in Myth #2 does not "starkly support" your assertion. If anything is "useless" or "misleading" there, it is the way that the Myth is worded.

Comparing a project's budget to actual costs isn't project management; it's guessing. Any PM that is utilizing earned value reporting understands how to calculate the CPI and SPI. In the widget example, both are above 1, so at the end of the first month the project is going well. The PM ought to be able to explain that immediately to an accountant.

If your intent is to write unnecessarily tricky questions for PMP Exam Prep books, Rita Mulcahy already has the inside track on that.

Michael,

Regarding Myth 2, you never compare only project budget with actual costs, you also consider the "estimated to complete."

Concerning agile, I do not think we can speak here about promoting scope creep, since the project scope seldom exists in these cases. In fact it is gradually built in steps.

I have to agree with the posts that question if this blog entry is simply baiting us. Software development and project management are two different processes that share some common themes. Using one process to rule the other in discriminatory manners is surely a recipe for error. A project managed properly avoids scope creep no matter what software development processes are used.

My experience shows that true agile dev happens too fast to track in project documents, and is best handled with regular meetings and progress testing, the results of which become documentation. Making undocumented and unwanted changes to the UI or other project targets is simply failure, not scope creep. They can be good changes and so regular meetings and progress testing should allow for their incorporation to the baseline project goals if warranted.

If it is discovered that only 2000 lines of code added now removes 2/3 of the project's phase II work, ummmm, do it and re-align the documentation to fit. This is beneficial scope creep in software dev. It happens, so we must be able to deal with the evolving ecosystem of the dev teams.

In many areas the tools used for the project will rarely change during the project. In software dev it's probable that there will be changes to tools during any lengthy project. Some of them are game-changing updates. If agile dev is bad, how then to best make use of such game-changing updates to the tool chains?

I'm sure this blog was written in honest opinion, but it doesn't seem the inspiration behind it fits with what I know of software development cycles.

Re: Myth number 1. I agree entirely that agile methods were invented to allow scope flexibility. However, I would like to inject two observations.

First, this didn't come from all of IT, it came from software development. IT infrastructure projects can - and probably should - be managed with a planned and controlled scope.

Second, software is not so easily corralled.

I have been managing software development projects for four years. I have used traditional project management methods and I have used agile methods.

When we use traditional methods we work very hard to define the scope up front. Then we fight fiercely any attempts to alter the scope as we go. Until the end. At that time we do a big change request to account for all of the stuff that we won't deliver because the things that we have delivered were bigger than we thought. And we leave the customer holding the ragged, bleeding contract and wondering where the rest of their functionality is.

With agile methods we all acknowledge that we are going to learn and change our minds as we go. We also acknowledge that we probably will have to choose between getting everything we want to build and getting to delivery in a specified time frame.

Both approaches leave scope on the floor at delivery time. The big difference, and the reason to choose an agile approach, is that the customer chooses what to include first. Traditional methods leave the choice in the hands of the development team. Nice for the team, not so nice for the customer.

Allowing the customer to prioritize functionality and tell the development team when they actually have enough to use the software to solve their problem leads to higher levels of customer satisfaction.

My 12 and a half cents.

Carlie Gehle

Michael,

Your comments about agile are misinformed.

Agile development is based on a series of fixed time and cost iterations of 2 to 6 weeks. Each iteration you plan and analyze your work and agree on a fixed scope with the team for the iteration. At the end of the iteration the team demonstrates what they have completed. No scope increases or time extensions are allowed during an iteration. Any new scope or incomplete items go onto the feature backlog for prioritization in the next iteration.

Agile projects deliver the highest priority features early which means that the business gets a return on investment much faster.

Agile development is an implementation of lean production principles to the software industry and thus is quite different to standard practices.

Many organizations have proven that agile projects deliver quality results faster with lower costs and lower risks than highly structured sequential systems engineering projects.

Michael

Good article.

I would put a twist on your myth re: Agile and SCRUM. I think, done well, these approaches have an attractiveness for clients, in particular, who have time-to-market pressures and/or who struggle to articulate their requirements in relatively concrete terms, which is required of traditional "waterfall' approaches.

My belief is that the failing is owing to the perception that "Agile" equates to "ad-hoc", in which project management is effectively dispensed of, and substituted with informal, undocumented, unanalysed and unmanaged interaction between a technical team and the client.

Typically, neither of these project participants is particularly cognisant of the constraints (budget, schedule) under which the project operates. The result is sometimes a mutual desire to focus upon the 'best product' (often referred to as gold-plating) rather than the business outcomes (i.e. benefits) which justify the project in the first place.

The antidote to this is, I believe, a more 'sympathetic' approach to project management. This entails managing to the project constraints, but demonstrating an understanding that project stakeholders have diverse interests, and will push their respective agendas, regardless of the business case.

Also, I believe that one of the reasons that Agile / SCRUM fails is that it is seen as an approach suitable for any client and any project. In fact, in my opinion (borne of experience), what is required is a GREATER MATURITY than normal, particularly of the client. For example, SCRUM demands that a single 'Product Owner' is appointed, empowered to approve the product (i.e. software) as it evolves. Too often, this role is filled my more than one person, with the resultant discord and inability to resolve issues in the time-frame and with the clarity demanded of agile approaches.

As always, a good read......miss the lively debate!

m

As with your previous posts, this too is somewhat controversial. I'm perfectly happy with your comments re. myth 2 but myth 1 is questionable. I don't believe agile is about promoting scope creep, but is rather about small increments aimed at verifying the direction taken is appropriate and enabling the business change direction without incurring high change management costs.

Michael

Surely this is bait?

Iterative developement as an inviation to scope creep?

How about an interative approach to value management?

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll

Categories