As information technology professionals, we constantly complain about mismanaged projects in which we have the misfortune to be involved.
Frequently, someone with more power than knowledge – usually in management and under the sway of a persuasive vendor sales team – has come up with a systems design most politely described as novel.
Because of our experience and understanding of the technology, we can clearly see the plan will fail. Heedlessly, despite our loud protests, the project plods onward toward oblivion, consuming money, time and our human spirit along the way.
We feel bitter and exasperated at being ignored. We are shocked at the audacity of spending a corporation’s money when you don’t know what you are doing.
Our most common reaction is to escalate, complain, and engage in a battle of wills with the author of the flawed plan. We must change our thinking. To engage in resistance to doomed projects is both futile and self-destructive.
By releasing our attachment to the idea that projects must be done right, we begin to see the virtuous effects of projects being done wrong.
Of course it is our duty to register our objections to a flawed plan to those in charge in email, using clear, technical and unambiguous terms.
Beyond that, however, our emotional involvement should end. In the event our customer or employer deploys a badly designed system, it will surely require many skilled, competent troubleshooters to fix the system. That’s us!
Incompetent systems design results in strong demand for competent technical people. But the benefits to the I.T. economy are not restricted to the aftermath.
During the implementation of a failed system, a company pays vendors and employees to build it, even though they lack the skills or knowledge to realize their system is doomed.
Without doomed projects, these people would not even be part of an I.T.economy. It is like a kind employment stimulus based on stupidity.
So don’t feel hate and loathing if you are in the midst of a doomed project, and nobody will listen to you. Release your attachment to the need for others to do things right, and wait for failure.
When it comes, do your best to help. I’m not saying I think this is how things should be. I’m just saying it works paradoxically to the benefit of good technical contributors. It certainly is not something to get bent out of shape about.
Subscribe to Our Blog
Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.
The “ORA-12154: TNS:could not resolve the connect identifier specified” Oracle error is a commonly seen message for database administrators.
This blog reviews how you can generate scripts for SQL server logins, role assignments, and server permissions for a smooth migration.