NotesOn: IT HR – Part III – IT Organization Models

Introduction (V1.4):

The structure of an IT organization is absolutely fundamental to the success of that organization.  Good or bad, it provides the foundation for and sets the tone and tenor for all else IT that follows.  Being traditionally under IT HR’s purview, CIO’s/CTO’s often spend a good deal of time with them as regards the best layout of their IT team.  However.  Based on direct experience and years of observation it is clear that the concept behind the business version of KISKIF is unknown, for too many IT organizational charts leave “something” to be desired.

Background:

As you may have read in the “About” pages of this site, over the years I have worked for numerous classes of business, from small to large companies to mega-corporations and I have been a contractor and/or consultant to many more.  Adding to the stack, I have looked in on the IT groups where both friends and business acquaintances have worked, obtaining their “works-doesn’t work” feedback.   From all of these living, breathing examples I’ve found only a handful of IT organizations built around clear, concise, functional, and efficient models that both company personnel and their clients/customers could use to everyone’s advantage.

As for the rest of the structures:  due to growth and contraction, constant senior leadership changes and/or a lack of full understanding, they are occasionally overly simplistic but, more often than not, convoluted and therefore unwieldy and ineffective.  The symptoms of such dis-organization structures include the following:

• oversaturated with dotted line reporting;
• duplicate, sometimes triplicate, horizontal roles;
• lack of clear and concise roles and responsibilities (a.k.a. job descriptions);
• hidden organization charts (if they exist at all).

Ultimately such groups reach the point where everyone “lives with” the fact that the boxes to which they are assigned, and the reporting hierarchies above them, are useless (or perhaps unknown).  To survive they have to “figure it out” on their own, i.e. work out how to get work done with the least amount of aggravation.

One of the more fascinating symptoms of the “What organization?!” phenomenon is the “hidden structure”.  It seems that companies reach a point where they are so embarrassed by their “org charts” that they hide them.  Under the guise of “security” or “not enough time” or “we are too fluid” they refuse to define and declare, let alone publish, any roles and responsibilities (RnR’s) below the executive level, which means the execs have to “figure it out” as they go, too.  This symptom creates a “psychotic” atmosphere in that it cultivates continuous confusion and openly fosters “whim of the moment” relationships and dependencies whereby anyone can end up reporting to just about anyone else for most any reason.  Almost worse, such “dis-organization structures” are fruitful grounds for “empire building”.

Left un-corrected, these symptoms inexorably, inevitably, lead to sustained chaos.  From a practical standpoint they jam up an organization’s “flows” thereby inhibiting production.  Which is why this subject is on “… IT Executive’s Checklist and Survey – Part III” and in the slightly cynical “… The Sinking Ship School Of Business.”

Let It Flow, Let It Flow …

Just as System Development’s projects must flow from one end to the other in a reasonably logical progression (let’s leave iteration out of it for now), so must an organization flow from one end to the other.

Organizational Rule #1:  If it doesn’t flow it won’t go.

Sound silly?  Yet another of my “simplistic” mantras?  Perhaps.  But.  It is also razor sharp truth at its finest.

My greatest successes in management have been where I (or I and my better bosses) defined roles for everyone in my group, defined the internal and external responsibilities (the rules of the game) for that role, and then insisted they own that role from end to end.  I then followed this up with mentoring and training to ensure they had the tools and skills to be successful.  This approach allowed projects and work products to FLOW!  Talk about performance increases!  And skyrocketing morale!  It was fantastic.  And.  Easy to do.

Now factor in this rule:

Organizational Rule #2:  if an organizational structure is too complicated it is also too unstable, i.e.  production will flow in inverse proportion to the degree of complexity.

In a straightforward “clean” structure which is known about and understood, everyone, from top to bottom, inside and out, knows where to go, who does what, who is responsible for what, who to talk to about “what”, and so on.  Living and working under such an umbrella is, though never perfect, nearly a dream come true.  As with a software development framework that allows a programmer to concentrate on the business rules, the teams soon forget about the organization’s “nuts and bolts” and, instead, focus on business and production.

On the other hand.  Due to the inherent, built-in, stress fractures, an overly complex and thus unnecessarily fragile organization will begin to falter upon implementation.  The ensuing instability may be incorrectly categorized as “growing pains”.  But with “growing pains” most everyone is enthusiastic as they learn their way around.  In a fragile dis-organized structure folks are either cautiously tip-toeing about in various states of confusion or “charging ahead no matter what” in order to get anything at all done.  And.  The more pressure (production demand) is brought to bear on such a structure, the faster its fatal (counter-productive) flaws appear and the sooner the structure begins to crumble … leading, inevitably, to eventual collapse.

It has been a while since I’ve heard the term, but “way back when” there used to be “time and motion study” experts and efficiency engineers.  These skilled and experienced individuals would come into a business, such as a manufacturing facility, and help optimize it for maximum performance, maximum output, at (hopefully) reduced costs.  What would they do, mostly?  They would rip out all of the wasted steps, remove all of the back-and-forth-and-crosswise motions, stamp out all of the redundant roles and decision makers and then line up the entire process from beginning to the middle to the end so that it logically made sense, so that, in other words, it “flowed”.  They would also address “exceptions” to the norm and plot those into the process as well.

Unfortunately, in these days of “iterations are forever”, efficiency engineering skills have apparently been dumped onto the trash heap of history and forgotten.  Little else could be more fatal to an IT organization.

So.  Let’s you and I resurrect the ideal models for IT organizations and get things back on track.  When we do, a return of True ROI (ref: “NotesOn: IT Fundamentals – Cost Cutting IT Is Not The Answer“) will be evidenced by:

• increased efficiency,
• reduced project time and costs,
• increased project success rates,
• reduced time to market,
• increased customer satisfaction,
• optimized headcounts, and
• significantly increased ease of management of the IT organization.

Is that end-game worth it to you?

When done right, your people will stop moaning and groaning about the “organization” and start moaning and groaning about keeping up with everyone else’s production pace … a different, far nicer, “problem” to have.

Fundamental Elements Of An IT Organization

So important is a firm understanding of how IT organizations work, should work, that I’m going to start at the very bottom layer, conceptually speaking, and define (so we can agree on) the primary, fundamental, elements that make up IT.  Let’s begin the discussion with this recycled diagram:

Figure 1 - Click on image to enlarge.

These eight elements are the major functions making up successful IT organizations.  If one (or more) doesn’t exist it needs to, at some level (someone at least needs to be seeing to the function), or issues will arise.

Can you think of anything I missed?  We’ll dig deeper in a moment, but, at this high level, is there anything that isn’t there that should be or is there that shouldn’t?

“Hmmm,” you mumble to yourself, “… there are actually nine spheres. What’s with that?”

Good question.  My answer is that in the original version of this diagram (presented to a class at University of Denver’s Daniels School Of Business) I did not include “IT Executives” in the center sphere.  I felt that IT Execs, being the overseers of all IT’s functions, are implicitly present in each functional sphere.  My reasoning was that while IT Execs make up a significant part of the overhead of the primary element(s) which they guide and serve, they are not, as a rule, directly productive, i.e. hands-on product generating components of any of the eight primary elements.

Technically speaking, neither are IT Executives contained within a distinctly separate element of their own, in the sense that they “have to exist” for projects to flow from one end of IT to the other to reach successful completion.  Once the proper PnP’s (processes and procedures, or policies and procedures if you prefer) are defined and in place, and unless one or more IT Fundamentals go missing, it should not take constant IT Executive intervention for work to flow, successfully, through IT. … However.  To avoid any possible confusion by not including them, I’ve now placed them at the logical center of all of the primary IT elements.

Fundamental Flows of An IT Organization

Since we’re discussing IT Executives and their work flow oriented teams, let’s pause for a minute to examine a somewhat critical factor in bringing about, and maintaining, a smoothly running IT (or any) organization.

Organizational Rule #3:  organization’s have “directionality” – at least vertical and horizontal.

By vertical I mean from the top down and the bottom up.

By horizontal I mean from one side to the other within a given level (Exec, Mid-Management, Production, etc.), or anything non-vertical (i.e. not an order or policy, etc.) that travels between two different horizontal levels.

There are general guidelines that govern use of directionality in an organization.  They, at a graphical summary level, are as follows:

Figure 2 - Click on image to enlarge

Fundamental Interchanges Of An IT Organization

We next need to look at, and understand, at a high level, how an IT group should flow, i.e. what are the essential inputs and outputs (who does what to whom, and when and how).  Without this likewise crucial, and fundamental, understanding, your group’s most important flows can too easily become inverted or twisted or omitted entirely.  For but one example, the correct IT and End User contact points can become so distant from each other that communication is near impossible.  Following is a high level flow diagram for IT organizations:

Figure 3 - Click on Image to enlarge

This diagram may seem overly simplistic and, in a way, it is.  However do not let it mislead or fool you.  Dealing with IT is truly no more complex than this diagram suggests.  Yes, there is more detail involved, which we will get to shortly, but the essence of IT’s interchanges is as shown above.  Let’s look at the key elements:

1. IT HR:  hires/recruits the IT personnel for the company.  IT HR oversees performance reviews and, when necessary, the termination process.  IT HR also ensures company policy is known and understood by IT team members.  Note:  IT requires an HR Specialist with IT skills as IT must be understood by HR before HR can properly enable IT.  If you do not have a separate IT HR group, at least one individual in your Company HR department must have sufficient comprehension of IT to work with it successfully.
2. IT Finance:  is a special field of Finance for, among other reasons, IT CAPEX (Capital Expenditure) and OPEX (Operating Expenditure) cost assignments can be “tricky”.  As with IT HR, the Finance personnel assigned to handle IT capital/expense costs, etc., must have at least a basic comprehension level of IT to work with it successfully.
3. IT Legal:  is a special corner of the Legal Department that deals specifically with IT contracts, service level agreements, e-discovery (searching of electronic records for court case related information), etc.  Here too, if there is not a separate IT Legal group at least one individual in your Company Legal department must have sufficient comprehension of IT to work with it successfully.
4. IT Services:  in brief, provides (or should provide) Project on-boarding, Project Management, Business Analysis, Testing, IT Audit, IT Security, Disaster Recovery Planning, Strategic Planning and Contract Management services to/for the rest of IT.  IT Services does not design or build or support systems in any direct way but does provide the support services that allow others in IT to successfully do their functions.  Note: IT QA and IT Risk Management, two of the primary elements, are often nested within IT Services.
5. IT Operations:  at a high level, typically builds and/or oversees all of the infrastructure layers (computers, servers, telecom, networks, etc.) for and provides technical data necessary to the designing, building, implementing and ongoing support of all IT systems.  These functions include Architecture Standards, Operations Engineering and Operations Support.
6. IT Application & Systems Development:  is the nexus point of IT, this is where the systems are designed and built; or evaluated, purchased and then installed.  They are also the final fall-back point for software support.  This is the “soft side” of IT.  It has little to do with hardware directly and everything to do with building the business tools that run on the hardware overseen by IT Operations.
7. IT QA:  is there, needs to be there (in some minimally viable form at the very least) to ensure that the products that roll out the door are, in fact, viable.  Why?  Because, as an example (as noted in “NotesOn:  IT HR – Part II – Characteristics of an IT Newbie“), with a few rare exceptions software developers are the absolute worst testers in the entire known universe.  They can be nudged, pushed and managed, with great persistence, into doing a tolerably decent job of it but true (bullet proof it) testing requires a “separate, fresh, set of skilled eyeballs”.
8. IT Risk Management: is the “unsung hero”, the most often overlooked IT function (next to IT QA) I can think of.  Even though the success of your IT Organization and every single project it accepts is, to a very large degree, dependent on this role(s) being done well, and done often it is too often ignored.Some PM’s are pretty good at managing risk (either from training or necessity born of experience or both) but having someone(s) marshalling, driving, the RM function, constantly, will save your IT group an unbelievable amount of heartache and potentially prevent years of legal litigation (or outright loss of your business).  There are two references in particular on my site you will find of value in this regard:
   1. “NotesOn:  Risk Management-Risk Analysis“
   2. “NotesOn:  Risk Management-Risk Analysis Process Addendum“
9. IT Leadership Committee: not shown on the above diagrams but addressed later is a special functions group that, much like IT Execs, works with IT by sitting above the IT work flow.  It is typically composed of the CIO and IT Execs plus Key Stakeholders from the other business units in the company.

The above logical IT units interrelate and interact, constantly.  No one is more important than any other … unless, of course, one of them ceases to function.  Any project that comes into IT passes through and is touched by (or should be touched by) all of the primary elements at one time or another.  Each must do its part for IT, as a whole, to be successful.

Reminder:  the Purpose of IT is to build and support systems that help the users do “it” better whatever “it” is.  The “better” portion of that statement may be achieved incrementally but, nevertheless, the fact of constant improvement does not alter the above statement.

However.  All eight cannot all be on the “front lines” of IT.  That is reserved for one, and only one, logical unit.

The cutting edge, the leading edge, the frontlines of IT is absolutely, without question, solely owned by IT Application & Systems Development, a.k.a. Sys Dev.  IT Operations is immediately behind, a hair’s breadth behind Sys Dev, but still behind.   If the other functional units of IT attempt to subvert that fundamental order, if they try to insert themselves between Systems Development and the Users/Clients, they will slow down, bog down, and foul up the processes related to the attainment of the above Purpose of IT; thereby causing repeated “misfires” in IT’s projects and service delivery.  By “misfire” (taken from the idea of a fouled spark plug causing an automotive engine to sputter, lose power and eventually fail) I mean the causing of projects to be over-budget and/or over-time and/or fail to meet the needs of the user(s).

Allow me to provide you with two graphical examples.  The first represents the correct relationship of the primary IT elements to each other and to their clients/users, as regards the development and support of IT systems.  The ideal client/user sequence is also detailed.  Take a moment to carefully study both sides:

Figure 4 - Click on Image to enlarge

Each functional layer on both sides of the pyramid establishes, guides, directs, supports and focuses the energy level, the knowledge level and the required skill level more and more tightly upon the project in question that needs to be delivered to the user(s).

Both pyramids must exist.  Both pyramids must be layered exactly as shown.  If one “layer” attempts to skip passed the one before it (or, perversely, dive back behind the one behind it) chaos will, not may but will, follow.  This chaos will take many forms but they all result in increased costs, wasted time, improperly utilized resources, blown ROI’s and, of course, failure to deliver what the user needed and requested.

Again, it may appear to be too simplistic.  But.  It is not.  The above diagram is dead on accurate.  When you violate it (if you haven’t, sooner or later you will be tempted) you will pay the price.  I guarantee it.  100%.  As in absolutely.  Please.  Do not overcomplicate this diagram and its meaning.  Or allow anyone in your IT organization to do so; no matter how “good” their reason may seem to be.  I promise you that you will regret it.  No hype.  No exaggeration.  No hidden agenda.  Simply fact.

Don’t believe me?  Well, if all else fails experience will handle your disbelief (disaster stories where engineers were ignored come to mind) but looking at it from a different angle may help bring you around without suffering the pains and agonies of “hard won” knowledge.  Hence, this “worst case scenario”, diagram:

Figure 5 - Click on Image to enlarge

As I’ve noted in the diagram itself, this is not a hypothetical “worst case scenario”.  It was real.  It happened.  And.  Sadly.  It continues to happen.    Need I add that this is ultimately fatal, organizationally speaking?

How does the worst case happen?  Simple.  Start with a bad case of “empire building”  And factor in clichés such as:  “Too many cooks in the kitchen!” and “There’s too many Officers and not enough Troops!” …  Then, from a physics standpoint mix into the equation:  “addition of unnecessary friction”, a.k.a. interference.  Not to fail to mention this classic element of confusion:

Did you ever play the “telephone game” in school?  Where everyone is in a circle and the teacher whispers a phrase into the first student’s ear and the phrase gets whispered to the next student and then the next and ultimately the message is passed along to the tenth or fifteenth or twentieth student until, at the other end of that circle, the phrase spoken out loud is complete gibberish compared to the original?

There is another IT Organization Model called the CRM model that has Customer Relationship Managers embedded directly in business units.  Everything, absolutely everything is filtered by the CRM’s, whether they have the technical “chops” to properly evaluate requirements and issues or not (usually not).  This too is an added layer between IT and the Users, and I have yet to see it work successfully.  For but one reason, the CRM model is fertile ground for empire builders.  Better to stick to the IT Services / PMO model discussed below where the BA and/or PM are embedded in (not separate from) the project team for each and every project.

When you add too many communication layers, too many waypoints, too many not-experienced-in-building-systems personnel to the requirements and design and build and test and roll-out processes, you end up with a “something” that is significantly less than the user is expecting and at greater cost and time.

It is no less noble to be in support of the front-line “troops” than to be one of the front-line “troops”.  Each role and function in IT is critical.  And.  As an IT executive or manager (or other non-code related position) it is necessary to realize that there are some things that your technical project teams are (should be) better at.

“Power grabs”, “empire building” and so forth (all efforts to be the “most important” factor in IT), put everyone at risk, from C-Level on down.  Such distractive efforts can be classed together as a case of “short term gain equals long term pain” as they are a violation of IT Fundamentals, including the use of the proper IT-Customer Relations focus points (Diagram 3).  This being the case, they are absolutely detrimental to the success of the IT organization as a whole and thus the company and its clients.

If/ when you see this “event type” occur know that the “someone” in question is “in IT” for reasons other than the betterment of IT and the successful delivering of IT systems to the customer.  Hard, brutal fact of Life though it may be, it is nevertheless true, to the hundredth decimal place, that no matter how good they seem … you would be better off without the “empire builder”.

Moral:  do NOT let politics, or ignorance of the real-world fundamentals of organizations interfere with the flows of your IT organization’s structure!  Just don’t do it.  Train or terminate.

Let’s move on now to the IT organizational model so you have a standard against which to compare.

IT Organization Models:

Let’s jump right in to it.  Take a few minutes (okay, more than a few) to study the model before reading any further.  As you do so, do a mental comparison to past and existing IT Organizations:

Figure 6 - Click on Image to enlarge

Note:  the App & Sys Dev group can be cloned where there are multiple distinct lines of business (LOB’s).

Did you find any missing critical functions?  Other than the IT HR, IT Finance and IT Legal groups that were omitted not due to any lack of importance in the overall scheme but because, frankly, I ran out of space?

It’s possible.  But.  I would be surprised.  As this model includes all of the fundamental elements, violates none of the above organizational rules and reflects none of the above described symptoms of a dis-organization.

By the way, as vital as Strategic Planning is, it is an “off-shoot” of Risk Management so I’ve not indicated it as a separate primary element.  My not doing so makes it no less important.

Technologies will change in due course and titles such as “SaaS / SOA” will be replaced with new “buzz acronyms” so study and apply this model from  a functional relationship standpoint not as a literal, titles-are-chiseled-into-rocky-mountain-granite-with-a diamond-saw, never-changing “law”.

You may call them different names if you wish (a rose by any other name …) And.  In small IT organizations one person may hold several of the critical roles under one umbrella, whereas in mega-corporations the work load may be such you have to split a single role into more granular descriptions.  But.  Doing so does NOT change the model or its internal relationships, or its internal and external interchanges, or its flows.  Make sense?

“But”, you raise your hand and ask “what if I work for a very very large organization and it has business units scattered from one end of the country or one end of the world to the other?”

Excellent question.  And.  The answer does not violate this model.  When you achieve an organizational scope of this magnitude, typically you will come to the conclusion (after doing sufficient “Look, Ask, Listen, Verify”) that you have two types of IT organizations:

1. Enterprise Level IT Organization – for systems that span most or all business units.  At least a portion of these functions are often referred to as “shared services”.
2. Business Unit (BU) Level IT Organization – for systems that are specific to, perhaps even customized for, one business unit alone.  If a system can be, should be, used by two or more business units then – for optimum utilization of resources, the development of cross-BU standards, elimination of duplication, reduction of costs, etc. – that particular system is moved up to the Enterprise level.

So what does an Enterprise – BU structure look like?  The recommended one below works very nicely and can be multiplied almost endlessly without loss of critical elements or roles:

Figure 7 - Click on Image to enlarge

Note 1:  if/when a tipping point is reached where an executive or manager has too many direct reports (recommended is five, no more than seven) then (cautiously) insert another management layer to balance them out, ex:  move the successful Manager up to Senior Manager, or the successful VP up to SVP.

Note 2:  though the ITLC box is included in the business unit level diagrams, it is recommended that there be only one CIO / CTO and they are at the enterprise level.  Each BU level should have, instead, an SVP or EVP IT at the top of each BU organizational chart.

If at some point you positively can’t stand it and have to “trim” a “lower level” function as it “isn’t doing anything”, ensure it is understood by everyone -brothers, sisters, first second and third cousins, and all boy or girl friends, etc. – that you are entirely moving responsibility for that element/role up to the Enterprise level.

A better idea, is to have someone at the BU level (with the skills and bandwidth) remain overall responsible for the role even if there is little to do except coordinate BU level activities with its counter-part Enterprise level position.  Doing so is less dangerous than having no element/role at the BU level.

The reason is, is that “out of sight out of mind” can be rather deadly to an organization as it is more difficult to spot what isn’t present … but should be … than what is … and shouldn’t be.  Such omissions result in “everyone assumed it was covered” failure points.  I’ve heard this situation referred to as  “camouflaged holes” where, sooner than later, someone unwittingly falls into them assuming there was solid ground under foot, or as “land mines” that someone accidentally triggers after being told all is safe and sound.

A note of warning about the Enterprise-BU model (sometimes referred to as a Federated Model):

There can be, does not have to be, should not be but in this type of structure especially there can be a tendency to create “dotted line” relationships from low to high and cross-wise … until the organizational chart begins to look like a heavily annotated “after action battle map” with lines and arrows running every which way.  Avoid this.  With a passion.  An absolute passion.

In this type of structure, the, say, BU #1 VP Of Operations should report solely and only to the BU #1 EVP IT, and the BU #2 VP of Operations should report solely and only to the BU #2 EVP IT, etc.  However.  They each need to coordinate with the Enterprise level’s VP of Operations (perhaps via an “IT Operations Council”?), just as they would coordinate with the VP’s and Directors and so on at their own BU level.

Dotted line relationships are never a terrificidea.  Splitting someone’s “managed by” status across multiple senior management positions can get rather … well … psychotic.  To the point where no one knows for sure who is managed by whom and, on the flip-side, for whom one is functionally and factually responsible.  In my humble opinion, based on many firsthand observations, dotted line reporting is an insidious, invisible poison that gradually eats away at an organization.  It does not reduce headcount, or costs, or improve flexibility or agility or efficiency.  Avoid dotted lines relationships.

A KISKIF Project Process Model:

Now that we’ve looked at the fundamental elements, flows, interchanges and structures of an IT organization let’s put this information into practice. Before we do so, however, let me address the logic behind the process.

There’s an old cliché that states that the “Devil is in the details.”, i.e. the “small stuff” that you overlook or brush off as “unimportant” can and will “do you in”.

Another facet of that “business rule” is “Murphy’s Law”.  There are a number of cynical, at least somewhat truth-filled, variations (you can find many on the internet) but one of the primary ones goes like this:

“If something can go wrong, it will.”

My personal favorite adaptation of this is:

“What you fail to prepare for … is what will get you.”

Or (particularly appropriate for Risk Management folks):

“What you haven’t thought of and planned for … is what will get you.”

The point being that, if you are interested in building quality systems, you can’t afford to let the details slide, or to put them off until some unspecified “later” … as eventually they will smack you up the side of the head.

With these thoughts in mind, take time to study the following very workable process / work flow for an IT project, created using the following guideline (a variation of the non-business KISKIF definition found on-line):

KISKIF (for business) = Keep It Simple Keep It Flowing

While the sequence of the following process steps (which needn’t take forever to execute) can be tinkered with, they each must occur.  They are not optional, not if you wish to move towards World Class status:

Figure 8 - Click on Image to enlarge

Note:  the percentages in the right-hand boxes of Diagram 7 (i.e. 50% +, 70% +, etc.) are minimum target values for the deliverables for each phase of the project.  Though 100% is virtually impossible for Release V1.0 of any new system, you and your teams can and should strive to do better than the values shown.

What will subvert this process is the “natural” tendency to want to “hurry things up” by short-cutting one-to-many of the above steps.  The average excuse is “… because we need the rubber to meet the road, now … because the customers are demanding it!”  When, more often than not what customers are truly demanding is a True ROI that helps them to do “it” better whatever “it” is.  By chopping out QA and Risk Management Reviews and/or Architectural Reviews and/or Security Reviews and/or Operations Reviews and/or Customer Input and Reviews, in the name of “expediency” and “speed”, you will be doing your customers a dis-service.

To be terribly blunt, the vast majority of customers/clients/users only get antsy, i.e. get nervous and fidgety, when what they see coming out of IT is, or is going to be, a crap system that has little or no relationship to their needs and requirements.  Thereafter they will either (a) get more and more nervous and more and more demanding, or (b) go elsewhere … in search of an IT Organization that KNOWS how to properly deliver quality systems.  Losing support for IT and/or falling sales is one significant indication that your IT organization is not performing as it should.

Summary:

As with all things IT, don’t make managing IT any more difficult than it is.  As you have no doubt experienced already (or will) there are enough variables “flying around” without adding unnecessarily fragile organizational complexities or overly complex (or incomplete) PnP’s, or both.

Bottom line:  you can either putter around as an amateur, eventually closing the doors of your IT Organization, or, you can drive home the Fundamentals of IT; re-focus your entire IT Organization so it is an external facing, customer-centric team; and align the elements, interchanges and structure of your IT Organization so it flows.  Use the tools and data in “NotesOn:  A Quick-Fix IT Repair Plan” and “NotesOn:  First-Aid Kit for IT Management Plans” as a starting point.

Towards that end, one of your prime IT Executive survey questions is, simply:  “Does it (really) flow?”

Hope this helps,

DP Harshman

PDF Link