In a great, lengthy comment to one of my recent posts, Michelle Carter of PeopleFit USA detailed many of the problems with my ideas about costing projects based on Jaques’s ideas of Time Span of Discretion of roles. She points out some issues very clearly, so I encourage you to take the time to see what she’s saying. (Her co-worker, Glenn Mehltretter, responds in another post with more good descriptions of RO and how managers can deploy it.)
One of the main points she raises for me regards the complexity of the Time Span of Discretion of a role. [UPDATE: I originally used TSD and “time horizon” interchangeably. They’re not. Time horizon is a property of a person, how far I can feel comfortable looking into the future, while TSD is a requirement of a position in the company, how far into the future I have to work until my decisions come due.]
My concern lies mostly with Information Technology projects within corporations. At Big Insurance Group (BIG), upper management has decided to create a Role-Based Access Control (RBAC) system for its internal users. This system was originally scoped at two years and US$25MM. Five years and $47MM later, they have a “version 1.0” that cannot be placed into production and that no group has yet agreed to use. The integration of the RBAC with only the applications currently being built or revamped will take another three years, by conservative estimates.
The Project Sponsor has a personal Time Horizon of about one year. The Project Manager has a horizon of about 1.5 years. BIG’s other project staff have time horizons of between one week and two years. The rest of the work has been farmed out to two outside firms with a mean age of about 28, which limits their time horizons to similar or just higher longer numbers.
The project has almost no chance of success because no one on it has a time horizon out far enough to resolve the complexity of putting RBAC into production.
I don’t think that I am going out on a limb when I say that short time horizons of project managers, sponsors and planners is the leading cause to the disastrous failure rate of IT projects. Most projects run 200% over initial estimates because the managers delegated the planning of the work out to Project Planners with insufficient complexity to understand what the project will take. A project manager, given a project planned like this but where he or she has with “Complexity to burn”, can often salvage it. Amazingly. Of course, the PM does it by redefining the scope of the work, throwing out the project plans and creating new ones that have the staff doing things that they are not assigned for.
Part of the problem stems from the issues that Michelle identified in her comment: the work is scoped incorrectly:
So the TSD for the consultant is squirrelly and misleading if s/he is being called upon to help with planning and strategy. If this is the case, you want a consultant whose current capability at least equals that called for by the entire project, not just the time span of the planning phase.”
This is where enterprise-level IT projects fall apart. The project planning is handled by lower level specialists “because they understand that technical stuff”. The projects are managed by lower-level specialists in project management, “because I don’t have time for day-to-day affairs”.
Unfortunately, the nature of requirements management and changing technology means that any long-term project will have changes throughout the life of the project. (Most important requirements are tacit rather than explicit knowledge and are therefore the users don’t have read access to them.) These effects of these changes will not be adequately discovered, because the staff handling change management cannot think out past the end of the project into integration where the effects will be realized.
All of this adds up to the need for a Program/Project Manager and Sponsor on the project with time horizons out beyond the project lifecycle.
An application manager whose time horizon encompasses not only the project lifecylce but also the entire software lifecycle (through deprecation) will have products that enjoy greater long-term success. Most of the really nasty problems with software happen after you get them into production, sometimes years later. Y2K issues were created during the 1960s for one insurance company I worked with. That’s a long time horizon to see a problem.
If Jaques is right about how we progress in complexity of information processing (and thereby increasing time horizon), our practice of using 27 year olds — or even 35-year-olds — to create software has some distinct risks.
All of this creates a difficult situation for someone like me who would like to create a halfway decent method for managing software projects. What time horizon matters for whom? Does one need to be able to see the total software lifecycle from requirements to de-servicing, or simply the project lifecylce from requirements to implementation in production, or just the design-construction-implementation work, or something else?
And who needs what level of capability in resolving work complexity?
Projects are transitory, like breath on a glass. The complexity needs of the roles differ from project to project. And unless you have some powerful minds running the show before the planners get it, you run the risk of thinking that you have 1-year horizon needs when you actually have 10-year needs.
There’s something wrong with how the entire industry is run. Anything we come to can’t get us any worse results than what I’m seeing right now.
For the record: Trying to replace a system that was created in over twenty years of maintenance programming with a “build from scratch with the latest technology” project is just stupid.
Or at least incredibly difficult and expensive.