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

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?

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.