Man drawing complex diagrams on whiteboard. (c) alphaspirit. Shutterstock.

Know Your Projects’ IT Level of Complexity and Explode Up Your Success Rates

Forrest ChristianComputers/IT, Project Management 2 Comments

Large IT projects are known for their massive failure rates, which may be as high as 50% according to some sources, especially if include projects that meet only part of the initial requirements. The problem is that no one ever seems to know exactly why these failures occur. Everyone who has worked in them knows that there’s some underlying reason. It just feels like this is true. But we lack the language to describe what that could be.

Requisite Organization (RO) and time span of discretion, the measurement of work discovered by Elliott Jaques, provides a way to look at projects and their management. Will it give us this missing language that will open our eyes to what is really going on?

I decided to apply RO to a large project I have been consulting to inside a large company in the financial services industry.

First I needed to determine who many organizational levels were between the front-line IT workers and the CEO. I ran up the corporate ladder from someone I knew from experience worked at Stratum I (1 day – 3 months time span of discretion). At first I couldn’t believe how many rungs came up. Surely this is too many!

And it was. The organization is very large but only national. The differences between the US states makes it a relatively more complex company than like organizations in other industries. But it still should not have nine levels!

No organization should have nine levels. This particular one should have about six, and perhaps only five. They have way too many layers.

This explains why people call the Vice President-Systems and her boss, the Systems Vice President, co-leaders of IT: their roles do the same level or work (size of work). Even though the organization chart says that the VP-Systems reports to the Systems VP, everyone knows that he is not her “real boss”, that he doesn’t really add any value to her work. You can get context from either one.

This puts the entire IT as being run at Stratum/Worklevel 4 (with a time span of discretion of 2-5 years). However, at least two of the IT projects had a development projection of ten years.

The manager in charge of the IT function does not have the time horizon in order “see” feel responsible for the entire timespan of project.

How do you think that will work out?

Classroom training in China for the AP1000 reactor. (Photo by U.S. Nuclear Regulatory Commission)

As a further test, I investigated IT planning efforts, since these should show accountabilities and time spans of discretion. For convenience, I reviewed all the planning documents from the department’s technical education group.

These planning documents and project work breakdown structures are almost entirely useless. Misunderstandings about simple terms such as “milestones” and “success criteria” abound. It is obvious that their boss told them to put together their plans, then he would gather them up to put together his.

This is CYA Planning, not planning for achievement. It adds no real value and qualifies as managers abdicating their planning responsibilities.

How can we use the principles of Requisite Organization (like time span of discretion or cross-functional authorities) to determine what organizational level should the sponsor of our IT project be at to provide the best chances of success? Glenn Mehltretter and Michelle Carter have been chatting with me (I’ve got to see them in action one of these days) and provided me one of their general documents about RO. (HINT TO NAMEWITHHELD: You may want to get them talking to your boss’s boss.] Their description of Stratum IV complexity gave me an idea:

Stratum IV: Integrating multiple serial paths or projects between which resources must be shared. Longest Task Spans: 2-5 years

The problem with projects, it seems to me, is determining the time span of discretion of the managing role, whether that of the sponsor or the project manager. You don’t want to run a project from too high in the hierarchy, because that person won’t pay enough attention to it. If you run it too low, the project will shrink down to be accomplishable within that person’s level of complexity information processing—or the project will simply fail a slow, miserable death, full of incrimination and accusation. But determining what that right level is seems elusive.

The description of Stratum IV (above) from PeopleFit gives us a clue: “Integrating multiple serial paths or projects between which resources must be shared.” If you have interrelated projects, running in parallel with resources shared between them, or many dependencies (you must get X completed so that I can use it to start Y), the project must be run by a Stratum IV manager. Anything lower risks not completing the work. Okay, is more than likely to fail. I can describe most of the work being done at BIG as “integrating multiple serial paths or projects”.

Unfortunately, this means that most of their projects should be run at the Systems Management Council (includes CIO and one level beneath). That’s running the projects: determining which projects should be run and planning them may take a an even higher Stratum manager.

The way they plan—getting the lowest level to plan first, then compiling them upwards rather than planning from the top, down—means that this does not happen. Planning and scoping projects is done at Stratum 2 or 3, and often by people not able to fulfill that level of complexity.

All of this raises an issue: how do I consult to a non-Requisite Organization, one whose very organizational structure means that they will not succeed at this change? I can’t in good conscience tell them that whatever I suggest will have much of an effect on their performance as a group. Training will not solve a systemic problem. I can help them get training designed for Stratum I and Stratum 2 and Stratum 3 developers, designers and architects. (Yes, I know that Enterprise Information Architects should be Stratum 7, but that sits above the CIO. Again, the organizational structure creates the limitation.) Since I need to eat, and I’m working with Stratum 2 and 3 (I gotta get out of doing this), I’m going to give them those different tracks.

So it goes.

Image Credit: (man at whitebaord) © alphaspirit. Shutterstock.

Comments 2

  1. Post
  2. I’ve usually described the difference between support and development in terms of recognition and appreciation:
    From the client’s viewpoint, in support you’re only fixing what everybody expected to work anyway; With development you’re delivering magical new products and processes.
    From my viewpoint, in support, everybody client is an idiot because the only issues you work with them on are ones they are clueless enough to call for help with and are usually no brainers for you; With development you work to improve the client’s job function which they (generally) know much better than you do and gives you some footing for mutual respect.

    But, this strata stuff does a pretty adequate job of describing why I hated my previous position. Client support wants minimized time tasks. I guess if my TSD were shorter then I too could be happy spending all day making printers work.

    My apparent stratum also says I’m underpaid in my current position, while going a long way toward revealing why I’m not more unhappy about that. I’m so relieved to be doing interesting work that I’m not as focused on the meager pay. Though obviously it’s not going entirely unnoticed [your favorite emoticon here].

Leave a Reply

Your email address will not be published. Required fields are marked *