Monday - Interview with a Wiki Ninja
Tuesday - TNWiki Article Spotlight
Wednesday - Wiki Life
Thursday - Council Spotlight
Friday - International Update
Saturday - Top Contributors of the Week
Sunday - Surprise
Did you have a childhood hero when you grew up? Most people do. The hero often is an athlete, soccer player, ballerina, pop star, president or movie star. For girls, the idol can be Madonna, Lady Gaga, Sissi/Romy Schneider, or Meryl Streep. For boys, the idol can be Tarzan, Bruce Lee, Lionel Messi, or Al Pacino. Me? I had a rather unusual childhood hero: Sigmund Freud. I surely would have become a psychologist, if I hadn’t fallen in love with programming so much. I rarely mention the fact that I’m interested in social science, as it is seldom relevant. But today, it is. You’ll see why in a little while, but if you’re suspecting it has something to do with Wikis you’d be right. For now, we’ll let that rest…
A little while ago, somebody in the SharePoint forums wanted to know how people go about estimating the size of SharePoint projects. Basically, I believe there are three ways of estimating IT projects:
Let’s elaborate on these forms a little more.
Yes, you won’t find that one in the study books. This one is quite easy to understand, and instead of providing a definition, I’ll provide some anecdotes to explain its meaning. I do this, not because it’s absolutely necessary, but because I find it’s more fun that way.
Anecdote 1. On my first job, I was sitting close to one of our account managers (let’s say his name was Fred). He was talking to a customer, discussing a new project. Fred said that the project would cost approx. 20,000 euro. The customer replied that that was okay, because they had a budget of 40,000 euro. Fred said that that was a good thing, because naturally, the 20,000 euro excluded project management, testing, communication, and documentation. So, in the end, 40,000 euro would just cut it, luckily. That was the fastest 20,000 euro loss/gain (depending on your perspective) I’ve witnessed.
Anecdote 2. On another job, the company I worked for was trying to win a new, pretty big project. People at my company did a careful estimation, let other people take a look at it, and did a re-estimation. Finally, they came to the conclusion that the entire project would cost 600,000 euro and that that was a fair price. They didn’t win the job, because of the following reason: the potential customer had a budget of 600,000 euro and used a rule that, internally, they doubled the offer made by any company, and would assume that that figure would be the real cost of the project. It turned out that another company (let’s call ‘em compA) offered to do it for 300,000 euro.The customer doubled that number, and saw that 600,000 euro was just within the limits of their budget. The offer by my company was 600,000 euro. After you double it, that becomes 1,2 million, which didn’t fit in the budget. At that point, it didn’t matter anymore that the estimation by CompA may have been far from the truth. They won the job and must have thought: “Well, there’s always budget for bug fixing, we’ll see what happens later”.
By now, you should have a firm grasp of the meaning of Machiavellian count. If you want to learn more about Machiavellian count, don’t ask me, as I’m far too nice a person to be good at it!
In the companies I’ve seen (and I’ve seen a lot of them) some sort of expert count is used regularly. Expert count is the scenario where you have one expert (or more) estimate how long it will take to complete a project. Depending on the quality of the expert(s) and his/her team members, this can be a fine approach. Over the years, I’ve been getting quite good at it, and I’m seldom mistaken by far. The obvious drawback is that it’s subjective by definition. So, the fact that it’s working for me, won’t mean much to anybody else.
A more formalized way to go about estimating IT projects is to use a standard (and rather objective) methodology for establishing the functional size of a, in my case, SharePoint project and express it in function points. Every function point is associated to a certain cost (in hours). The total project size consists of the total number of function points multiplied by the cost. There are several methodologies out there, such as COSMIC Full Function Points or FPA.
The main advantage of function point count is that using this methodology, it becomes quite possible to compare projects to each other, determine how well a certain project team or member is doing, and, if you have enough empirical data, you’ll find a more objective way to do estimations. A drawback is that gaining enough empirical data in the fast and ever changing .NET world can be truly hard to do. Also, doing a Function Point Count simply takes more time.
We’re coming to a full circle now, because it turns out that social science, Wikis, and project size estimations are totally related. Social science succeeds in finding patterns/laws in human behavior. One example of such a social scientific law is that a group of people tends to be very good in doing estimations (especially compared to individual guesses). To verify this, as a party trick, you can let your guests guess the amount of beads in a jar. Please note: I’m not actually suggesting you should do this, as I want you to have fun on a party, I’m just saying it’s one of the things you can do.
In a project size estimation world, since we already have a more or less objective way to establish the amount of function points, we need a way to guess the cost of a function point. Social science teaches us that a group of people is good at that, but now we have to find a way to assemble a group of people that are willing and able to do the guessing in a joint effort. That’s where Wiki enters the picture. Wikis may just be the very best way to assemble experts on a given topic (divided across companies around the world) and may just be your very best bet on getting a grip on project size estimation. For me, my main focus lies on SharePoint technology, so I had to try and see if some accomplishments could be made in this area. Here’s (as is always the case with Wiki) the result so far: http://social.technet.microsoft.com/wiki/contents/articles/10590.sharepoint-2010-best-practices-to-estimating-and-benchmarking-project-efforts.aspx