Flowers and expectations

In The Netherlands there is lottery based on postal codes (Postcodeloterij). I participate for years now and the most I ever won is a couple of euro’s.

Last week I received a letter fromthe lottery that I won a bouquet of flowers, to be picked up at a local florist. So I took the additional time, when going home from work, to go to the florist and pick up my gains. And this is what I got:

This is not a bouquet of flowers. This is 4 flowers in plastic with a commercial message on it and I even had to spend time to pick it up myself. From my first positive surprise that I won something I now moved to the negative disappointed about what I won area. My appreciation for the lottery decreased.

This is really bad expectations management from the lottery. The clue behind expectations management is in the end to give more than expected. In my case, in this lottery I do not expect any winnings. So if I win something, at least the prize should be clear. It’s better to give less people a prize, but then at least give something decent. So not half of the village 4 flowers, but 50 people a really nice bouquet of flowers, preferably slightly bigger than the one they would select when buying flowers themselves.  The people not winning expect that, so no problems there. The people that do win are extra positive because their prize was even better than expected….. it’s not that difficult.

15 minute rule

If you have a problem, if no-one else can help, and if you can find them, maybe you can hire the A-Team.

For those of us that are not so lucky to find the A-team, we need another solution. A nice rule I saw implemented in my Lviv team is the 15 minute rule. If you run into a problem and don’t see how to fix it withing 15 minutes…. ask one of your colleagues to assist.

This leads to faster problem solving and more knowledge sharing!

(And it’s always nice referring to the A-team ;))


Update Feb. 11 2011:  Part of the solution is explaining your problem to somebody else in your own words. By explaining it, often you already find the solution.

The client wants everything

In the past I have done a couple of projects (all CMS websites or portal development) where the deadline and budget were fixed, and the scope variable. Most of the times because the Senior User (business/client) did not completely know what they wanted at the start of the project. This is a problem. During the project more and more requirements become clear, and new ones pop-up. The work to be done, based on the existing and new requirements becomse more clear. And after some time it gets clear that the total amount of work requested will not fit the time and budget that is available.

That situation is not nice for the Senior User, because priorities have to be made and less important (but still wanted) requirements will not be delivered or additional time and money needs to be available. Also for the Senior Supplier (we) this is not a good situation. The client does not get all they want, which means the client will not be completely satisfied in the end.

Of course then you think…. but the agreements was based on variable scope, this problem is discussed in the project, everybody should be aware of it. Yes. But still the client wants everything, and is not happy if this doesn’t happen. String of thought: scope is variable, so let’s add this small feature, and this small feature, and this small feauture, ow… and this small feature.

In my current project we updated the offer from variable scope, fixed planning, fixed budget to fixed scope, variable planning, fixed budget. By defining the scope and offering it fixed it gives clearity to the client: this is what you will get, nothing more, nothing less (at least… without updating agreements). There will be less discussion, because is defined as fixed. And because the scope is fixed there is less reason to investigate all possible other nice related features.

No problems with scope changes, but they will have to be discussed separate. The advantage is the Senior User will verify if the additional scope adds value, because it’s clear what are the costs of this specific scope.

So my best practice (for the types of projects we normally do):

  • analyse the needed functionality and create clear specifications about them (T&M)
  • create a fixed scope offer for implementing the functionality described in the specifications
  • changes: RFCs

Twitter for reporting

Until now I did not really understand the added value of Twitter. Blogging I understand. But just mentioning what you do, it sounds a bit…. irrelevant. I know a lot of people see this completely different, so probably I am wrong (so pls don’t feel offended). And I think you never know for sure if you don’t test it yourself. So I need to find a good reason to push myself in trying this.

Wednesday we started a new project, which needs to be delivered fast, so we are going to do an extreme developement project. I have the honour of managing the project. Because we all like the concept we are really focused on delivering good results. We have a capable team. So far nothing but good news 🙂 Now, the next part is reporting to my client. We are doing this project as an internal project, so my client is also internal, but always really busy. And because time is short I want to be able to give small regular updates. What I do know he is using Twitter on a regular basis.

So I decided to bring these two together, and I will use Twitter to do reporting on the project. Not the normal Highlight Report at the end of the week or an Exception Report (hopefully not needed). But just small updates, some additional small info, short questions, etc, just the type of messages Twitter is meant for.

It will be a nice test to see if Twitter works for me and if I can swift to the extremely cool 😉 people that do use Twitter. Will I like it? I will keep you posted.

O, if you are interested:

Projects are about the goal

A couple of weeks ago I wend hiking in Belgium with my Scouts. And it was really nice, good weather, a nice route. After one and a half day we crossed a road which leads to the village Hotton, and we knew we also had to go through that village. One of the Scouts suggested: “Why not follow that road…. that’s faster than hiking up and down that hill in front of us”. Of course we didn’t follow the road, not only because it was a drive-too-fast-don’t-pay-attention-to-pedestrions-because-they-shouldn’t-be-there-anyway-road, but mainly because Hotton was not the goal of the day. The route was the goal. Hike through a nice environment, enjoy the view, enjoy the route.

This is different in projects. Projects are about the end goal, the business case, the benefits. And of course if you have no fun at working towards that goal,  find other work. But the  only reason for doing the project is reaching the goal. So if you find a fast route towards the end goal, you take it. No detours just for fun, no “sitting around, enjoying the view”…. 

That’s not always easy. Not only the senior user/business/client has a tendency to add as much as possible to the scope of the project, without verifying if it serves “the big plan”. Also developers like to add as much to the scope as possible, to deliver the best and complete product possible. However there is also time, money, quality, etc to consider.

So I guess in a project with every step you take, consider: “Does this have a positive influence on the goal?”.

Team culture

Some time ago I was doing a project in Germany. I worked closely with a lot of people at the client, on location in Germany.  What better way to discover the cultural differences 🙂

I was surprised. Germany and The Netherlands are neighbouring countries, but there were more differences than I expected.

Compared to Dutch people Germans have a more formal way of communication at work. So it’s possible you are good friends for years, but still in business meetings you will call each other sir/madam (if other people are present). In The Netherlands you almost never call somebody you know sir/madam, there are other ways to show you respect people.

It’s also always clear what the hierarchy in the company is, lot’s of people even have that in their signature, which makes escalation paths really clear ;). Disagreeing with somebody above you in the hierarchy is not done in Germany, but Dutch people are always ready to discuss everything with everybody, because it is possible you have a better solution for a problem than your manager. On the other hand it does take much more communication time in NL because of that.

Because of the different cultures within this project (German, Dutch, Greek, Romanian) the culture in the project changed from the local German working culture into a mixture best suitable for this project. For example everybody was on first-name base, but decisions from higher levels were always accepted as a fact.

As always a project team should find its own culture for maximum performance. Working with people from different cultures means you have more options to choose from and more to learn from each other. Of course if the cultural differences are big, everybody needs to change their behaviour more to fit in the culture, althought the tendence is to stay closest to the clients culture.

Pareto principle

Pareto’s principle, the 80-20 rule, is of course also true for projects. Some examples:

  • 80% of the project managers time is spend on 20% of the team.
  • 80% of the work is delivered by 20% of the team (and most of the time not the 20% in the above example).
  • 80% of what the client wants takes up only 20% of the budget.
  • The other way around it sounds more shocking: 20% of the requirements take up 80% of the budget.

But how can this help us?

Management time
In a team some people need more personal attention than other parts. That’s normal. But a big amount of the time is spend on a small part of the team. Why is that? This can have a lot of different reasons. The 20% part of the team might have the most difficult and risky part of the project, not the correct knowledge for the tasks, tasks that need a lot of coordination between teams, bad work attitude, need more guidance, are more pro-active in discussing progress, etc. So find out what’s the reason for all the communication and see if it’s normal for the type of tasks and knowledge level, probably. And if that’s not the case, there is a problem that needs fixing, because it can save a lot of management time that might be needed for other parts of the project or it can decrease customer costs.

Delivered work
On the other hand 20% of the team is delivering 80% of the work. Are they that efficient, overqualified or do they have easy tasks? The main point is that something is going really well here. Try to find what it is and have other people learn from that experience. Imagine what happens if you can get the high-delivering part of the team bigger!

Requirements/scope vs budget
Because we have a default set of portlets for delivering portals we try to do 80% out of the box, meaning the additional, custom, 20% will probably be the most expensive part. So indeed 20% of the work can take as much as 80% of the budget. If we focus on the 20% custom part to see how we can lower that, it can dramatically save money for the client. For example by discussing if some of the requirements are really so important they need custom work or can be met with a, much cheaper, out of the box solution. This is all about value for money.


By knowing Pareto’s principle we can try to break it and bring the bad part of the percentages to the good parts.