Some thoughts on C/SCSC and the current state of project management tools
Project Management in Action
From The Executive Suite
Robert E. Feldman, president of his own consulting firm, has 33 years of experience in functional, project, and business management positions on a broad array of high-technology applications, from landing spacecraft on the moon to building aircraft simulators to developing management information systems. He has also consulted on health care, waste management, construction, manufacturing, trucking, and law enforcement.
Mr. Feldman, an international lecturer/teacher in project management, has been a leader in the development of training programs for the various project management functions. He writes a quarterly column for the Performance Management Association (PMA) newsletter, The Measurable News. He is also vice president of the Los Angeles PMI Chapter.
Mr. Feldman has a B.S. in engineering from the University of Illinois and a master's degree in behavioral science from California State University.
I recently wrote an article for our sister organization, the Performance Management Association (PMA), with some observations on the current application of cost/schedule control systems criteria (C/SCSC), otherwise affectionately known to us old-timers as C-Spec. Since C/SCSC seems to be such an emotional issue in the world of project management, I thought it would be useful for me to rewrite the article for PMI and I hereby offer it for your thoughtful review and commentary.
I spent 33 great years with Hughes Aircraft Company successfully leading project efforts with and without C/SCSC constraints. My first experience with C-Spec came in the mid-1960s when I was project manager for an element of one of the first programs to apply these techniques. We kind of “invented” the process as we went along and my project, as well as the program in total, was very, very successful. Later in my career I was assigned C/SCSC focal point for a $1 billion/year organization. In this position, I handled internal training and compliance auditing. This experience formed my perspective—I saw C/SCSC as a reluctantly applied process in a disbelieving management environment.
Where are we today? I have now garnered three years of experience outside Hughes and outside of Aerospace. In addition, my network of professional friends and associates has greatly expanded, giving me an opportunity to gain additional insight vicariously through their experiences. Let me share some thoughts with you.
First off, I see a wholly different climate between DOD and the contracting world regarding the implementation of the C/SCSC measuring and reporting process. It had been a pretty adversarial process, or if not adversarial, then very “uptight.” The development of (management) system descriptions and the related approval process was often reduced to a dreaded, time consuming, “fencing match” between unwilling contractor and demanding government teams, both with unrealistic goals. Today, thanks to the leadership of Donald Yockey, Undersecretary of Defense, and his subordinates, the DOD administrative climate has changed significantly and is much more open and positive. Secondly, the Defense/Space Industry, via NSIA‘s System Description Process Action Team under the able direction of Gary Humphreys and Ron Cohen, has opened up a long overdue, self-help forum aimed at improving both the environment and the process. The contractors are talking to each other about their system descriptions, comparing notes, and sharing insights with the customer—using consensus results to lobby for change. Contractors reviewing each other's systems descriptions was unheard of during my tenure in the industry. The systems descriptions were treated as proprietary documents, revelation of which, “warts and all,” might just give away a competitive advantage.
The bottom line: The climate is getting better, but the C/SCSC “tool” remains underutilized.
The last three years have given me a much broader perspective. Now that I am not a contractor C/SCSC focal point fencing “windmills” with auditors, it is easier for me to recognize the intent of the 35 criteria as an outline of sound management practice. (For those of you new to the subject matter, C/SCSC is not a “system” but rather a list of criteria for judging the adequacy of “your management system.”) That being the case, I would expect to find greater acceptance across a wider group of industries paralleling the modern-day growth in the use of project management techniques. However, when I sit in with a group of project managers discussing performance measurement and earned value techniques, the mention of the C/SCSC “word” brings an almost instantaneous and emotional response: “Not on my programs! '‘The process is too rigid and bureaucratic, so the logic goes. Occasionally, a project manager comes forward with some new performance measurement technique recently “discovered” and describes the process along with the benefits accrued. Oftentimes that “newly discovered process” looks to me a lot like C/SCSC‘s earned value methodology. Why the disparity? Why the lack of acceptance given that our government agencies are pushing the process at the highest levels— with a more open and positive environment? Why are other countries adopting the process? (Did you know that Canada and Australia have officially adopted the process and other countries are looking at the methodology for internal application?)
C/SCSC‘s strengths lie in bringing discipline to an inherently chaotic process. Further, having been “applied” to a large number of contracts and technologies over the past 25 years, there is now a valuable historic database that can be used to bring some semblance of sanity to the forecasting process. In recent discussions with DOD‘s Gary Christie, analysis is tending to suggest that there is a “generic” program/project performance profile that may be useful in measuring any type of project effort against plan. Given that these benefits exist, again the question, why aren't the techniques more widely embraced?
A POTPOURRI OF OBSERVATIONS
A member of the management staff of a large government program notes that C/SCSC is a requirement on his program but it is not useful because things change too fast and it is too cumbersome. Network diagrams have also become useless as a supporting tool because every task is critical and performers use automation tools to “rig plan input” so that all events appear on the critical path. Since we cannot rely on this input we are experimenting with computer-based simulation/modeling tools to help us manage and forecast.
A commercial project to develop an automotive airbag sensor and implement the production line was planned and controlled mainly from a unique WBS-based matrix and a Gantt/milestone chart. In discussing this successful project effort with a group of peers, the program manager “apologized” for not finding it necessary to include a CPM diagram in the process: he didn't need it. Similarly, one of our major copy machine companies makes extensive use of self-managed teams to develop new products using a variety of very effective management techniques. The large-scale public works construction industry makes extensive use of project management tools, particularly the automated network schedulers. But inmost of these applications, unless required by a U.S. government customer, one does not find the application of C/SCSC. If it is effective, why not?
Part of the reason is probably due to lack of adequate knowledge about the issues and techniques. Another piece of the puzzle is probably tied to a poor “image” that was acquired in earlier days and has not been updated to reflect today's more open and responsive environment. In some cases, it may not be an appropriate management vehicle for the project. The bottom line: The climate is getting better, but the C/SCSC “tool” remains underutilized.
PMI should take an active role in establishing requirements and lobbying for the development of appropriate new tools and/or the revision of existing ones, preferably as a joint PMI/PMA effort.
Three recent articles in the PMNETwork may shed some additional light on the issues. In two of the articles, Kenneth G. Cooper, a consultant and advocate of heavy-duty computer-based management simulation tools, argues that projects are mismanaged because much of the work occurs in the “Rework Cycle” and is not effectively accounted for in traditional start/finish-based activity management systems such as might be implemented using a traditional network scheduling package (these two articles are in the February 1993 edition). Another article authored by John Tuman, whose credentials include extensive stints as a program manager, suggest that it is time to “Re-Engineer Project Management.” Tuman notes that most of the tools being used today were invented years ago and it is time to rethink the process. He suggests that information technology may be the key to this reinventing process and “groupware,” network-based software allowing online team interaction, may be a possible vehicle (this article also appears in the February 1993 issue). Interesting, thought-provoking articles, particularly in the context of my preceding observations.
As project management professionals, should we be concerned about these issues? Do we care? What can we do?
First of all, I see project managers as “loners.” Strong, very effective individuals who by the very nature of the job tend not to form strong outside professional organizational ties. As such, many of the decisions that impact our professional lives are made by others who are more group-oriented and thus speak with “louder voices.” In this context, I see us making less impact on the development and institutionalization of the tools of our trade than we should. That may have been all right in the past, but it seems to be hobbling the process as it moves into the twenty-first century. I think we need to get more deeply involved.
Looking at PMA, our sister organization, formed to deal specifically with C/SCSC issues, it would seem that they, even though a separate organization, are akin to a PMI Specific Interest Group. This becomes significant in the context that the two organizations working together could provide a strong voice in spawning professional change, particularly the development of appropriate PM tools. I proposed in the PMA column that the two organizations collaborate and would do so here. Also, I believe:
- PMI should develop a strong working relationship with PMA to create an ongoing exchange of professional information and foster fellowship between program managers and performance management professionals.
- PMI should take an active role in establishing requirements and lobbying for the development of appropriate new tools and/or the revision of existing ones, preferably as a joint PMI/PMA effort.
My first recommendation is based on a personal conviction regarding the need to break down the barriers between program managers and their planning and control support team. I am aware of the reasons for the independence of the two professional organizations, PMI and PMA, but believe that the two complement each other extremely well and working together they could become a very strong voice for change and reform.
The second item is based on a conviction that there is a need for leadership in this vacuum. The commercial software marketplace is trying to accomplish this task and is probably doing a pretty good job, albeit somewhat fractured. Think how much better these vendors could do if they had some guidance from the real users “speaking” with a single voice.
Editor's Note: Mc Feldman has issued two challenges to PMI and PMA: to combine forces and to initiate efforts to promote development of new tools, and improve existing ones, for project management. Reader opinions are invited on both these issues. Identify your comments as “PMI/PMA Actions” and send to PMI Communications Office, PO. Box 189, Webster, NC 28788, or Fax to (704)293-9801. Your opinions gain value by sharing them.