Interesting article [“The New Science of Change,” Sept. 15] showing the mechanics behind the processes.
There is an opposite group, of which I am a chief member, where change is the constant and the motivation. Repetition or being comfortable are ideas that drive fear into our souls. The idea of taking the world and turning it on end to watch the results is thrilling. Therefore, we must have a fine-tuned frontal cortex as we prefer to avoid the comfortable. We dissect things, not because they are broken, but because we like to “make it different.”
This is a management challenge, as a propensity for change will scare coworkers and can lead to disarray if done in a whimsical manner.
Interestingly, many who reside in this realm possess the “knight in shining armor” mentality. We thrive on saving the day and swinging for the fence. If we dream, we dream big. So we have come to find that pairing one such change-oriented person with someone very reserved and detail-oriented will create a great symbiosis—one constantly looking to improve through change and the other through standards and maintenance. As the saying goes, “the one constant is change.”
Systems Administrator and Analyst
Reading this article explains a lot of things I’ve seen during system implementations, and I’ll be a lot wiser next time. Sadly, I doubt the outcome will be much different, because change management is rarely considered, much less funded, and training is bare bones in all but the largest companies.
Senior Systems Analyst
R. Ryan Nelson’s article [“Tracks in the Snow,” Sept. 1] is spot-on when it comes to the need to assess and analyze the real value and success of IT projects—or any projects for that matter—after delivery.
I think we miss the bigger point, however, when we fail to design and plan projects with the end user in mind and involved from the start. The best applications and initiatives are no more than high-ticket wastes if the end user isn’t really engaged from the very first thought.
One of the ongoing shortcomings of most IT and technology projects is a lack of proper planning and scoping to determine not just the functional specifications and technical business requirements but the actual requirements as well. Sometimes we get so wrapped up in what technology can do that we fail to ask if it’s something that needs to be done by the business. Just because we can use VoIP phones and desktop videoconferencing doesn’t mean that it’s a valid business idea to implement for a small business. Similarly, having one single standardized, integrated computer system sounds great in theory—but if the users can’t make it work (or have to build workarounds to compensate for local conditions), then perhaps the project needed to be planned to compensate for these issues at the start.
We’ve found that the best question to ask to stimulate this kind of critical thinking is, So what? When my tech director has a vendor come to him with the latest and greatest gadgets and toys, we ask, So what? Will our staff really use fully mobile tablet PCs with wireless? Do we need wireless PDAs with voice, data and Internet to use on projects where much of the data has specific security requirements?
The key then is to ask what the business really needs—not just in tech terms, but in terms of what the users need. If we can get these questions asked properly at the start, we can get more bang for the buck and avoid some of these totally successful projects that are practical failures.
Tom Van Kleef
I totally agree that project “value” is probably the most important and visible success criteria, but I believe that, unfortunately, value is becoming a buzzword. I suggest that project value must be classified as direct, indirect, infrastructure, strategic or transformational value. Each of these value classifications, in turn, requires a different type of valuation and analysis.
City of Charlottesville