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: http://twitter.com/tomvanlamoen

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?”.