Why Good Project Management Can Destroy Your Project
Okay, the title for this post is misleading, I admit. But I wanted to catch your attention.
One irony of software development is that the consulting companies I’ve worked for always want me, as project manager, to have documentation to prove I did every reasonable thing possible to make the project succeed. Is that so bad? Actually, sometimes, yes.
Now the thinking is obvious. If things start to go wrong on a project and the customer starts to blame us, at least we can prove it’s not our fault. Now, of course documenting everything is impossible to begin with due to the law of lossy requirements. Besides, you can’t really know in advanced what minor detail at the time will turn out to be perceived in retrospect as obvious negligence. But those problems aren’t the ones I’m writing about today. For the sake of argument, let’s pretend it was actually possible to document every possible issue that might later come back to bite you.
The problem is that proving something ‘isn’t your fault’ is probably going to be perceived as equivalent to ‘blaming the customer’ instead. As it turns out, proving your customer is at fault isn’t always what’s best for your project – even if it’s the truth.
Over the years, I’ve gotten pretty good as guessing in advanced where problems will crop up. I’ve also gotten pretty good at documenting in advanced that I really did try to resolve the issue and/or obtain help from the customer to do so. I’m no where near perfect at this, but I’m good enough at it that the obvious problems don’t catch me off guard any more.
But my experience is that this makes the consulting companies I work for over confident. They then wish to waltz into a meeting with the customer, prove via my documentation that the customer is at fault, and expect the customer to just accept this. I’ve actually seen text book ‘good project management’ like this ultimately undermine the relationship with the customer, and thereby sink the project because the realities of human psychology were overlooked.
Now how would you feel if your vendor did this to you? I know what I’d do. I’d fire them.
Why? Because there is no way I’m going to keep a vendor around that has proof I’m incompetent and that the project’s failures are my fault.
So even if I do have documentation to ‘protect myself’ with, I rarely want to actually use it to correctly place the blame as to what the source of the problem is. It’s generally better to, if necessary, pretend I was partially to blame then to prove to the customer it was entirely their fault. (And of course, I am often partially to blame.)
So once again we see that software is primarily a human endeavor and that you can only ignore the psychology side of things at your own peril.