This document utilizes a project the author is currently nalyzing and addresses the functional and risk elements uncovered prior to the client''s acceptance of the endeavor. It also provides a blueprint for managing and implementing the project, drawn from both personal experience and lessons from failed projects gleaned from various authors. submitted 2-Dec-2001, 2001 Dantel L. James Page 1 2160, Kharbanda on Project Management, Dan James Table of Contents EXECUTIVE 1 TABLE OF 2 INTRODUCTION......... 3 PROJECT FRAMEWORK 4 DISCOVER 4 DEVELOP 7 DOCUMENT — 9 DEPLOY.... Ђ” 9 FINAL LESSONS — 10 DISCOVERY OF "PROJECT 1 1 THE BIG PICTURE — 1 1 FUNCTIONAL ANALYSIS — — 12 RISK ASSESSMENT 15 PROJECT M ETHODS & FEASIBILITY.................. 22 Page 2 By Daniel L. James Introduction In 1981, the Rand Corporation studied the phenomenon known as the "Concorde syndrome," named for the infamous Concorde project to develop a commercially viable supersonic airliner. As history has shown, the Concorde is a technological marvel, but a commercial flop. Rand''s study found that 80 percent of typical "pioneer" (new development) projects failed to achieve their main objectives. It is axiomatic that everyone learns from mistakes, but there is no law I''m aware of that says they must be our own mistakes. The book, What Made Gertie Gallop: Learning from Project Failures, by Kharbanda and Pint02, is the lead source of this Course Paper on project management. In a nutshell, the book discusses actual failed projects from around the world, from which valuable project management lessons are extracted. The authors set the tone in the Preface, "... [T]hose who never made a mistake also never made a discovery. 3 1 found that the authors validated many of the principles I have applied to project management efforts through my professional career, but I also benefited from new perspectives, especially related to multi- ational projects. This was especially relevant because I was recently contracted to provide analysis and risk assessment services for a global information technology project by a client in San Antonio, Texas. Since I am under strict non-disclosure constraints, I cannot discuss strategic details nor reveal specific technologies associated with the project, however, a general description of the services and methods employed is possible.
And I am able to divulge that the working title of the analysis is: "Project Rodeo. " My intention is to show that the current client need not learn any lessons the "hard ay:'' but that the potential risks and failures associated with this project are identifiable and, thus, preventable. As Michael Eisner said: "Everyone in business makes mistakes. If you didn''t take risks, you''d never get anything done. The sin would be if you made the same 4 mistake more than once. " Merrow, E. , Phillips, K. , Myers, C. 1981. "Understanding cost growth and performance shortfalls in pioneer process plants. " Santa Barbara, CA; Rand Corporation. project failures. " Van Nostrand Reinhold, New York, NY. 3 Ibid, preface, p. x. 4 Michael Eisner, Chairman and CEO, Disney Corporation, 1995; quoted in Henkoff, R. 995. "Smartest and dumbest managerial moves of 1994," Fortune, Jan 16, p. 59. Page 3 Through careful Analysis a n d Risk Assessment, the key prerequisites to any project, we can assist the client in avoiding mistakes and calculating the risks well in advance of any major financial commitment. But before we get into any specifics, we need to establish the framework of successful Information Technology (I. T. ) project management.
Project Framework First of all, we must agree that there is no such thing as a "frozen specification" in the real world. Life and business are subject to change as the market changes or as echnology evolves. Knowing this in advance forces a good project manager to adopt a reiterative approach to the design of the finished product or service. For I. T. projects, I have found the "Six Ds" to be a successful approach, consisting of the following deliverables: Discover, Design, Develop, Debug, Document, and Deploy. Figure 1 illustrates the sequence followed. Discover Deploy Design Document Develop Debug SOURCE: Larkin Industries, Inc.
Used by permission Figure 1. Reiterative I. T. Project Deliverables. Not only should the entire project be managed in this sequence, but each pattern. In the high-technology field, even after a product has been successfully deployed, it should be continuously revisited, re-analyzed and revised to stay ahead of the market. A discussion of each deliverable follows. Discover This is the analysis phase of the project, where we discover the needs of the client or end-user, in order to devise a blueprint for achieving the stated goals and to successfully complete the project.
Is this project even feasible? The answer must be found during this initial phase. The more knowledgeable we become in the beginning, before large resources have been committed to Page 4 evelopment, the more accurate and cost-effective the ensuing development will be. For this reason, Discovery is the most important deliverable. For example, if one''s goal is to develop an office building, it is not wise to start with a builder; one must first allow an architect to "discover" the needs and desires of the client, and to present a concept from which clear decisions can be made.
A "golden" principle of project management for information technology development is: Never be in a hurry to start writing programs. The more time spent in analysis and design, the less time wasted rewriting programs later on. As Kharbanda says, "Research and development are twin pillars. One without the other often signals a sure recipe for disaster. "5 In order to ascertain any preliminary cost estimates, the project deadlines, equipment and material requirements, and human resource needs must be estimated.
In addition, we must determine the general areas of development in both software and hardware that are required to make the final solution workable. How are these elements analyzed? Kharbanda''s approach is useful: "Planning must always take into account the ultimate goal in terms of what is needed to obtain [client] pproval. Once the final goal is set, 6 one works backwards to complete the entire development plan. " During discovery, we make our first attempt at a cost estimate, although this is usually understood to be a "rough guess. All parties to the project must understand that legitimate cost estimation can only arise when some basic design has been completed. Without such understanding and agreement, the project should go no further. To arrive at a rough cost estimate, most American project consultants follow the procedure: design, estimate each resulting component, and add up the costs. Other ultures do it in reverse. For example, in Japan, they start with the market''s likely selling price, then work backwards to the cost in order to calculate the project''s internal rate of return (the Sony Walkman"* was developed this way).
A "market price" is not always valid for non-consumer high-tech projects, but my experience indicates that, to approach the "real" cost of an I. T. project, I start with my normal cautious double it! Historically, this formula has kept my projects within a mere 10 percent error rate. Additional rules-of-thumb I have used in I. T. projects where, after realistic time stimates have been presented, the client wishes to "compress" the project time: For each one percent reduction in project duration, the project cost will rise by 1. 75 to 2. 0 percent. 5 Kharbanda, O. P. nd Pinto, J. K. 1996. "What Made Gertie Gallop: Learning from project failures. " Van Nostrand Reinhold, New York, NY, p. 265. 6 Ibid, p. 10. Page 5 In assessing failed projects, Kharbanda nails this point home: "... [M]any problematic projects or outright failures were often handcuffed by utterly unrealistic scheduling and budgetary constraints at their conception. "7 Finally, our analysis must identify he risks likely to be encountered during the project and suggest appropriate counter-measures to manage those risks. On this topic, Kharbanda spends a great deal of time.
For example: every field of activity, there is always an element of risk. The real test of good project management is to try to reduce these risks to the barest minimum and/or acceptable level through meticulous planning, execution, control, and above all, motivation of the entire 8 project personnel. " The principle issue that must be addressed as part of any project''s risk analysis is the degree to which various forms of trouble are prevalent and predictable. The best approach is to expand risk analysis to take into consideration a greater degree of uncertainty.
Other authors concur: The number one cause of project failure was the inability or unwillingness of the project manager and team to engage in the What 9 if? troubleshooting guesswork before problems came to the surface. It should now be crystal clear that the "Discovery'' phase is extremely important, and that considerable time should be devoted to this effort. In the process of analyzing all aspects of the project, the project manager will gain the additional benefit of iscovering the political environments and individual personalities of all parties to the project.
Once we have done our homework, we fully understand the concepts of the project, and the client has approved the "big picture," the next step is to perform the necessary engineering and detailed analyses to prove the viability of the previously discovered solutions. To continue our office-building example, after obtaining an architect''s drawing, the next step is to enlist electrical, fluid, mechanical, and structural engineers to "flesh out" the concepts with precise drawings and specifications.
The resulting documents should now be "portable," meaning that any builder could complete the project by following the engineers'' instructions. In I. T. parlance, this phase results in flowcharts, system diagrams, data models, user interface designs, and other technical information. The final component of the design phase is the real cost estimate for the project, which takes into consideration any new elements discovered during "engineering. " 7 Ibid, p. 22. 8 Ibid, p. 81. 9 Pinto, J. K. and S. J. Mantel, Jr. 1990. "The Causes of Project Failure," on Engineering Management, EM-37, no. , pp. 269-276. Page 6 IEEE Transactions This is also an important opportunity for the client to cancel the project based upon the detailed evidence and updated cost estimates obtained. Some clients may consider this option a sign of failure. I disagree, as does Kharbanda; to wit: ". [C]ancellation is a realistic option. A company that is bold enough to cancel a project and acts early enough, will indeed cut its losses. Such a decision, however, requires as much, or even more, rigour [sic], analysis, and discipline as the decision to launch a new project.
Project cancellation should not be seen as a failure, but rather as a 10 ey decision in the company''s strategy. " While this stage in the project is not a "point of no return," the client must ensure by whatever means open to it that early estimates are sound, based on a completed basic design. Once Development has started, it is crucial that every change in scope is identified, scrutinized, recognized, authorized, and publicized, in order to answer the question: "must we have it? " impact on the fate of the project.
Each change request should come with a complete and clear description, Justification for the change, and the expected impact on both time and budget constraints. In most cases, a change in project scope will necessarily require additional time and budget allowances. Develop While the previous deliverables are typically documents and diagrams, the "Develop" phase appears more tangible - hardware is being purchased and installed; software is being written; the full force of the project team is onboard; but the potential risks are mounting.
At this point, if either the Discover or Design steps have been skipped by the client, the risks of project failure are multiplied by an order of magnitude, including missed deadlines, cost overruns, missed features, inadequate testing, and o forth. Assuming we can begin Development, often, it is necessary to first develop small- scale prototypes of the most critical technologies before committing to major systems, thus reducing risks along the way. The key is that the most crucial - and difficult - steps (discovery and design) have been completed, reducing any further questions about the scope and content of the overall project.
Any specification changes at this point, if not properly managed, further multiply the risks of failure. It is a scientific fact that engineers, if not time-constrained, will by nature continue to improve and perfect their designs. Project managers are often damned if they allow it, and damned if they don''t. In order to get the technology perfect, we sacrifice time. In order to accelerate a project, we sacrifice budget money. The most important ingredient in the project management mix, at this stage, is communication. Kharbanda sums it up succinctly: "Effective communications are 10 project failures. Van Nostrand Reinhold, New York, NY, p. 323. page 7 essential to the successful execution of any project. "11 All parties must know what is expected of them, and by when those expectations are to be realized. The project anager must be acutely aware of both time and budget, and must enforce the quality of the project output according to (or exceeding the spec''s). My favorite method of managing a complex project is to "show up and walk through it. " Problems are often not communicated effectively in memos and phone calls. By seeing and hearing them firsthand, problems can be resolved on the spot.
One problem faced by project managers during development is external interference. Interference, whether political or bureaucratic, encroaches on both time and budgetary resources, and is a primary cause of failure to meet deadlines or cost imitations. Statistically and historically, projects and politics do not mix, and any attempt to mix them often leads to disaster. When political expediency continues to Projects often fail "due to management''s inability to refocus from the micro approach that consumes much of the project manager''s day, to a strategic, overall macro focus on the direction the project is taking. 12 This is the project equivalent to rearranging deck chairs on the Titanic. In order for oversight to remain objective while eliminating the need for daily "micro- management," larger projects should be reviewed (audited) periodically, both before nd during each major milestone, by representatives from five disciplines appointed by the client: research, marketing, strategy, operations, and finance. 13 This is the least intrusive and disruptive to the project team while providing the necessary feedback between the client and the project manager.
Debug Thorough testing and benchmarking are imperative, especially when developing new technologies. It is dangerous to assume technology that works well in one setting will work equally well in another, particularly when other variables in the equation are subject to change. During this phase of the project, each component - hardware or software - is stress- tested against real-world environments, first as separate units and then in the context of the entire project. Benchmarking and field evaluations ensure that components are performing according to specification, or in line with customer acceptance.
Only after thorough testing should any component, no matter how trivial, be signed off to production. Once all components have been tested individually, the integrated solution can be tested against client-determined performance needs and acceptable rates of failure. 1 Ibid, p. 86. 12 Ibid, p. 67. 13 Lambrix, R. J. and Singhvi, S. S. 1984. "Preapproval audits of capital projects," Harvard Business Review, Vol 62, March/April, pp. 12-14. Page 8 All "debugging" and system integration testing should be performed in such a way as to apply the real-time stresses of the production environment to the subject system.
The entire project, and its management, will live or die by how effective its represent the core of any system whereby project management can be assessed in ''real time. "14 There are many categories of documentation. Technical documentation is used nternally to memorialize the designs of each product, and to provide assistance in maintenance and troubleshooting efforts. User documentation teaches the end-user, or customer, how to use the technologies and how to resolve problems encountered in the field (problems we should have determined in prior analysis and testing).
All user documentation should be written for the lowest level of literacy amongst its potential readers. In other words, if 6th- graders are using the product, the documentation should be written so that 6th- graders can understand and benefit from it. Management documentation is the edium for communicating overall project status, financial reports, resource requirements, and other high-level topics. Documentation can take many forms, and tends to be most conveniently published online these days, however, printed documentation will often be required in the field where Internet connections are unavailable.
For global projects, all user documentation should be provided in multiple languages. This further supports the requirement that complete Discovery, Design, Development and Debugging be performed prior to writing user documentation - we want to translate the text into multiple languages only once. The final component of "Documentation" is the availability of live, technical user support and field training, if applicable, without which final deployment of the project should not be allowed to proceed. The client should be made aware of the costs of such support and training well in advance of deployment.
Deploy Now that all products and technologies have been researched, developed, fully tested and documented, the initial users have been trained, management has approved the results, and the project manager is prepared, the project is ready for deployment. Depending on the scope of a project, a few components may be "phased in" over time, or many components deployed to a small geographic region before expanding the project to larger areas. The process of deployment is subject to vulnerabilities, requiring strict project management to reduce further risks. 4 project failures. " Van Nostrand Reinhold, New York, NY, p. 55. Page 9 At this Juncture, if there is anything we have "discovered" in the finished product that could be improved, the information is communicated to the client in preparation for a reiteration of the "Discovery'' process, under a new project framework! With maintenance upgrade. In many cases, parallel projects - following the same reiterative pattern as we have established - can be used to develop new releases of the original product.
The key is to actually have succeeded with the initial project before a larger scope or version is deployed. In my experience, "deployment" is not complete until the customer is satisfied and all bills are paid. A project is no better than its ultimate use. Thus, a completed project that goes unused is a failure, and is indicative of a lack of prior analysis. Final Lessons From reading Kharbanda and other sources, and after my own project management experiences, I have learned some valuable lessons, which can be applied generally to projects large and small.
First, projects have four common dimensions: 1 . They are constrained by a finite budget and timeframe to completion; 2. They comprise a set of complex and interrelated activities that require effective coordination; 3. They are directed toward the attainment of a clearly-defined goal or set of goals; and 4. To some degree, each project is unique. Second, the "art" of project management can be condensed to two words: cost ontainment. That is, if you look at it from the client''s perspective.
From a project manager''s view, we are subject to many forces and are constrained by four general "specifications:" 1. Time; 2. Money; 3. Performance; and 4. Customer satisfaction. The last item, "customer satisfaction," has not always received the importance it deserves by project managers, especially since it often requires additional time and attention maintaining close ties with and satisfying the demands of "external" clients. Some managers prefer to include the concept of "customer satisfaction" within the performance" specification.
However, after studying the lessons from past failed projects, I am convinced that customer satisfaction should be separate and equal to the other concerns. Finally, business leaders should also learn from failed projects. The majority of mistakes identified from project disasters throughout the world can be attributed page 10 to a violation of one or more of the seven lessons, described by Kharbandal 5 below: 1 . Put professionals in charge and allow them to operate as the real champions; 2. Organizations must be flexible and adaptable to respond to their environment;
No comments:
Post a Comment