Information Technology (IT) is more complex than most buildings. This is why it requires a similar architectural process in order to have a positive and predicted outcome. Too many IT projects don’t end positive or as predicted. IPA business analysts end up running hundreds of surveys in companies all over North America. They’re exposed to many IT environments of various complexity and effectiveness. My experience as an analyst leads me to believe that staff tends to fall into three categories. The first and largest group would be those who believe they are completely IT illiterate. The second largest group would be those who think they are the second coming of Bill Gates. This group is considerably smaller. The third and smallest group are those who believe they fall somewhere in between. This is a common disparity and creates a common problem. Those who believe they have no understanding of IT look to anyone with some understanding as highly proficient in all areas; even worse they often confuse PC proficiency with IT proficiency.

The truth is even those who are brilliant in the IT domain are rarely strong across all divides. It is more common that quality IT staff will have superior ability(s) in one or two areas. Here are four basic areas of proficiency to consider. I am certain there are many ways to slice this pie but, in order to keep this short and sweet, consider these four.

1) Hard (Hardware & Networking)
2) Soft (Software, Database & Coding)
3) Application (Planning & Programming Adaptation / High Level)
4) Project Driver (Single Point of Contact & Oversight / Super High Level)

It is very rare that anyone would be exceptionally strong across the board. Placing too much faith in the office “PC guru” is one reason so many IT projects fall short of the anticipated miraculous impact on sales and profits.

Often projects get more driven by the shininess of new equipment and the technical jargon that gets added to staff’s vocabulary. The person or people entrusted may believe acquiring state of the art servers, monster switches, brilliant routers, and the latest greatest cabling and optical fiber is the answer to everything. The problem is the real “answer” is to question that was never asked or asked poorly.

Questions are the foundation of a building in the IT world called “Application”. An ergonomically designed building in the construction world requires a good architect. A well designed IT environment requires the same. The best application architecture comes from processing what you are trying to accomplish while momentarily ignoring the seduction of the hardware and software and the allure of multibillion marketing practices. It is not uncommon for a highly complex technology environment to become an expensive albatross. The reason is the brain for the brain is missing; the application side is weak. Wildly expensive, enormously sophisticated software purchases loaded up with unimaginable binary horsepower fall victim to the same short sidedness. I have been in too many companies hell-bent on purchasing bigger servers and laborious software with absolutely no way to support it.

Proper planning is the key. As obvious as that statement is, technophobia often critically weakens this essential step via a passing the hot potato style of delegation.

Architects require surveys of the existing conditions, such as soil conditions to support the enormous building weights. This ultimately defines footings and foundation requirements. Lot sizes in combination with the local laws pertaining to set backs and zoning affect what you can and cannot build. The survey is where an architect starts in the construction world and the same applies in application architecture. A survey must be performed.

Step 1)
Take a survey of the current platform. Both the business platform and the technology platform need to be analyzed. The current hardware is normally the only substantial survey ever taken. The analysis needs to be heavily weighted to the current business operations. Strong consideration of potential opportunity, lost opportunity, efficiencies and inefficiencies, as well as the current operations model needs to be graphically converted into flow charts that define everything. Schematics need to clearly show the information flow, interdepartmental processes and global processes accompanying written specs. A company outsider should be able to read this and understand in detail critical processes from the survey’s findings. An identical process is used in the construction world by building architects who eventually evolve their construction document from existing conditions documents called as-built drawings, plot plans or “surveys”.

Step 2)
Brain Storm every imaginable opportunity and all potential changes. Be brave, nothing is stupid. You will find quantity will eventually become quality. This is purely an exercise in discovery. You have to walk on the moon to personally feel and relate to its gravity.

Step 3)
Narrow the creative processes to what is likely to work; get sensible. Start applying cost & benefit analysis. Look at what your true resources are. It is important to understand budgetary constraints, people’s ability constraints, and timeframe constraints. You need to be vigilant in cost to benefit as well as hassle to benefit analysis. Look for potential risks, the landmines in the road ahead. Be honest with yourself about impact: learning curves, culture shock, political impact, systems impact, debugging impact, moving the big ship impact. Repeat Step 3 as many times as it takes. Don’t let mental fatigue prematurely hasten this vital process. Often more focused surveys will evolve requiring an increasingly narrowing brain storming process. Once comfortable with the final incremental impact analysis you are ready for the next step in the application evolution.

Step 4)
A high level of confidence in the strategic planning and schematics are a required precursor for this step. Once the written problem/resolution logistical spec is done and final agreed upon procedural changes outlined it will be time to sharpen the information processing to support and proactively enforce the objectives of everything you wish to accomplish. This is where the interface of the technology side and application come together. Ultimately all the high level planning becomes low level information handling. When designed correctly the end user interface should mandate, high level performance. Ironically high level application will become lines of code and clever programming that ultimately become templates, macros, websites, databases, smart queries and smart metrics. Codes sequenced in billions of zeros and ones will get routed at the speed of light through networks that should be designed to support all of this with scalability within anticipated growth and budgetary constraints.

Step 5)
The best of the construction world architects with the most proactive design methodologies will still encounter change orders because of unforeseen problems. The more proactive the blueprint, the fewer change orders. This holds true in application architecture too. No matter how well you plan, you will encounter unforeseen problems resulting in change orders. You should always plan, budget and anticipate accordingly. Modifications to the original application design of your IT project will happen. It is easy to make rash decisions because you are in “lets just get it done” mode. That is likely to create more change orders and less is better. You can avoid falling into that trap by employing the same methodologies as described in steps 1-4 only with a narrowed focus on what precipitated the need for a change from the original application.

It becomes increasingly critical as you add more stories to a building’s design the necessity for a strong foundation to support it. Designing information technology to support your operations follows the same rule. The more layers of complexity likewise will require a stronger application. This is especially the case when you are introducing either new technology or technology intended to dramatically enhance operations. Over look this and you may find your parking spot in front of the Leaning Tower of Pisa.

Please feel free to visit International Profit Associates website to learn more about our services, resources and opportunities

About the Author

Geoffrey Ladish Gabor is the COO for IPA. Gabor is a former senior business analyst and has personally experienced a vast array of application projects. Gabor recently was placed in charge of a multi-million $ network & telephony makeover at his home base, International Profit Associates. Gabor has had multiple speaking engagements at Harvard’s Graduate Business School discussing topics relating to the perils todayi½s businesses face.