There was a very interesting article posted not long ago at SQL Server Central by Janet Wong entitled My Projects Have Never Failed.
In the article, the author explains projects that experienced varying degrees of success for various reasons - but in all cases a disconnect existed between the end-user or customer expectations and the delivered product.
Personally, I consider these projects failures.
Here's why: The stake-holder or executive has this expectation. It may be very unrealistic, but they hold it nonetheless. They may be very educated people or not. They may understand technology or not. None of this impacts the fact that they hold expectations.
Q: Who's in charge of communicating realistic expectations?
A: Technology people.
Or at least a member of the technology team.
A good technology team has several moving parts and people fulfilling different roles.
Note: If you're a one-person-show, this post is not about you.
At least one person on the team needs to be customer-facing. That person needs to be an expert in communicating with business people who hold unrealistic expectations. Make no mistake: this is a talent and an art.
Good communicators are rare in life, rarer in business, and practically extinct in the technology sector. Most good communicators abandoned IT departments decades ago and moved into sales where they could enjoy salaries orders of magnitude beyond what IT departments will pay them. But I digress...
I don't blame my customers when their expectations go unmet - I blame myself. Had I communicated something better - or even differently - the outcome would likely have been better for everyone.
So here are some tips for communicating with project stake-holders / executives:
- You may understand what you mean when you say "Third-Normal Form Relational Database" at a meeting with executives, but few of them will. It's not their job to understand - that's why they're paying you. Step up. If you cannot translate your conversation into executive-speak, let someone else do the talking. If your point is to embarrass the executives, you'll probably not try that at your next job.
- Identify someone on your team (or add someone to your team) to serve as a point-of-contact to the executives. If your team has a project manager, they may be the best person to do this. I've also seen horrible project managers who exacerbate the problem with their own inability to communicate (or worse yet, take the side of the stake-holders and hang the development team out to dry).
- Keep it short.
- Keep it as simple as possible. Stake-holders and executives do not need to know the history of iterations you went through to arrive at your conclusion. Take it as a sign of confidence in your abilities that they accept your judgment on the matter.
- Stake-holders and executives have different priorities from you and I technology people - remember that.
- If you deliver quality late, no one remembers. If you deliver junk on time and under budget, no one forgets.
- The old consulting axiom ever applies: Under-promise, over-deliver.
This is business. This isn't academia; you do not get to interpret your own results.
It's not a success unless they believe it to be a success.
Me, I've had projects fail. Some of them have been spectacular in the scope of their failure. To date, I've stepped up, admitted the failed status of the project along with my errors, and promptly moved to correct the issues. I've found excuses to be a waste of my and my customer's time.
Having a project fail is bad enough; failing to manage the failure takes it to the next level.
Remember, if you fix it, it will be ok.
Tomorrow, I address Stake-holders.
:{> Andy
Technorati Tags: Software projects Success Failure Technologists