Changing the Goal Posts

I got a chance to watch some Gaelic Football recently as my two sons have started playing hurling and gaelic football.  Hurling is a fairly ferocious sport where everyone goes for the ball with hands and sticks. Gaelic Football gives the appearance of being a far kinder sport. However, the Australian version (aka Aussie Rules), is a much more physical and aggressive game.  One thing that differs between the Irish and the Australian version is the goal posts. In Aussie rules points are scored when you kick through one of four poles, Gaelic, you kick into or over a pole. Little differences but really important to know and get right.

Adam Goucher had a nice post this week on communication and letting your team know where the goalposts are. Well I have had a similar goalpost problem. Except in mine, the goalposts changed. How I scored the goal had changed, and no-one had told me.

I have a very nice client (he’s a client, so he has to be nice, well in this case he actually is very nice) but new to the software development, and a grappling with some of the basics do’s and don’t to mostly people in IT take for granted.  It’s the basic advice they require most. Like, letting people know when things change, so I can relate to Adams comments.

I spent a good amount of time before the project, understanding who the stakeholders were, and the mission of the testing effort. I explained to them the many different types of testing I could perform, such as Usability, Performance, functionality, Installation and Configuration. It was decided to narrow the scope to robustness, it was a prototype after and all and as long as the screens did not crash, that would be satisfactory.

The day before delivery to their customer, there was a review. The stakeholders were dismayed at the state of the screens and the way the functionality worked. But I spluttered, “you told me you didn’t want Usability Testing”  What a frustrating experience. They had changed the goalposts!

The experience left me angry and frustrated. I had approached the whole exercise well. I had involved the stakeholders, I had worked out their mission. Why did the customer have to go and change their minds?

I suddenly felt empathy developers whose requirements continuously change.

It then struck me that in a way I was the problem. I was being too inflexible and rigid in expecting an inexperienced customer not to change their minds.

I’ve resolved to be far more open in my approach to what’s required (for this project). As long as the customer understands the financial implications of such decisions who am I to argue?

After all is not the customer always right?