Boiling the IT Frog

Here is an excerpt from the book “Boiling the IT Frog” by Harwell Thrasher.

“IT people are very focused on the how, not on the what. The most common mistakes they’ll make are errors caused by doing the wrong things, not by doing things wrong.

Tell IT people what you want to do and you can almost see the gears turning in their heads as they evaluate alternative approaches and eventually come up with various options on how to accomplish your goals. IT people are so focused on the how, in fact, that the most common mistakes they’ll make are errors caused by doing the wrong things, not by doing things wrong. That’s why an IT strategy is so important to a business; it’s the only way to be sure that your IT organization is headed in the right direction.

Some of the worst difficulties in communicating with an IT organization are caused by differing definitions of nontechnical words. For example, IT people frequently use the word project to mean the software development part of a larger Project that includes everything necessary for the business deliverable: design, building, testing, documentation, training, implementation and infrastructure additions. Thus the completion date for a project may be viewed by IT as the completion of the software work. If you don’t clarify the deliverable, then there will be a huge misunderstanding.

Similarly, an IT organization might commit to have some work done by the third quarter. The IT customer will assume this means July 1, but the IT organization will assume it means Sept. 30 at midnight. “

Some other aspects to the book refer to the idea of boiling a frog: meaning, if you place a frog in a pot of boiling water he will jump out immediately. But, if you place a frog into a pot of cool water and gradually heat the water to boiling, the frog will not recognize that the water is hot and will eventually be cooked. This is a good paradigm that we, as IT groups, should be aware of. Sometimes we get so involved in the depths of our project work (developing, debugging, data conversion etc) that we do not recognize that the project as a whole is in serious trouble – we fail to recognize the world around us and perhaps the pressure points have changed. We all should get in the practice of periodically taking a step back (or out) from our daily tasks and routines and truly analyze our projects.

· Has the client’s perception changed?

· Has the client’s business direction changed? From a strategic standpoint, is this project still in line with where they are headed?

· Has the project evolved into something other than what we originally planned? This is usually a good thing, but we should reevaluate to see if it is still heading in the right direction.

· What else is happening in your client’s organization? Are there any new efforts popping up that are in competition with your project? Or maybe an effort has started where we can identity new integration points to expand your project.

The point is, if you don’t stop and take time to evaluate your surroundings from time to time, you (and your project and project team) may end up in boiling water.