One of my clients has spent US$45M dollars on an IT security project that will enable role-based access control (RBAC) across the enterprise. RBAC is a simple idea that is pretty complex to enable without rewiring your organization. Big Insurance Group (BIG) has recently declared the first release project a success, even though there is nothing in production and the product does not work. Even though they are continuing to spend millions every year, the project has almost no chance of success for entirely organizational reasons.
Because of I can’t stand to see a dumb animal suffer, here are Forrest’s Rules for Organizing for Project Success:
First, determine the real length of the project vision. Real Length is the total time (chronological) it will take to roll out a complete vision, from idea through requirements through construction through implementation through post-implementation corrections, all the way to stable maintenance. In other words, it’s soup to nuts, the entire meal, not just the time for the main dish.
Real Length requires looking at the complete vision, not merely a component. If you are designing an operating system, it is the whole operating system and its accompanying rollout and distribution, up until support and maintenance have stabilized.[UPDATE 2013: I’d now argue that this should be through maintenance and sunset, the full product lifecycle.]
Assess who has the capability to sponsor, manage or architect the work and staff these roles appropriately.
The project sponsor should be capable of setting context for the project manager and architect, who can share a strata. If the sponsor and PM are the same person, he or she does must be a strata above the architect.
I have reservations about the architect’s role. It seems obvious that the architect, as the expert, can even be in a much higher strata than the PM, but must be at least the equal of the overall sponsor.[UPDATE 2013: This now seems ridiculous. I suppose it depends on how you define the project accountabilities. Using the lateral authority types defined in Requisite Organization go a long way to solving this.]
If you cannot get project sponsorship from the appropriate executive level do not do the project. Some managers — especially a problem in IT Security — will assume that they can do the job themselves, even though the project’s timespan would warrant a much higher executive. This simply never works.
Sponsorship from a level that is higher than appropriate has considerable risks. Executives who are stuck with projects that should be handled by subordinates often neglect the project altogether, mostly out of boredom. The project sponsor should be just high enough and interested in doing the project.
The sponsor should hire a project manager and an architect who are also capable at the appropriate level(s). It may be that even as architect, you as the technical expert do not have the requisite experience and “far-visioning” capability. Make sure that the persons assigned do. A project manager whose far-visioning cannot take him to the end of the work will declare victory too early on a deliverable.
Sponsorship at the appropriate level along with project management at the appropriate level increase the likelihood of success.
Image credit: Manhattan Bridge under construction-1909. Via Library of Congress collection.