Learning from NASA
Earlier this year, we had the opportunity of listening to a fascinating hour-long special presentation by Dr. Ed Hoffman, Director of the NASA Academy of Program and Project Leadership (APPL), a part of the US National Aeronautical and Space Administration. The academy was established to provide comprehensive resources in support of project leaders and their teams. As its leader, Dr. Hoffman works not only with NASA, but also other government agencies, academia and industry, to assist in establishing priorities and to enhance capabilities in program and project management.
Dr. Hoffman explained that the fastest growing area of APPL is in bringing knowledge, wisdom, learning and support to the project practitioner or team when they need it, where they need it and how they need it. His work extends beyond the classroom environment to the real world of ongoing projects. The objective of the support is to increase practical project learning, while at the same time increasing the probability of success by delivering the right support to the project team at the right time. Conversely, the idea is to capture and research knowledge and experience from the best practitioners and transfer this through open communication and dialogue. From the individual's perspective this adds up to knowledge sharing, performance enhancement and career development.
What all this nice wording means in practice is that APPL is there to bail out projects in trouble. Well, at least in large part and this is no mean feat because, as every one knows, NASA has a large number of very large ambitious projects with huge budgets. That doesn't mean, as you might think, that there is enough money to cover everything. On the contrary, like every other project, there never seems to be quite enough money to do it all and to do it right.
Dr. Hoffman explained why projects fail, citing a number of reasons such as: ineffective leadership; inefficient "toxic" working environments; inefficient "toxic" cultural interfaces; fear to tell the truth upwards; poor team communications; poor customer communications; cost and schedule constraints; insufficient risk assessment; insufficient training; low motivation; ineffective processes; lack of experience; design errors, and so on. Sound familiar? Of course! But it is just amazing how many projects, not just at NASA, that fall victim to these conditions - yet fail to recognize the source of the problems.
Dr. Hoffman went on to describe a particular success story in which a project having difficulties was put back on track through initial consultations and assessment, on-site training and workshops, followed by appropriate mentoring and consultations. But the issue we found most interesting is "Who pays for this service?" In the case of APPL, APPL pays! In contrast, we have worked in environments where the equivalent of a program management office provides services to projects, including mentoring, but is treated as a cost center and so such services are charged back to the project. This never seemed to work well because of the natural reaction of the project manager who had budget problems (and most of them boiled down to budget problems) was to say: "Why would I encumber my budget with high-priced help for an unbudgeted item, when the budget is already in trouble?" Besides, once initiated, like employing lawyers, the project manager has no control over the charge back.
So, APPL seems to work rather like a two-way confessional. There is no penalty in asking for help and in fact it is encouraged because of the "wisdom" captured for deployment to others. But, as we said earlier, NASA is a large organization with large budgets, so is there a lesson here that much more modest organizations can learn from? Certainly, although it might not be the one necessarily intended by Dr. Hoffman. The issue is: "Can an organization afford to fund an independent mentoring group?" Where a project portfolio of significant size is concerned, we think they not only can but should. Here is the logic.
According to Marie Scotto (Project Resource Planning, Chapter 13, Project Management Handbook, Jossey-Bass, 1998): "The business community believes in understaffing which it can prove is generally good business most of the time." In contrast, projects by their nature are uncertain and hence contain risks for which margins or contingent resources are required. For a project to be under-resourced is not only magnifying the risk but a potential recipe for failure. Thus, the very mindsets of the two types of management are diametrically opposed.
At face value, that means that every project should have adequate contingency or risk management funds in its budget. But as Scotto points out this is the antithesis of general management practice. Moreover, since contingency money represents surplus on some projects, corporate contingency cash across all projects of a significant number in the portfolio could be over-allocated. Therefore, what better way than to establish one central limited contingency fund under the control of a separate responsibility center. One that exists for the express purpose of mentoring and training where needed? That is, to help with projects "in trouble".
|
