Establish CredibilityBy Bruce F. Webster | Posted 2008-08-21 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
Baseline columnist Bruce F Webster talks about what it takes to champion the right information technology project solution. He can’t guarantee that you’ll succeed, but he knows you will have a better shot at it.
If possible, you must start this task before any problems arise, since you may lack the time and opportunity to do it once problems arise. You build credibility in several ways. Work hard and work with the team. Know what you’re talking about, technically and from a business perspective. Always be honest, especially when it means admitting you’re wrong or you just don’t know something.
With regards to what you feel is the “right” solution for a difficult IT problem, understand and acknowledge the pros and cons of all proposed solutions, not just yours. Be really sure that your solution is indeed the best one – not just the most interesting or convenient. In short, give people a reason why they should listen to you. That leads to the next step.
Build Consensus Upwards
Many years ago, in the middle of a difficult and protracted software development project, I found myself concerned over some key issues regarding technology and features. I felt I knew the right answers, but mine was a minority opinion. So I went to one person on the development team and talked with her about my proposed solution.
She didn’t necessarily agree, but I didn’t argue with her; I just stated my reasons and left it at that. I then went to another person on the development team and did the same thing. And so on. After going through the whole development team a few times, I started to hear member of the team discussing my solution with one another – and agreeing with it, while adding on their own improvements.
I then moved upward in the management chain, repeating the same process. By the time that the firm had to make a decision on this matter, consensus had built around the solution from bottom to top, and it was adopted.
Most importantly, it wasn’t seen as my solution, because it wasn’t. It had been shaped and modified in the process; tradeoffs had been made; improvements added; and it was now a solution that almost everyone bought into.
I then started talking with the engineering team on the next thing that needed to be changed.