Wednesday, April 30, 2008


Honestly... how many out there do it? But most of the time it is really the simplest, most straightforward and successful path to achieve what you're after, whether you're working with APIs, VCRs, exotic palmtops or microwave ovens.

The "I'll try this and that and then tweak it a little" attitude often does not pay.

Tuesday, April 29, 2008

Top Ten Actions for IT PMs

I happened to see a very interesting question on LinkedIn: "What top ten actions can IT project managers take to increase the likelihood of implementation success?"

I think that each of these actions could easily fill more than a book, but I'll try to share some of my thoughts, in no particular order.
  • Choose the right people. As I already quoted elsewhere, blockheads will never produce good code. I know it might sound nasty, but that's how it works.
  • Build a team with the people you chose. That means you must end up with something which is better than the sum of the parts.
  • Respect your team, don't enslave them. Trust them to be able to deliver if they commit to. Happy and motivated people always perform better.
  • Go agile. Waterfall is one of the worst causes of software project failures.
  • Protect your team from external influences. Once the goal for the iteration is fixed, stick to it (hey, have not you gone agile yet? didn't you read the previous item?).
  • Deal collaboratively with the customer, do not drive the hard bargain when you negotiate but look for a win-win situation. Involve him, involve him deeply, involve him early.
  • Often show your team's progress to the customer, and involve him in acceptance testing.
  • Avoid WBSs, plan by features. Let the team manage the WBS internally and only discuss the features with the customer.
  • Always communicate clearly the status of the project. Bad and early informations can become opportunities, bad and late informations only reveal a death march. And it will be too late to avoid it.
  • Plans are nothing, but planning is essential. Adapting to new informations is much better than sticking to a plan which, in the end, will satisfy nobody.
I'm sure there are lots of other tips, but these will do for now.

KISS more

Keep - It - Simple - Stupid. We never remember it enough. Too often we overengineer. It's also true that for every complex problem there is a very straightforward solution, which is wrong. But we should really strive to follow this simple rule.

Monday, April 21, 2008

Joda Time

First things first, nothing to do with Yoda (even if at first glance somebody might be misleaded). Joda Time is a library which should replace the Java date and time classes (who's never clashed with them?). At the moment I'm just starting to play with it, tired of... the dark side. The library also offers the Interval class, that represents a time period between two timepoints. What I still have to find out is how to manage open intervals.

Thursday, April 17, 2008

One year ago...

...I discussed my thesis and graduated cum laude. Nothing has changed in the lower right corner of my paycheck (yet(?)), nonetheless I am sure it was worth it, and now I am "a sadder and wiser man". At least I have a lot of time to spend with my children (and this year I could watch all the Six Nations matches).

Wednesday, April 16, 2008

Estimating blasphemy?

I am working with my team on a new project; we still are in the Inception phase, so even if our ideas are quite clear there are also many foggy aspects. Anyway, we've identified almost all the stories we shall need (the domain is well known) and we are estimating them with story points.

This project will be quite different from all the others we've worked on for many different reasons, so there will be a lot of uncertainity; I then reported to the management that our first estimate will actually be a guesstimate, thus possibly ranging from 60% to 160%. The Project Management Institute (PMI) has an equally broad, but more pessimistic, range for this stage of the project (75% to 175%).

As expected, the management reaction was less than cold, and I was told we had to narrow the gap between the worst and best estimates - a perfectly legitimate request. The problem is that we do not have enough informations at the moment, and only when we'll have an approved product definition we will be able to get to an 80% to 125% range (close enough to the PMI budgetary estimate), but luckily that should happen in a few days.

I'm afraid that will not be enough, because the second question after "how big will it be?" is always "how much will it take?", which obviously leads to "how much will it cost?". Estimates in story points are only a pure measure value, and a duration must still be derived. We cannot use our historical velocity values because, as said, this project is very different from the ones which generated them, so we'll have to run at least a couple of small iterations, observe the values and make a more or less reliable forecast.

Luckily our managers deserve their jobs and they understood our motivations, so I've been able to reach an agreement upon a spike in which we will very lightly touch all the layers of the application and the new technologies we've identified in some previous pilots.

This was another example of how an honest conversation can lead to a win-win situation: the team will not have the pressure of an irrealistic plan and the management will be able to take decisions and actions on the basis of sufficiently reliable informations.

Speech Engagement Schedule

As a follow up to this article, it is confirmed that I'll be leading a seminar on data warehousing for the Università degli Studi di Milano on May 26/27, 2008 (the date is yet to be confirmed, but it is fairly set).

The seminar will be about a real project I led, and it will be conceptually organized in two parts: the first part will deal with the case study in general, while the second one will focus on the integration of different data sources. Depending on the needs of the audience, the seminar will be held in one or two sessions.

Monday, April 14, 2008

Agile Estimating and Planning

Yesterday I finished reading Agile Estimating and Planning by Mike Cohn. I found it quite interesting, even if id didn't add very much to what I had found in other readings; the good thing is that the whole process is explained, delving into different aspects (some of which are too lightly touched, in my opinion).

Azienda Ospedaliera di Melegnano

My family and I would like to thank everyone at the pediatric division of Azienda Ospedaliera di Melegnano, for they not only took care of our baby's health, but also cared about him. You can visit their web site here.