The Hard-Nosed Project Manager

Public Works and Government Services Canada’s National Project Management System

I just happened upon this presentation by Public Works and Government Services Canada’s on the National Project Management System (NMPS).  It is kind of interesting to see how they approach project management. 

One very interesting tidbit is on page 10 of the presentation which displays data on projects on schedule and overruns reasons.   Wouldn’t it be nice to have an equivalent level of detail in the CHAOS reports?  

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Earned Value for software development projects is not a myth

I was minding my own business this morning, installing software on my home computer, when I decided to do my email.  There was an email from PMI-ISSIG about the ISSIG Review 2010 Vol. XIV No. 1.  One article that got my attention was “The Myth of Earned Value! (for Software Development Projects)” by Richard Fox.  I’m not including a link because it is copyrighted material and anyway I think the article is plain wrong.

You have to read most of the article before you get to the meat of the matter; basically, Mr. Fox states that EV and software development don’t mix because (my order so it makes sense to me):

• Software project have imprecise requirements. So, you don’t know what you want to achieve?
• Sotware projects are harder to estimate and it is harder to get an accurate progress report from a developer. Never worked construction, have you? This is not a software development exclusive.
• Until the software tests successfully we don’t know that we are done. Well then, claim nothing before then and then claim 100%.  Better yet, have clearly defined milestones with clearly defined deliverables and clearly defined %complete associated to them.

Add these 3 to this quote from the article:

The magnitude of trying to decide how much of the work of many software development activities has been completed may be best expressed by an old method of estimating the “ETC.” This is the 95% rule - “It takes “95% of the estimated schedule/cost to complete 95% of the work and ANOTHER 95% TO Finish it!”

Is it any wonder he claims EV and software development don't mix?  You could also guess who I’d be nominating for the CHAOS award this year…  For those who want to learn something about EV go to Glen Alleman’s blog, Herding Cats and type EV in the search box.

What do you think?  As always comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Chaotic numbers

I found a new (for me) project management blog called Scope crêpe by Rich Maltzman and as I was getting caught up with this blog I encountered 2 posts about project success rate.  The first one provides some statistics from an issue of PM Network while the second is about the CHAOS report.

You may recall a post I made on the same subject.  In it I grouped together the CHAOS report’s “failed” and “challenged” numbers.   Interestingly enough the percentage of successful projects according to the CHAOS report is much lower (by about 20%) than in the PMI numbers.  The spread increases for organisations with a high level of project management maturity.

I’m not sure how to interpret this spread between PMI and CHAOS numbers.  If I were to guess (and I am) I’d say that CHAOS has a higher percentage of IT projects and that drives their success numbers down.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Bracketing the target

I like appropriating expressions of my past lives and reusing them in project management.  Bracketing the target is something an artillery observation post crew does; you start shooting for a target and then try to find its actual location by overshooting it, undershooting it, and shooting right and left of it.  Then you deal with it…

In project management the equivalent would be finding the true scope of a project which may be hidden within a large number of fuzzy requirements.  That fuzziness comes from a lack of context, the use of jargon, the piggy backing of requirements left behind from other projects, pet requirements, etc.

As I mentioned in my CHAOS theory post I believe that applying a Pareto law to the set or requirements would remove the 20% that really hurts the schedule and cost of a project and increase risk.  My experience is that when you leave those 20% behind you hardly ever get to include them in future releases; they just weren’t that “required”. 

Looking at it from a slightly different perspective Glen Alleman replied in a comment that at the US DoD, under Secretary Gates, 60% of the needed capabilities "now" are considered much better than 100% (or something near that) later.  This is a very good, very pragmatic approach to projects.

The best practice we’ve been using to get everyone on the same page is to do a prototype, demo it, and then make the necessary adjustments.  This prototype is not a throwaway; it is a rough draft of the end project.  This approach works with software projects as well as “consulting” assignments such as strategic planning.

Using such an approach as always allowed us to identify and then remove fuzziness from requirements.  It is also a great way of working around communication issues brought on by jargon.  The end result our clients and for us is less pain and typically a lower cost, a more accurate schedule, and less risk.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

CHAOS theory

Glen Alleman’s post on the Standish Group CHAOS Reports documents nicely many of the weaknesses of those reports.  Having only three categories doesn’t provide enough granularity, fuzzy definitions for these categories, no access to the base data, small sample sizes, etc. 

You also have to consider that the Standish Group is a commercial concern and that shielding their data and presenting it in a way that is advantageous for them can be expected.  We are not dealing with a not for profit research group subject to peer review.

Just for kicks I built the following chart by grouping all the “failed” and “challenged” together from all the CHAOS report information I could find on the web.  I’m assuming that the CHAOS report methodology has been constant over the years (was it?).  Even with a built in bias you see that both groups flat line over time.

 

My own definition of success is no more that 10% off on cost, no more that 10% off on duration, and no significant scope reduction.  By that definition, and based on my experience, I’d say that the same conclusion holds true; the success rate has flat lined over the years.  Whatever that success rate happens to be.  Why is that so?  Here is my personal CHAOS theory; no butterfly wings required:

• Requirements are fuzzy, often documented out of context and not tied to deliverables. See this previous post. If you don’t know what you are delivering how would you when and for how much?

• All requirements are deemed equal. No consideration is given to a must have/nice to have classification. If a particular requirement addresses a seldom encountered condition or action is it that important? I believe that the Pareto principle applies here and that 20% of requirements cause 80% of the cost. Why not implement only the true essential requirements; saving costs and complexity?

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.