Large, complex projects tend to compartmentalize key functionality into coordinated sub-projects. This allows an organization to divide a complex endeavor into more manageable pieces. These pieces are usually run semi-independently and require coordination between sub-project leaders (or project managers) and at a higher level. The level of interdependency between coordinated sub-projects can be loose or tight. This functional coupling of sub-projects can (and frequently does) change as the project's time line progresses.
One of the difficulties that a coordinated sub-project structure introduces is that it stymies the end-to-end leadership team's ability to comprehend and assimilate a sub-project's overall integration with other sub-projects, their on-time/on-budget status, and the soundness of their overall approach. Indeed, it is possible for one or many of these sub-projects to become independently troubled while others may be running smoothly. Unfortunately, these troubled sub-projects can be difficult to anticipate, as information and status is distributed and can remain hidden from those that need it. In addition, those troubled sub-projects will eventually impact the rest of the project when they miss critical inter-dependencies, if they are not addressed.
A large, complex project that I am currently working on fits into the above scenario. Three of its sub-projects in various states of "trouble." To be sure, each has different causes and each needs different corrective actions. I have been concentrating some of my time on one of these sub-projects, as it is the one that will have the most impact (today) on whether the overall program is a success. The other two sub-projects will eventually be just as critical, but this one is the most important one to fix at this time, so it grabbed my attention first. This particular problem took me back to Bangalore, India for further investigation — my fourth trip this year.
As I began to investigate what might be pushing this particular sub-project into a troubled state, I found that they paralleled many of my findings for other troubled projects. I hesitate to describe all of the details, as I do not wish to offend anyone who may by chance read this, but I have written about some of these root causes in the past: Team leadership, project management, and team cohesiveness. This sub-project also uses an unorthodox approach to reaching their ultimate goal that has a high probability of failure (not that unorthodox approaches are necessarily bad, but in this case it probably is).
To correct such a problem requires a parsing of the trouble areas to ensure that they are each addressed. The difficulty is that each time you address one area you tend to find others that also need attention. Gathering information from existing project artifacts can be helpful to identify the overall context of the problem, but it is more important (to me, anyway) to talk with various members of the team from its top leadership right down to its so-called "worker-bees." Since I was already going to India anyway, I took the opportunity to talk with some of the team members while there. As one might expect, I found some of the things that were "fuzzy" when I discussed them with the leadership team were more clear when discussed with the team itself. It should be noted that it is not that the sub-project's leadership intentionally hid the information, but because it was a strategy they were following for what may have initially been very good reasons, they did not think to highlight it as a a serious issue — one of the team's leadership did reference this problem as one of the areas that should be addressed, but it was not clear to me how much impact this was having until I talked with the team. (Note to self: Dig harder when someone makes a vague reference like that).
Ultimately, the ability to move this or any other sub-project out of troubled status will rest on how well we understand the problems they are facing and make the right decisions to correct those problems.
Post a Comment