One such was when our Country Manager called me into the office just before Christmas years ago. I thought he wanted to have a small chat and wish me Merry Christmas but things turned out differently. ‘Could I please step in and salvage a project, make a plan and……. have it ready before New Year.’ I knew a bit about this particular project, the Project Leader was a highly experienced and likeable fellow. However, the concern was that for the last months he had been regularly reporting that 2-3 more days tops and the project would be done. Clearly intolerable for all.
Calling everyone in – both the client and one’s own colleagues in the week between Christmas and New Year was not exactly popular. However, it was also probably the reason I got all my questions rapidly and concisely answered. In the end, I came up with a revised plan for the outstanding work of 378 hours to be done over three weeks which all with some relief I am saying, accepted if not believed in.
The key to the turn around was that for each step (this was before sprints and agile became buzzwords), we pinned down and agreed clearly on the outcome we wanted, and, of course, a commonly agreed criteria for deciding whether these criteria had been met. Before we started, we signed off on it.
When executing this revised plan, there were no more last minute changes, additions and new ideas – these were all understood and accepted by all to be outside the scope.
In all my years running projects and especially being called in to salvage development projects, there is one observation that appears to be the elephant in the room: Being unable to tell in simple and measurable terms what the purpose of the development is. This fact will most likely split the various stakeholders into different factions and take away focus from achieving the goal.
To put it briefly, we came in, on time and on budget with the agreed revised scope. Having done so, we had the luxurious opportunity to sit down and discuss what should come next. I moved on to other crises but it didn’t escape my notice that we continued billing the client over the course of the next six months and were given the opportunity to build several extra modules for him, each being a separate assignment.
My observation is simple: agree on how to measure whether you have succeeded or not before you start. At that point in time, it is possible and relatively easy to agree without being influenced by a whole series of events that often set sail in a different direction than first planned. One may argue that objective measures are not possible, a fact I happily accept. In my experience, it is possible to agree on subjective measures to steer by. The all-important point is to align all to the blueprint one started out with and to make educated decisions along the way.
Later, when working and living with developers in always beautiful Odesa, Ukraine I learned more, that testing is a field of expertise in its own right and further underpin my point shared. More on that, next.