The Hard-Nosed Project Manager

The Agile Estimating Revolution

I just read “The Agile Estimating Revolution” in PM Network, April 2012.  Let me punch a few holes:

• “a smaller project could get only slightly bigger, while a large project could have more variance”.  So, project with more features can go wrong in more ways than smaller projects?  Who would have thought?
• “A team identifies the smallest user story for the group, called a backlog, and associates a number – 2, for example – with it.  Next they determine other stories similar in size and nature that could be given the 2 estimate”.  That’s Agile?  That’s a revolution?  Estimating by analogy as been around forever.
• “With story point estimates, a 5 is a 5 no matter who is doing the work”.  Total nonsense!  If I have more experience and skills than you and you agree that my 5 is equal to your 5, someone is going to get hurt if you get the job.

Again, pronouncements without numbers to back them up.

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.

Webinars on 9/14-15 (updated)

There will be a Pharma CoP webinar called “Manage Projects using SharePoint and Microsoft Project” today, 9/14 at 12h00 EDT.  Those who can’t attend should look for my comments after the webinars.

There will also be a PMI Agile CoP webinar called “Fixed Price Agile Products” tomorrow, 8/15 at 12h00 EDT.  I'll watch the recording and issue my comments.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

 

A believable plan

As I was catching up on my reading I landed on The Late Finish Strategy by Glen Alleman.  I find that reading his posts usually make me think, sometimes make me smile, and that linking to them make people believe that I’m not that dumb after all…  Often times Glen’s post are about those common sense things that, for some reason, end up being neglected.  Things like knowing what you are trying to deliver or having a believable plan.

In this post he talks about the need for budget and schedule margins.  Most of the time you are not given margins; your team has to fight hard to build them up.  Most of the time you look at your schedule and there is a sea of red tasks; the critical path extends from project beginning to project end with no break.  To state the obvious; if your schedule does not have any slack, it’s not that you MAY get in trouble, you ARE in trouble.

Now, if you are blessed with some slack in your project schedule you are not out of the woods yet.  As the old saying goes: ”How does a project end up late? One day at a time…”  So, however you got that slack, you have to fight tooth and nail to avoid seeing it disappear.  You likely won’t be able to end with all the slack you started with or all the slack you managed to build up but you just can’t give it away or you’ll end up being the meat in a “rock and a hard place” sandwich.  This situation can happen real fast or creep up on you but the result is the same; pain.

I’ll add to Glen’s post that on top of a budget margin and of a schedule margin you also need a personnel margin.  What good are schedule and budget margins if you don’t have the personnel to do the work?  I contend that like for budget and schedule you need a personnel margin.  Why?  Here are a few scenarios were that margin would be useful:

• Your resources are “potentially overcommitted” due to their name or skills being linked to numerous proposals or future projects.  Don’t you love “do not substitute” clauses in contracts?
• You work in a matrix environment, your resources are on “loan”, and the loan is being called.
• Your resources are committed to more than one project and the other project manager (not you of course) dropped the ball, his project is in trouble and he is sucking all available resources.
• Your resources are committed to more than one project, business priorities change and your resources end up overcommitted.  Multitasking and overtime are taking their toll.

Once again, if your schedule does not have any slack, it’s not that you MAY get in trouble, you ARE in trouble.  You must have slack in your schedule, budget, and resources or you plan is not believable and you have to stop lying to yourself and others.

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.

3 Point Estimates

I was catching up on my reading after coming back from vacation and I hit on Glen Alleman’s Herding Cats blog particularly this post.  Be sure to read the comments too.  If this content doesn’t get you to subscribe I don’t know what will.

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.

Leading by setting stretch goals

One of the points I should have made in my previous post on leadership was that you grow your replacements by setting stretch goals for them.  Setting stretch goals does not apply only to leadership roles but also to all project team members. 

Planning and estimating are activities that many would love to offload onto the PM; the problem becomes how do you train the next PM?  Here are a few examples of stretch goals around planning and estimating:

• When a new Request for Proposal (RFP) is received; distribute it to a few potential or new technical leaders or project managers. Give them a reasonable but not generous amount of time to individually derive a list of deliverables and a WBS.

• Convene everyone to compare, organize, and harmonize the results of the WBS round. Give everyone a reasonable amount of time to individually derive a list of tasks and efforts related to the deliverables identified in the harmonized WBS.

• Convene everyone to compare, organize, and harmonize the results of the task and effort round. Give everyone a reasonable amount of time to individually set constraints and dependencies for the tasks identified in the harmonized task list.

As you go through the exercise observe every participant’s behaviour.  Look for signs that individual participants appear to be lost, uninterested, or not participating in meeting.  Address issues as they come along, offering help and encouragement as needed.  Do not allow participant to give up on the exercise.

You can expect wildly different outputs from each individual at each step of the exercise.  You may reveal hidden talents and you are almost certain to foster a feeling of commitment in all participants.

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.

Who should pay for project management?

It all depends on the type of contract (fixed cost, time and materials, time and materials not to exceed) and who shoulders the risk associated with the project.

If it is a fixed cost project you need your own project manager to protect the interests of your company.  If your client elects not to appoint a project manager it is up to them but in that case you should increase the project management part of your estimate because you’ll end up doing their job for them.

If it is a time and materials project you are basically selling live bodies to your client.  Since that is not a true project you do not need a project manager except if PMs are the ones issuing invoices in your company.

If it is a time and materials not to exceed project you should beat you head against the wall until you get it into your head that you have just entered into an open ended contract where your company assumes all the risk.  If you ever needed a PM now is the time.  Appoint the meanest, angriest project manager you have, give him a Gatling gun, all the ammo in the world, and fix bayonets.  Life is about to get interesting…

Personally I’ve been advocating for a while that we should always appoint a PM regardless of whether the budget allows for one or not.  Cheapest insurance policy in the world.  If you do not take care of your interest who will?

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.

Do we need accurate estimates?

You bet your life you do and you should involve as many people as possible developing one.  If you do get that accurate estimate you will enjoy, in no particular order, the following benefits:

• Focus on the deliverables; hopefully you started with a WBS. Are the task in the estimate directly related to the deliverables or are we gold plating?

• Buy-in from your team members and management. It is not YOUR estimate anymore, it is EVERYONE’s estimate.

• You can run a Monte Carlo simulation to figure out the realistic end date instead of the optimistic one. It is pretty amazing how both values may differ.

• You’ll have identified the training and staffing needs you’ll have if this project becomes part of your portfolio.

• A strong basis for contractual negotiations. Now your sales force knows how much you think this will cost and why.

• If the client says you are too high by X your sales people can ask what can be dropped from scope.

• If your company wants the project to satisfy both its Balanced Score Card financial and customer objectives we now know how many hours we may agree to give away to gain a new client or keep an old one. Remember; do not drop the rate, give hours away instead.

• Faster response time when revising your estimate following scope changes. You already have figures out where you can cut. If the client doesn’t volunteer potential areas of scope reduction you probably have identified them already.

• You’ll have a good starting point for the next time a similar project crops up.

Of course you’ll only know how accurate you were after you get the project and you deliver on it…

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.

Have you ever been architected? ...

... I have.  (Sung to the tune of Jimi Hendrix's 1967 track "Are you experienced?")

First let me say that this post does not intend to take shots and enterprise architects or business analysts; we are all in this together.  The aim is to comment on a possible cause for typical complaints with software projects: stakeholders do not get what they expected, when they expected it, and for the price agreed upon.  As a corollary, the software services provider does not make the expected profit.  No one is happy. 

Here is how the story unfolds:

• As the bidder, you get to estimate a project based on a Request For Proposal (RFP) package. This package contains all kinds of information about the client, the stakeholders, the bidding rules, and the requirements. Often the package is fairly vague about deliverables; this is the root cause of the problem.
• Whoever put the RFP together spent a lot of time discussing needs with stakeholders and extracting requirements from those needs. During this process a list of deliverables, think WBS, was discussed. Believe it or not, in some industries the WBS is included in the package, becomes the basis for a fixed cost bid, and later, for progress and financial reporting.
• Stakeholders would have legitimate expectations of having their needs met but they will be disappointed; the “What does done looks like?” question about deliverables was asked but the answer was not properly documented and the bidder is in the dark. The bid package has descended into the minutia of requirements disconnected from deliverables. This is equivalent to ordering a bunch of building supplies (the tasks/features/requirements) but expecting delivery of a bungalow (deliverables); how do the parts relate to the whole? What is the likelihood of satisfaction?
• In response to the RFP you come up with a cost estimate and tentative schedule. Because of the missing deliverables a time and material approach may be suggested even if a fixed cost was requested; this will likely be rejected but, if not, there is a high likelihood of recrimination later in the project.
• The bidder may be told that he is too expensive and/or that delivery is too late. A phased approach may be suggested to clarify the deliverables (time and material phase) and refine the schedule and cost estimate; this is also likely be rejected as it will appear to redo work already performed by the client.

There are ways to avoid or mitigate the problem and its impact:

• You get to engage with the client early on and work as a trusted advisor while the RFP is being created. This may mean that you are not allowed to bid to avoid an apparent conflict of interest.
• Strict gates are applied to prevent the project from moving forward without agreeing that what is being developed is what was envisioned.
• Both parties get ready for very strict scope control.

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.