Micro Deliverables

The Tech Republic had an interresting post earlier this month:  Monitor Project Progress by using micro-deliverables.

This is a lesson we made almost two years ago.  Being mostly software centric, we refer to this as the "patch a day principle".   We even push it further than the author of the post by targetting deliverables on a "almost daily basis".

1. Amongst developers, the code is an awesome communiation tools.  
   
2. You cannot catch an error much sooner than the next day it is commited.
3. In distributed contexts, the time zones often plays in your advantages and review happens over nights. 

As you can see by the name of the "principle" this is something very software engineering centric.   There is no reason to not apply this accross all roles involved in a project though: Documentation, QA and UX. 

This is about predictability and this is a requirement common to all activities on a project.   Make your project lead and your customer happy through a predictable team using frequent micro-deliverables!

ProjectTools part of the InfoWorld 2008 Top 100 IT Innovative Products

What a nice way to start the day! Yesterday Macadamian was awarded one of the top 100 company that have made use of technology to enhance their business.

Somewhere back in 2004 we started to be concerned by the effort that was required to be effective at project startup, monitoring and status reporting.

We envisionned that it would be a real challenge to provision all our projects with the apprioriate knowledge management technologies and to monitor them with consistency.

With now more than 100 projects starting and ending every year we can say thanks to this early vision. Needless to say that the pressure at being efficient and predictable was high and this is still an important concern at Macadamian.

"Let's automate all that". Our concern for efficiency and predictability gave birth to what we called Project Tools. What is Project Tools?

Project Tool is a software product that aims at:

1. Automating the innitiation of our project's knowledge management infrastructure (KMI). All tools needed for our projects are ready to go in no time (issue tracking, wiki, source control, mailing list, news groups, SFTP, continuous integration, IRC, etc...)
   
2. Managing access control towards all system of the KMI
3. Collecting projects progression metrics.
4. Reporting objective information on progression.
   

It is outside the scope of this blog post to go deeper about what it is, how it works and so on.

Today I want to say kuddos to everyone who contributed to this project.

Thanks to you Francois, Pierre, Benoit, Sebastien, Jake, Jimmy, Richard, Rafy, Karen & Irina. It would not have been possible to achieve this without you.

Last but not least, this award would not exists without Teresa who submitted ProjectTools to InfoWorld. Thanks to you!

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.

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.