The Hard-Nosed Project Manager

Agile; still not convinced

Today I was listening in on a PMI Agile CoP webinar entitled "Beyond Scope, Schedule, and Cost: Rethinking Performance".  I do try to broaden my horizons...

I must say that I am still not convinced that Agile is that different from other iterative approaches.  Actually, at some point, the speaker adopted RUP terminology and if you had just joined in you'd have been confused. 

Much of the argumentation was anecdotal; for example:

• Claiming that Agile yielded an 89% improvement (decrease) in the number of defects over the "traditional" approach is great but when you mention that the organization was apparently 4 times over the average for its industry you could say that the problem lied somewhere outside of the methodology.
• Claiming that a Gantt chart is not as good as a Parking Lot chart is not comparing apples to apples if when the deliverables are not the same.  Comparing a crappy Gantt to a good Parking Lot is a weak argument.
• The fact that some projects fail due to feature bloat is not news.  Using Agile (or RUP, or something else) does not by itself fix that issue.  The "traditional" approach did not cause that problem either.

Making claims from a position of authority does not win debates, it speaks mostly to those who are already believers and it may create in others the perception that the claims cannot stand on their own.  

Using a different vocabulary to talk about the same or equivalent concepts is not enough to create buy in for Agile.  For example, Story Points vs. $ is at some level similar to $ vs. Euros; all we are talking about here is currency conversion.  What if, from now, all projects Agile or not used goats as their currency?  Would that make Agile better or worse than the "traditional" approach?

I'm still open minded about this subject but still not convinced.  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.

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.

Crystal clear communications

Blast (pun intended) from the past…

FOO (Forward Observation Officer): Reference the left corner of Small Wood, left 150 mils, range 3500 meters, the target.

OP (Observation Post) Tech: Seen! Reference the target, left 350 mils, range 4000 meters, T-Junction.

FOO: Agreed!

What does this conversation between an Artillery (Red over Blue!!!) FOO and his OP Tech have to do with project management?  Well, nothing and everything.  Everything, because the subject of this post is crystal clear communications.

How do you expect to get things done if needs (requirements), priorities, etc. are not communicated clearly?  Having well written SMART requirements is one thing; having them understood is another.

To insure common understanding you need to insist that what you communicate to a team member be read back to you in his or her own words.  If you truly recognize you communication at the end of the read back you can safely assume that common understanding has been reached.  A few words of caution:

• You have to do this each and every time.

• You have to do this with everyone regardless of whether they are new or you’ve known them forever.

• If you do cannot equate the read back with your initial communication start again and again until a common understanding is reached.

• In this type of exchange every participant is equal; it is not about imposing your will, it is about communicating clearly.

Communicating is 90%+ of a project manager’s activities; what will happen if you are sloppy 90%+ of the time?

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.

Risk management is a day 0 activity

This morning I was participating in a Mentisor seminar/roundtable activity on Risk Management and Scope Management.  Both subjects are basic project management topics that often don’t receive the attention they deserve given the mayhem that neglect may cause.  This got me to reflect on a conversation I had a few months ago with a client that got badly burned.

In my line of work system validation is mandatory and very expensive compared with hardware/software/programming costs.  The numbers vary and each of my clients has its own pet number but it is typical to add 170%, 200%, or even 220% to the purchase cost just to account for validation.  In hard numbers this means that a $1M system will cost $2.7M to $3.2M by the time it is validated and rolled out.  If the system is more expensive; you do the math.  It can get scary pretty fast

A side effect of this multiplier is that clients understandably fight scope change tooth and nail.  We do the same; no one wants to be the donkey in a game this pricey.  The title of this post being “Risk management is a day 0 activity”, you are probably wondering where I am going with this?  Well, the wait is over; some best practices related to Risk Management and Scope Management should avoid a lot of wasted money:

• Risks are built in the project approach; a project or product is not a repeat activity and some of this innovation is likely to have unrecognized risks. Recognize this from day 0.

• Avoid Swiss army knife software; there is no software package that does everything well and all those marginal features will still need to be tested and validated ($$$). What is the likelihood that some of these features are putting you project budget or schedule at risk?

• Avoid stakeholder’s pet feature for the same reason as above. I’ve had requests for reports that have the same content but packaged differently; keep only one variant and let the people adapt. There has to be a positive aspect to that Evolution thing.

• If you can’t avoid the two previous points, identify those features that are risky, track their triggers diligently, and the minute those triggers engage let the project sponsor know. You may be able to jettison them before they really hurt the project or at least to minimize their impact.

• Remind your stakeholders that featuritis is costly to implement, to validate, and to live with over the live of the product or system. Remember COBOL, FORTRAN, etc? Systems written in those languages still need to be “fed” years after rollout by old guy like me who will retire eventually.

Don’t tell me that these points don’t ring true and that they don’t represent situation that repeat themselves, with predictable outcomes.  Recognizing and managing risks from day 0 will save you a lot of aggravation and costs.

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.

Gizmos, gadgets or just plain SMART?

More catching up and I landed on this post.  I fail to see how an iPad or for that matter any other hardware gizmo would improve requirements.  In most cases the issue is not with the format but more with the quality of the requirements. 

What about coming up with SMART requirements?

· Specific

· Measurable

· Attainable

· Realistic

· Timely

I think that we may be able to do this without gadgetry.

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.