Predictability and objective historical information

Over the last two weeks I have been involved at the process of interviewing project managers for an coming project.

A few positive things are striking me:

1. Eloquence. All the guys I have talked to seems to have a facility at talking. This is not a skill you can filter from their résumés. You expect this from a PM but I was expecting some to be weaker on this front.
   
2. Deep understanding of what they did. Although their experiences were high level project management (not technical) they would all be able to describe in a fair amount of details the projects they worked on. That's good.
   

However, a few not as positive things are striking me too:

1. Predictability. Let's face it, software projects are slipping for many reasons. However as a project manager you want to reach a point at which you will know with a rather high level of certainty when you will be completed. Periodically pushing back the delivery date is a bad thing both internaly and externaly. None of the guys have brought this up. It feel like this is even not a word they know about. It's like if this is external to them, don't shoot the messenger kind of attitude. I think this is wrong.
   
2. Historical Information. When talking about estimation, re-forecasting and schedule slippage one would hope that historical information is valued as a way to improve predictability. Apparently not.
   
3. Subjective info is king. Last but not least, it would seem that very few metrics are being used by the people I have talked to. This surprises me, they all had some form of PM certifications. What if the people that brings you back the info are bad at estimating? This one beats me.
   

Obviously, maybe the questions I have asked were misinterpreted, but I am telling you I did all I could to get them to tell me about predictability, historical and objective information.

The lesson here to me is that we will have to train this new project manager to consider looking at the past to improve predictability.

After all, this is rather simple thing to do. Take your velocity/productivity/burnrate (call it however you want) and apply this to the remaining work to do. Chances are that the estimation mistake you made so far are existing in the up coming work too.

With this approach, at least, you have an objective basis for the project change (feature, time, $$) you will have, like it or not, to ask for.

This is so 1990

Sometimes I just can believe how people are getting stuck in their comfort zone. In this case, using folders as THE way of organizing email. I was 100% sure that this debate was over now, that folders (and trees of these) were bad, one of these evil creation of software people.

Coincidentally, I have a draft blog post which is totally the opposite of this guy's perspective. There is no way I could have been more effective at dealing with my Inbox content when I came back from vacation than through the Gmail client. (note that I have not tried Yahoo recently - last news was that this was simply another Outlook on the web)

His discussion on the whole unmanageable Inbox made me laugh too! Effective handling of incomming emails can be imroved through the use a powerful email client but most importantly I believe it is process thing. Looks like he did not buy into the Zero inbox concept I am referring to here.

I need to publish this "Back From Vacation" blog post...

GPS for software team

I referred to my vacation in one of my recent post. We left NYC on a Monday at around 19h. That was fun. Thanks to my GPS.

It reminded me my father who, 20 years ago, got lost while attempting to leave NYC. He ended up in the Bronx (or was it Harlem?). He luckily got assistance from a police man, who told him something like "follow me I will escort you out of here, do not stop if you do not want to loose all you have with you". He was driving a shiny mini van full of bells and whistles. A quite scary moment for a unilingual Quebecois.

This made me realize that we have several tools at Macadamian that serves the same purpose to a team than a GPS to a driver.

The most important is probably what we refer to as the "Remaining Effort" graph.

With the assumption that:

• All substantial tasks are recorded in the tasks system
• Tasks life cycle is followed
  
• Time spent on the project is recorded in the time sheet system
  

This graph shows a quite accurate representation of the remaining effort and the remaining time budget for a project.

In the case of the project above, the team has been beating the estimates throughout the project. The remaining effort - red line - was always below the budgeted effort - green line.

When this happens, we are in for a nice and smooth ride. Obviously, we also have cases where our estimates are wrong. It is then, that we - and our customers - get the most value out of our project progression monitoring technology.

Obviously, this graph is not telling which direction to take but it is at least telling you that you are on the wrong track and this, sooner than later.

Estimation

I am receiving the news letter from the TechRepublic. Most of the time I am only reading the titles and move on. Yesterday an article attracted my attention.

Use a pilot project to confirm estimates and lessen risks.

That is interesting in the context they describe where they have a project involving the execution of a task many times. If you made a substantial mistake at estimating the repeated task, sure you will slip big time.

In my humble opinion what is important with estimates is that:

1. You estimate everything you do.
2. You get everyone involved in the estimation process, especially the ones doing the work. This way your whole organization improves on this front.
   

Last but not least: you give exposure to your estimate and make it clear that they serve a purpose: being predictable.