Human Factors In Action (Based On A True Story)
In this story, there are three “groups”. The vendor, who is the development team, the end users, and IT for the users. IT is the sponsor – i.e. they have the money for the project.
The vendor does a pretty good job of documenting their requests for information. The end users don’t always do such a good job of responding in a timely manner. This isn’t really that shocking, because supporting the software development effort is not their primary job. The vendor has been very good about allowing schedule slippages to accommodate the users. (How they do this without charging more money is beyond me. Presumably they make their profit via selling their software licenses.)
Unfortunately, there is this one request for information that has been out there for weeks and the vendor is still waiting for a response. (All the others have been completed. The end users really are pretty much on top of things.)
Finally, getting nervous, the vendor calls a meeting to discuss the status of the request. During the meeting it becomes clear that the end users still don’t know what they want. The vendor pointed out that if we can’t resolve this soon the result will be that they will have to break these requirements out into a separate release and therefore ask for some additional money – but probably not that much.
Now having often been the vendor myself, I know this is an entirely reasonable request. But the end users reacted very badly to this. They immediately started trying to figure out who to blame for this perceived failure.
Now, of course, if there is any ‘fault’ in a situation like this, the only people that can really be blamed are the end users themselves. But this seems unfair to me. They are dang busy and they have returned every single response except for this one and there were extenuating circumstances with this one. No one is even considering the need to blame them. When it comes right down to it, IT should be ready to pay a bit more to the vendor to accommodate the users – and they are prepared to do so.
But the end users feel nervous that they are going to be ‘blamed’ and basically launch a pre-emptive strike to figure out ‘who is at fault’ only with the caveat that it most certainly is not themselves.
But how can the end users blame someone else? Isn’t this just a simple failure to get answers for the vendor? But of course, it’s always possible to find someone else to share blame with: “Who made the decision that we have to have these requirements now?” one end user asks.
Another user agreed, “Yeah, when this all started we asked to make this a separate project, not part of the current project. So who the heck decided to make it part of the current project anyhow?”
Their ‘blame tactic’ seems to be that actually this is all ITs fault because we just didn’t budget enough and plan well enough. If we had just been smart enough to follow their advice to not include this in the original scope, then we’d not be in this situation today.
Now mind you, absolutely no one but the end users is currently blaming anyone. And considering what a minor bump this is to the scope, I’m really not at all worried about the worst case scenario – breaking these requirements into a separate project.
And for that matter, how much sense would it make to start off with this as a separate release? That would just mean it was more expensive to begin with with no chance of getting it into the current project and thereby saving time and money. So the case that it would have made more sense to initially plan for the worst case scenario is pretty thin.
Yet this whole blame game seems to be a necessary part of moving on. The end users really need to go through this ritual to assure themselves that they are not at fault.
Unfortunately when you play the blame game, you actually have to come up with a reason why it’s not your fault and thereby you are actually blaming someone else. In this case, it’s IT’s failure to follow their initial advice. Now IT, who was never even blaming the end users to begin with, now feels they have to defend themselves.
And so that does IT do? Why they whip out the original proposal that the end users all signed off on which states that the cost on these requirements is contingent on getting it into the current release. So apparently the end users claim that they originally told us to put the requirements into a future release – if true at all – was forgotten even by themselves when they signed off on the proposal.
Now you can see the danger here. The end users, not wanting to take the blame, started trying to exonerate themselves upfront. This turned into blaming IT. IT then showed the end users their down sign offs that proved them wrong. Now what? That last thing you ever want to do is alienate your users. Bad. Very bad. And without a doubt, the single fastest way to alienate your users is to be able to prove something really is their own fault – which is what IT just did.
Luckily we managed to diffuse the escalating blame game. We claimed that clearly there was a miscommunication between what we requested of the vendor and what went into the proposal and unfortunately no one caught it until after it was signed. So now it’s, um, the vendor’s fault, I guess. Lame, I know, but it worked. And I don’t really blame the vendor. They were probably the most on top of this of anyone.
There are a lot of points to learn from here:
1. The very real human need to find blame away from yourself.
2. Anything said any time in the past (or misremembered as such) tends to be remembered as a requirement by the end users and they will try to hold you to it if necessary.
3. Having physical proof (a sign off) that the end users were misremembering actually had the potential to make the situation worse. Luckily it didn’t this time.
4. On the other hand, I am very grateful that we did have the sign off. If this ever did become a more serious issue and was sent up the food chain, I could always just wave the sign off around.
5. In fact, having that sign off virtual guarantees that it will never go up the food chain. The end users are too much at risk of looking bad if they decide to raise this as an issue.
There is another thought here worth mentioning – what if that proposal had not explicitly stated that the cost would change if we didn’t respond by a certain date? Of course every proposal is implicitly based on the assumption that you give timely responses. But had it not explicitly stated it, most likely the political pressure for the customer would have been to try to force the vendor to not raise their costs. This seems rather unfair for the vendor. They are really just lucky that they foresaw this possibility and happened to document it. But it’s impossible to foresee every such problem.