Troy mentioned in a comment on my previous post on ASP.NET MVC and Agile that I must be in a rare company, or I must be a lucky or persuasive man. There is certainly an aspect of truth to both those observations.
It is certainly nothing out of the ordinary for me to be brought into projects that are struggling - partly I guess as a contractor you only get brought in when projects are behind, and partly I guess my CV tends to reflect that I usually end up being a troubleshooter, despite my original job title or role.
My first comment at my current client was to quote Brooke's Law ... I was asked to come in for one month to tidy up some loose ends and help them push their project through the last hurdles to production ... they believed this was a month's work, and then it would be finished. That immediately range warning bells, and Brooke's Law was in the forefront of my thoughts.
"adding manpower to a late software project makes it later"
If this project was a month away from live release to clients, it must have been fundamentally finished a month or two ago, and now there must be only tweaking and bug fixing left. But there was nothing to see other than a dozen static pages and a SharePoint site structure that had been solely designed to support the navigation menu (yes, you read that right ... the structure of the SharePoint site was designed solely with the navigation menu and breadcrumb in mind). There was not even a basic page that retrieved an item from the database and displayed it - actually there was not even a database, nor was there a SharePoint list to support any of the data.
Someone had got a figure of one month, but I have no idea where from.
So my previous post covered the steps taken to get things moving again, but how did I convince them that this needed to happen?
The Rare Company Theory
My current client has a classic legacy suit of applications, some new, some old, mostly all customised by different suppliers and developers. They have experienced chaos and non-delivery. So they were open to new ideas. I guess that is a major part of the "Rare Company" thing.
One of the first steps to recovery is admitting you have a problem.
That sounds familiar ... but honestly I have no drink or alchohol problems I am aware of!
It is however a familiar feeling at many clients. They continue on the way they are going because of a variety of reasons:
-
All software developers give bad estimates
-
No project ever goes to plan
-
All software has bugs
-
... fill in generic "this is the way it has always gone" excuse here
And yet none of these things are true. But they are almost accepted wisdom at many companies, especially with the decision makers at the top who are used to these and a host of other excuses for why for the upteenth time their project is not going how they asked for it to go.
Until you can prove to a client that these things do not have to be true, they will go with the path they are comfortable with, and that is often a below average result or even total failure. Oddly I have found many places where it easier for managers to explain to their bosses that the project is a total failure, whilst blaming the developers or suppliers, than to stand up haflway through (when failure was obviously inevitable to all) and say "I need authority to get this project back on track, we may take a little longer, but you will get something that meets your needs".
So, yes in many ways my current client is a "Rare Company" ... they (or at least the person with responsibility for this project) have had the courage to stand up, accept that this project wasn't working, and take a drastic and brave new approach.
The Persuasive Man Theory
I am certainly a strong character. In some circles it can be seen as confident, in some it can be seen as arrogant, in some it comes across as foolhardy, and in some it comes across as a leadership quality.
I will be the first to admit that I have limited tolerance for silently doing things badly. I consider myself a professional, and whatever I do, I like to do it well. As a contractor I could very easily sit at a client's office for months getting paid, while knowing the project was in serious trouble, and no blame would come back to me, my future prospects would not be affected. This is the path of least resistance.
But I tend to speak up if I see problems. The only question then is which way it comes across to the client. To the right client it can be a breath of fresh air and a different perspective. To the wrong client, or the wrong person, it can be seen as being troublesome or an attempt to ursurp authority.
I have in mind a specific example of a former client, where the manager of the development team was highly persuasive, but lacked knowledge around the technical aspect of the project. It was "his" project, therefore any comments upon it were a critisism of him. He was not confident or strong enough to admit he may not have got it right, and so he tried to ignore and shut down my input.
His director however was also involved fairly closely with the team, and he was open to hearing my thoughts. That left him with the dilema, he could believe his development manager (who he had known for years and trusted) or he could believe me (who he had known for a few weeks). That took some substantial negotiation to get approval for providing a prototype system that did the same job but in a much cleaner way. As it happens, by the time we had completed the prototype, and effectively proved the original project was not going to deliever, it was too late and the project had to be cancelled.
The key to being persuasive is a mixture of self confidence, demonstrable experience and a degree of being a salesman. To persuad somebody, you only have to make them believe you are worth putting their trust in ... after that they will change their project, or buy a vacuum cleaner from you.
So Which Was it Here?
A few days after the director at my current client had agreed to effectively cancel the ongoing project, and start it from scratch, we had a meeting. He needed confidence that he had made the right decision - after all he just made a million pound decision (and more importantly took a political risk) in changing direction - all based on me. He had a right to be concerned.
Unfortunately I am also a very honest person. So my reply was:
"You really don't know. I could be very good at what I do, and I could be guiding you to the best possible solution to your problem. Equally I could be a bloody good talker and know bugger all, like the last people that you trusted and who put you where you are now. And to be totally honest you have no way of knowing which of those two is the truth."
It is better to be up front and honest, at least it shows I understand why he is anxious. I cannot "prove" I know what I am talking about, and equally I cannot prove the last person didn't. So obviously his face at this point was a mixture of "well I wasn't expecting that reply" and "oh no, maybe he is just a good talker"
So What Was The Clincher?
"The best way you can judge whether I am leading you down the right path or not is by results. By this Friday you will have a full walking skeleton of the site, with all legacy data largely imported and viewable. You can then see the site as it evolves, you can see the story cards move across the board as we complete them, and if at any point you feel we are not making the progress we should be, we can discuss it and deal with it."
The Clincher is ... Visibility
When a client can see what is happening, they can judge for themselves. The "old" way involved months of telling the stakeholders that all was well and on target, but that they couldn't be shown anything yet, or that they could only see small parts of the solution.
What Agile brings to the party is, now they can see exactly what the development team is doing. They don't have to put trust and faith in our words, they can put it in our results.