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 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.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
Imagine there are over one hundred logins in the source server and you need to migrate them all over to the destination server. Wouldn’t it be awesome if we could automate the process by generating the scripts for the required tasks?