Fluent Essays

As the project manager for the Lucky Me Animal Rescue annual adoption event, you have noticed that most project team members do not fully grasp the tasks that take place during the closing process group, nor do they fully understand the lesson learned process. Therefore, you must prepare a PowerPoint presentation to use during a training that you will hold for the project team members as you prepare to enter this phase of the project. Your PowerPoint presentation must address the prompts below. · Explain each of the tasks in the closing process group. . You may use the sample closing checklist provided in the unit lesson as a baseline or follow a different version with which you are familiar or have found in your research. . Use the animal adoption event project to illustrate how each task is applied. · Evaluate the lessons learned from the animal rescue project. . Be sure to present the information in a way that will help the team understand the value of this task to the organization and/or future projects and teams. . You will need to hypothesize at least three lessons learned on which to base your evaluation. Choose realistic examples that would have been documented in the lessons learned register throughout the course of this project and that can serve as valuable training opportunities for your team. Your PowerPoint presentation must be a minimum of 10 slides in length, not counting the title and reference slides. You must utilize the speaker notes function in PowerPoint to elaborate on your slide content. Each content slide must have a minimum of 75 words in the speaker notes area; however, ensure that you are not repeating actual slide content. You must use at least two sources that are peer-reviewed or academic in nature, one of which may be the textbook. Adhere to APA Style when creating citations and references for all sources used. MGT 6302, Project Management Strategy and Tactics 1 Course Learning Outcomes for Unit VII Upon completion of this unit, students should be able to: 3. Summarize the project management process groups. 3.1 Explain the tasks completed during the closing phase of a project. 3.2 Evaluate lessons learned in a project. Course/Unit Learning Outcomes Learning Activity 3.1 Unit Lesson Part 2: Chapter 6 Article: “A Case Study of Project and Stakeholder Management Failures: Lessons Learned” Article: “Project Teams and KM--Part 3 The Benefits of Identifying and Sharing Lessons Learned Across Projects” Unit VII PowerPoint Presentation 3.2 Unit Lesson Part 2: Chapter 6 Article: “A Case Study of Project and Stakeholder Management Failures: Lessons Learned” Article: “Project Teams and KM--Part 3 The Benefits of Identifying and Sharing Lessons Learned Across Projects” Unit VII PowerPoint Presentation Required Unit Resources Part 2: Chapter 6: Closing Process Group In order to access the following resources, click the links below. Sutterfield, J. S., Friday-Stroud, S. S., & Shivers-Blackwell, S. L. (2006, December). A case study of project and stakeholder management failures: Lessons learned. Project Management Journal, 37(5), 26–35. https://libraryresources.columbiasouthern.edu/login?url=https://search.ebscohost.com/login.aspx?dire ct=true&db=bsu&AN=23858910&site=ehost-live&scope=site Trees, L. (2018). Project teams and KM--Part 3 The benefits of identifying and sharing lessons learned across projects. KM World, 27(1), 25–29. https://libraryresources.columbiasouthern.edu/login?url=https://search.ebscohost.com/login.aspx?dire ct=true&db=bsu&AN=127652523&site=ehost-live&scope=site Unit Lesson Introduction In Unit VI, we focused on the controlling process group, which takes place during the execution phase. In Unit VII, we will focus on the final process group, which is the closing process group. In many instances, the project team is excited to be done with the project, and the closing process group often does not receive the attention that it needs. The closing process group includes all of the final processes that are necessary to close out the project and deliver the final project deliverables to the project stakeholders. Finishing strong is important in any project, as this ensures that all details have been finalized, and the project stakeholders will UNIT VII STUDY GUIDE Closing https://libraryresources.columbiasouthern.edu/login?url=https://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=23858910&site=ehost-live&scope=site https://libraryresources.columbiasouthern.edu/login?url=https://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=23858910&site=ehost-live&scope=site https://libraryresources.columbiasouthern.edu/login?url=https://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=127652523&site=ehost-live&scope=site https://libraryresources.columbiasouthern.edu/login?url=https://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=127652523&site=ehost-live&scope=site MGT 6302, Project Management Strategy and Tactics 2 UNIT x STUDY GUIDE Title be left with a positive impression of the project manager and the project team. It is the responsibility of the project manager to ensure that all contract obligations have been met and signed off on by the project stakeholders. Until the final sign-off has occurred, the project is not officially closed. Lessons Learned The closing process group is essential not only to officially close the project, but it also serves as an opportunity to review the lessons learned. These lessons learned, which you have been documenting in the lessons learned register throughout the project, are listed below: • techniques, tools, or technology that were particularly helpful (or a hinderance) in maintaining the project scope, schedule, and budget; • variances that occurred, corrective actions that were applied to the variances, and effectiveness of corrective actions; • claims; and • general information on how to improve the process. The lessons learned process includes the five steps, which are shown below. Lessons learned are used by the organization, project managers, and project teams in their future planning processes. The more information that can be collected, the more data that will be available for future teams to use to make informed decisions about their projects. Let’s dive deeper into the tasks completed during the closing process group. Closing Out the Project Most projects are quite complex, and as a project progresses, more workflow is usually required. The projects end can create as many details as were found in the initiation and planning process groups. Even if the project experienced proper execution of all activities and the project manager conducted monitoring and controlling of all processes, there are still many tasks to ensure that the project comes to a successful close. As noted in the textbook, the closing process group consists of those processes performed to conclude all activities across all project management process groups to formally complete the project, phase, or contractual obligation (Project Management Institute [PMI], 2017). To learn about the activities involved in the closing process group, we will explore the processes involved to ensure that the project is closed out correctly and effectively. Closing Project Process For the closing process group, there are three outputs that should be completed. They include the final product, service/result transition, and the organizational process assets update. The final product is the actual deliverable that was created based on the projects scope. For the project to be approved, the project stakeholders will review the scope and determine if the final product includes all of the requirements as stated in the scope statement. The service/result transition is the process of taking the project deliverable and beginning implementation. For example, if the project were to create new time tracking software for employees to record their time, the next step would be to transition the software from the hands of the project team to the end users. It is important to note that even if the deliverable is completed, there may be additional steps before the final product can be used. In our example, installing the software may not have been in the scope of work for the project team, so the information technology department would be responsible for the MGT 6302, Project Management Strategy and Tactics 3 UNIT x STUDY GUIDE Title final implementation. The final output is to provide an update to the processes that may have been impacted from the final product. Most organizations map out their operational processes; therefore, any change to the products used to complete the operations must be updated to reflect the changes. The organizational process assets update is a more complex process and will take the project team time to complete. This update involves recording all of the project’s artifacts, such as the project management plan, the risk register, and the stakeholder register. Formal documentation must be completed for the completion of the project. The project manager and the project stakeholders will review all contracts to ensure that the stakeholders accept the final project. An essential activity that takes place during the update is the process of documenting all lessons learned from the project. The lessons learned will assist future project managers with areas to avoid and areas to focus on to ensure project success going forward. Lessons learned can only be captured if the project had the correct monitoring and documentation during the project. The lessons learned should not only focus on the problems encountered; it should also document the successes that the project team experienced. Close Procurements Process Once the project has ended, it is important for all contracts to be closed out as well. The contracts are the agreements between the project stakeholders and the project manager for the expectations of the project. In addition, separate contracts may have been created for the budget, the schedule, and various phases of the project. The project stakeholders and the project manager should review all contracts, and the project stakeholders must sign off on all contracts before the project can be officially closed. Any bank account or other financial account created for the project should also be closed. Any additional funds in the accounts should be delivered to the project stakeholders. Closing the contracts and all accounts ensures that the project can be archived and officially closed. Remember, to be a project, there must be a start date and an end date. Within the closing process group, there are two processes of focus, which include closing the project and closing procurements. A project may be closed and not accepted by the project stakeholders. This could be the case for a cancelled project or one that stakeholders do not accept but do not want the same team working on. Until the project is officially closed, the procurement process cannot begin. The procurement process, as noted above, is the final step in the project management cycle (PMI, 2017). Closing Checklist Due the complexity of the closing process, it is important for project managers to create a checklist to ensure that no task is forgotten. Below is a sample checklist that would be suitable for most projects.  Create closing procedures. Closing procedures help you to complete the closing process smoothly and should include which member of the project team will be responsible for certain tasks. The project manager should review all tasks to ensure they were completed correctly.  Complete all contracts. This item is usually completed several times for each contract that the project manager created. The contracts could be with various stakeholders. The process is continued until all contracts have been closed.  Verify the deliverable to the scope requirements. This is an important step, as the deliverable must match the projects scope to be accepted by the project stakeholders. If not, the project stakeholders will not sign off on the project.  Obtain acceptance from the stakeholders. The stakeholders will likely have their own process for reviewing the projects deliverable, but the project manager should ensure that the scope is used and verified by the project stakeholders.  Submit the final performance reports. The project manager is responsible for creating performance reports for all project members. This is not only important for the project itself, but it is also important for the members. Most project members will be seeking additional projects, and the performance reports can be used in this process.  Index and archive all of the projects records. This task is important so the records can be easily accessed, as needed.  Document the projects lessons learned. The lessons learned are documented for the benefit of other project managers. They can learn from the project and the positives and negatives that were experienced. This information allows project managers to have a baseline for their planning; therefore, they do not have to start from scratch in the planning phase.  Hand-off the completed project deliverables to the end users for the project stakeholders. The project MGT 6302, Project Management Strategy and Tactics 4 UNIT x STUDY GUIDE Title stakeholders will now be responsible for the additional decisions made regarding the project’s deliverables.  Release the team from the project. The project team members will likely return to their normal position or seek another project to join.  Celebrate! If the project was a success, the project team should take the time to celebrate the win and have one last team-building moment together. Conclusion The closing process group is the final stage of the project. During the closing process group, the project manager and the team are responsible for ensuring that all tasks have been completed and the project is ready to end. The final closing procedure cannot be completed without the final sign-off from the project stakeholders. These stakeholders will verify that the projects deliverables meet the agreed-upon scope. If the stakeholders accept the project, the project team will have met all of its obligations. Before returning to their day-to-day job or moving on to another project, the project team will take the time to record the lessons learned. The lessons learned process includes five steps: identify, document, analyze, store, and retrieve. This data is used by future project managers during the planning of their projects and provides a baseline of the information needed to plan and execute successful projects. Reference Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK® guide) (6th ed.). https://online.vitalsource.com/#/books/9781628253900 Suggested Unit Resources In order to access the following resource, click the link below. The following study explores the significant challenges faced by government and business project delivery organizations to ensure that lessons are learned and that mistakes of the past are not repeated. Paver, M., & Duffield, S. (2019). Project management lessons learned: “The elephant in the room”. Journal of Modern Project Management, 104–125. https://libraryresources.columbiasouthern.edu/login?url=https://search.ebscohost.com/login.aspx?dire ct=true&db=bsu&AN=134748811&site=ehost-live&scope=site Learning Activities (Nongraded) Nongraded Learning Activities are provided to aid students in their course of study. You do not have to submit them. If you have questions, contact your instructor for further guidance and information. Visit the website YouTube, and perform a search for each of the following keyword search terms to view a wide variety of resources that offer additional insight into this unit’s topics. Note the channels or authors whose videos you find most helpful, and consider bookmarking or subscribing to them for continued professional development. It is suggested when looking for online resources, you choose those that are most recent, as they will offer the most up-to-date information. Keyword search terms for this unit are listed below. • Project management closing • Project management lessons learned https://libraryresources.columbiasouthern.edu/login?url=https://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=134748811&site=ehost-live&scope=site https://www.youtube.com/ Course Learning Outcomes for Unit VII Learning Activity Required Unit Resources Unit Lesson Introduction Lessons Learned Closing Out the Project Closing Project Process Close Procurements Process Closing Checklist Conclusion Reference Suggested Unit Resources Learning Activities (Nongraded) A CASE STUDY OF PROJECT AND STAKEHOLDER MANAGEMENT FAILURES: LESSONS LEARNED Stakeholder theory is a useful framework for analyzing the behavioral aspects of the project management process, particularly the complicated process of project man- agement within the Department of Defense (DOD). Projects can be beset by the agenda of various stakeholders within the organizational structure. When this occurs, the implementation of a strong project stakeholder management strategy is necessary to increase the likelihood of success. This is a case study of a failed DOD project, even though it was fully jus- tified and badly needed. Stakeholder the- ory serves as the theoretical underpinning of this case analysis, which identifies the potential causes of the project failure. Project management lessons learned from the failure and a project stakeholder man- agement strategy framework are present- ed to facilitate better decision making on the part of project managers to increase the likelihood of successful project man- agement outcomes. Keywords: Project management; project stakeholder management; stakeholder theory; decision-making ©2006 by the Project Management Institute Vol. 37, No. 5, 26-35, ISSN 8756-9728/03 Introduction P roject management within the United States Department of Defense (DOD) has been described as the one of the world’s most complicated processes. Successful completion of a project may require several years and the develop- ment, implementation, and evaluation of a successful project management strategy. DOD projects are difficult to manage even under the best of circumstances due to var- ious structural, behavioral, and environmental complexities. Many of the complexi- ties stem from the fact that the project manager is likely to be beset by various project stakeholders from above and below. A thorough canvassing of the literature has dis- closed that, while research on various project stakeholders has received attention, there is a lack of research that actually examines the process management process through the theoretical lens of stakeholder theory (e.g., Bourne & Walker, 2005, 2006), as well a lack of research that has applied both stakeholder theory and the strategic management process to the project management process (e.g., Ives, 2005; Jugdev & Muller, 2005; Norrie & Walker, 2004). Therefore, this paper fills a void in the literature by using stakeholder theory and the strategic management process as the theoretical lenses through which to analyze the case study of the DOD lighter amphibian heavy-lift (LAMP-H) project, and to offer a project stakeholder manage- ment (PSM) strategic framework. The management of various project stakeholders from above and below the proj- ect manager can either positively or detrimentally impact large-scale projects within any organization. The type of impact can be largely influenced by the management of various project stakeholders as was the case with the DOD LAMP-H project. From above, senior financial executives are project stakeholders who are constantly seeking to re-allocate the funds that have been justified by a project manager for his or her program. From below, functional managers are project stakeholders who are solici- tous of protecting their vested interests. Functional managers may consider the authority and latitude for independent action accorded the project manager by sen- ior DOD management to be an encroachment upon their authority. They are con- cerned with full compliance, and therefore require the project manager to comply with each and every regulation pertaining to their separate functional areas. Oftentimes, this is counter to the project manager’s acquisition-streamlining strategy and project completion timeline. In many cases, full compliance lengthens a DOD project’s time to field to 10–15 years, which is an issue that can greatly increase proj- ect costs and timelines (Griffard, 2002; Office of Inspector General, 2001). ABSTRACT J. SCOTT SUTTERFIELD, Florida A&M University SHAWNTA S. FRIDAY-STROUD, Florida A&M University SHERYL L. SHIVERS-BLACKWELL, Florida A&M University D E C E M B E R 2 0 0 6 P R O J E C T M A N A G E M E N T J O U R N A L26 D E C E M B E R 2 0 0 6 P R O J E C T M A N A G E M E N T J O U R N A L 27 This case study of the DOD LAMP-H project is used to illustrate many of the conceivable stakeholder management pitfalls that a project manager can encounter if a PSM strat- egy is not effectively developed, implemented, and evaluat- ed within the project management process. The format of this paper will include a brief background on stakeholder theory and the LAMP-H project. Next, the various LAMP-H project phases will be analyzed, along with the activities of the various functional concerns at each phase. This will be followed by lessons learned from the LAMP-H project. Lastly, a PSM strategy will be presented to fill a void in the literature and delineate a strategic framework that can be used to enhance project managers’ abilities to effectively manage various project stakeholders earlier in the process. The proposed PSM strategic framework should also facilitate project managers’ decision-making capabilities and increase the likelihood of successful project outcomes. Stakeholder Theory A generally accepted definition of a stakeholder is any individ- ual or group of individuals that are directly or indirectly impacted by an entity or a task. More specifically, the term project stakeholder will be used throughout this paper to refer to any individual or group of individuals that is directly or indirectly impacted by a project. Stakeholders can be internal or external to the project team or they can be internal or exter- nal to the project scope. Therefore, the determination of whether an individual or a group of individuals is internal or external to a project is dependent upon the point of view of the observer. Although there are various perspectives of stake- holder theory (e.g., social science stakeholder theory, instru- mental stakeholder theory, and convergent stakeholder theory), one common denominator of all the perspectives is that stakeholders perceive that they have stake in the entity or task. As a result of their perceived stake in the entity or task, they have certain expectations, and consequently, engage in certain types of behavior, sometimes constructive and some- times destructive (Bourne & Walker, 2006). Within the project management process, various stake- holders have or perceive that they have various stakes in the project. Based on their perceived stakes in the project, stakeholders behave in ways in which they feel will help them accomplish their project objectives, which may be congruent on incongruent with the project manager’s proj- ect mission, vision, and/or objectives. Therefore, it is incumbent upon the project manager to understand the objectives of each project stakeholder in order to effective- ly manage his or her needs and desires. In order to achieve a successful project outcome, the project manager must be adept at managing the interests of multiple stakeholders throughout the entire project management process. Therefore, it is argued that a strategic PSM framework can aid project managers in maximizing the potential positive impact, while minimizing the potential detrimental impact that project stakeholders can have on the outcome of a project. Hence, a PSM strategy will be offered after the analysis of the DOD’s LAMP-H project. LAMP-H Project Background The LAMP-H project was initiated by the U.S. Army to acquire crafts with amphibian (movement over land and water) and heavy-lifting capabilities. The Army had identi- fied these requirements as essential for logistic resupply mis- sions for numerous areas of interest around the world to support ground troops during amphibious assault missions. The LAMP-Hs would follow the troops from large carrier ships to land and provide them with the supplies necessary to sustain their ground assault. In order to be effective, the LAMP-Hs would have to meet certain payload and speed requirements. Some stakeholders thought that the LAMP-H should be capable of carrying two M-70 tanks, a payload of approxi- mately 140 tons, at a relatively low airspeed. Other stake- holders argued that it should have a lower payload and be able to fly at a greater airspeed. On a different front, some stakeholders believed that the LAMP-H should be powered by paddlewheels that would propel it through the water until it reached the beach, and thereafter by large deeply treaded tires over the sand. However, other internal stake- holders believed that two large Archimedean screws should power it. They argued that this would suffice for propulsion over sea or sand. Still other stakeholders argued that the LAMP-H should be driven with ducted propellers. Along with all this diversity of opinion from various project stakeholders, there was also wide disagreement as to how many LAMP-H units should be purchased and at what unit price. Finally, the user of the system, the Transportation School (T-School), wavered on its want or need for the LAMP-H system. Although the program had floundered along for about 10 years, it is likely to have survived as a result of the “seductive appeal of collective belief” (Royer, 2003) by those involved with the project because of their perceptions regarding the importance and significance of having LAMP-Hs in the Army’s arsenal. Early Program Development The project manager of the LAMP-H project knew that he had to manage various LAMP-H stakeholders. However, he was surprised at the great diversity of opinion surrounding the LAMP-H project, and wondered how any project could have become so controversial. There was great diversity among the project stakeholders as to the technical require- ments and configuration for the LAMP-Hs, the acquisition strategy for the system, and funding source and cost of the LAMP-Hs, with the threat of funding cuts being a showstop- per. Thus, it became immediately evident to the project manager that in order to support funding for the LAMP-H, and to put an end to all speculation as to what the LAMP-H configuration should be and how it would be acquired, a requirements analysis was needed. Therefore, the project manager immediately initiated one with an independent systems analysis organization. Positive results from the requirements analysis breathed new life into the LAMP-H project. To grasp the vital importance of the requirements analysis in defending the budget for the LAMP-H project, it D E C E M B E R 2 0 0 6 P R O J E C T M A N A G E M E N T J O U R N A L28 is necessary to understand the organizational structure with- in the DOD, and specifically within the Department of Army. This can be better understood by viewing the organi- zational chart in Figure 1. With this organizational structure, the line of authority for the watercraft project manager reached through the Troop Support Command, through the Army Materiel Command, and to the Department of Army staff. Practically, this meant that the Army Materiel Command controlled the funds for all watercraft project managers’ programs and projects. The project manager used the positive results from the requirements analysis to build consensus among the var- ious stakeholders to demonstrate the need for the LAMP-H project. This consensus building was done by starting with the highest levels of management within the Department of Army down to the DOD staff and briefing them on the results from the requirements analysis. Once the Department of Army staff had a basis for defending the LAMP-H project, the Army Materiel Command no longer cut funds and the project was able to make progress. The project manager also developed an acquisition strategy con- sistent with the technical requirements shown to be neces- sary for the LAMP-H craft, based on the results of the requirements analysis to further solidify the program. After reviewing the final results of the requirements analysis, it became obvious that the initial payload and speed requirements had to be altered; but the project man- ager was finally able to identify the cost per unit. This pro- vided the project manager with enough information to ensure that adequate funds were appropriated for the acqui- sition, and to refine the acquisition strategy. The T-School, one of the stakeholders, became an enthusiastic supporter of the LAMP-H project when results from the final require- ments analysis were available. However, because the techni- cal specifications developed by the Watercraft R&D Center, another stakeholder, were shown to be technically incorrect, their support only appeared to be half-hearted. Nevertheless, the project manager had accomplished a major feat—the LAMP-H project was established as a viable project. As it turned out, problems with the LAMP-H project were only beginning. Mature Program Development Shortly after the LAMP-H project was solidified as a viable project, two very significant changes occurred in the senior leadership of the project manager’s organization. First, a senior position called the program executive officer (PEO) was established and filled by a senior Department of Army staff member with no acquisition experience. Numerous PEO positions were established throughout the Department of Army to provide an executive sponsor for each program. Figure 2 shows how the new PEO structure affected the lines of authority in the Department of Army organizational structure. After implementation of the new PEO structure, the project/program managers were taken from under the Troop Support Command, and placed under the authority of the new PEO. The PEOs reported directly to the Assistant Secretary of the Army for Research, Development and Acquisition (ASARDA). Practically, this meant that the PEOs were placed in charge of all programs/projects, and that the Army Materiel Command no longer had any management Figure 1: Army structure before implementing the PEO D E C E M B E R 2 0 0 6 P R O J E C T M A N A G E M E N T J O U R N A L 29 control of the programs and could no longer take funds from programs. This was an early attempt to achieve what Matta and Ashkenas (2003) called “balancing vertical and horizontal activities.” This combined with a matrix manage- ment approach provided the capability to achieve rapid results both vertically and horizontally. This is precisely what the Department of Army envisioned in reorganizing to the PEO structure (Kerzner, 2003). The second change that occurred in the leadership of the watercraft project manager organization (the home of the LAMP-H) was the arrival of a new project manager. This new project manager had also come directly from the DOD with an excellent acquisition background. He had recently completed the program management school taught by the DOD where he had imbibed many new ideas and approach- es as to how systems should be acquired. One such idea was that the project manager should be firmly in control of his programs. He also accepted new approaches regarding con- current engineering and the need to build prototypes on production tooling in order to minimize the number of changes to a system configuration. He had become a staunch advocate of the Army Streamlined Acquisition Program (ASAP) approach to systems acquisition, and there- fore, was an enthusiastic supporter of the LAMP-H acquisition strategy. The former project manager had become the deputy project manager, and also believed in the validity of these ideas and approaches and was an enthusiastic supporter of them. This eventually proved to put the new project manag- er and his deputy in direct conflict with the functional man- agers and workers that the project managers relied on for matrix support (Kerzner, 2004; Killian, 1971). It also turned out to put them at odds with their new boss, the PEO. Although he ostensibly supported the LAMP-H program, it was later discovered that he secretly entertained great reser- vations about it. Due to his lack of knowledge about the acquisition process, the PEO was very leery of adapting any new innovations to the acquisition process. Also, the new PEO preferred to avoid conflict with functional managers and workers. Consequently, he became very nervous with the disagreements that the functional managers and workers had regarding the new approaches taken by the new project manager and the deputy project manager. The first indication of the PEO’s true intentions about the LAMP-H project came when the R&D funds for the LAMP-H project were cut. In order that the program not suf- fer a break in activity, it was essential that the R&D funds be restored. It was well within the power of the PEO to restore these funds; but he continually delayed in doing so until the entire acquisition strategy had to be revised and the program rejustified because of slippage. It later became clear that he supported the termination of the program due to the com- plexities associated with an R&D program with two IPRs. Another factor that delayed the program was the failure of the T-School to complete the required operational capa- bility (ROC) document in a timely fashion. In DOD acqui- sitions, the ROC is an indispensable document (Metzger, 2003). The ROC lends legitimacy to a project by specifying the exact capability to be acquired. This document had to be approved before R&D funds could be spent in further proj- ect development. Although this document should have been approved years before, it had only been circulated in draft form and had existed in that form for seven years with almost no attention, even though the T-School had been Figure 2: Army structure after implementing the PEO D E C E M B E R 2 0 0 6 P R O J E C T M A N A G E M E N T J O U R N A L30 point out that it is the responsibility of senior management to maintain the vision. In the case of the LAMP-H project, the project manager and the deputy project manager regu- larly refreshed the project team on the project vision in staff and team meetings. Thus, momentum was gained and maintained. This perpetuation of the project’s vision was vital to the LAMP-H project’s advancing as far as it did. The strategic management literature suggests that a project mis- sion to set forth the purpose of the project would also con- tribute to successful project outcomes (David, 2005). But, the LAMP-H mission or purpose did not receive the same type of reinforcement as the project vision. Kerzner (2003) pointed out that a project is formally defined by specifying its objectives or requirements in a requirements analysis. This is the third of the life-cycle phas- es in normal civilian projects, but it is the second significant step in the military acquisition cycle, with the first being the concept phase at which time the project vision and mission should be developed (Kerzner, 2003; Kimmons, 1990). It is essential that this step be executed as early as possible in order to appropriate adequate program funds, and to defend and sustain the project. If this is not done early, then the project and its funding are absolutely defenseless and vul- nerable to the whims of any budgeter who may wish to cut funds from a project. Also, unless the requirements analysis is performed early and accurately, it is impossible to proper- ly appropriate program funds. In the case of the LAMP-H project, a project mission was clearly conveyed by the project manager and the requirements analysis was not initiated until about 10 years after the need for the craft was first identified, or about 9.5 years later than it should have been. At the time that the requirements analysis was performed on the LAMP-H, the program was already in serious trouble and probably would have been terminated that very year had the requirements analysis not been undertaken. Thus, the first practical lesson is that, regardless of the type of organization, a project vision, mission, and requirements analysis should be devel- oped and articulated to increase the likelihood of a success- ful project outcome. Lesson #2—Project Sponsorship It is vitally important to the success of a project to have a project champion or sponsor (Helm & Remington, 2005; Kerzner, 2003). Although such sponsors are vitally impor- tant in normal civil and industrial projects, they are absolutely essential in military projects. In order for projects to succeed in either the civil or military sector, they must be supported by a consensus. Because military projects are influenced by so many stakeholders, including special inter- est groups, and have involvement from several different commands (see Figure 2), a great deal of effort must be devoted to consensus building. Further, the project sponsor must have the management span, appropriate knowledge, and organizational authority to harmonize the discordant voices. This is where the project sponsor in any type of orga- nizational project can really make the difference between a repeatedly told that the ROC would have to be approved before funds could be spent on the LAMP-H program. Program IPR Approval and Subsequent Development The IPR period proved to be a very interesting time for the project manager. Preparations were being made for the IPR that would authorize release of the request for proposal (RFP). The RFP invites submission of proposals as to how a contractor would, if selected, construct a vehicle to satisfy the LAMP-H requirements. These preparations included completion of four principal program management docu- ments: the ROC, previously mentioned; the test and evalua- tion master plan (TEMP); the integrated logistics support plan (ILSP); and the acquisition strategy. Although the TEMP and the ILSP could be taken to the IPR in draft for- mat, it was necessary that the ROC and the acquisition strat- egy be approved. In anticipation of the intense level of activity that would be required to complete the program management documents and other work in time for the IPR, a matrix team was formed and a small contract was execut- ed for preparation of the acquisition strategy, the ILSP, and some of the program management documents. The TEMP was to be prepared by the Watercraft R&D Center for coor- dination with the test and evaluation command (TECOM). Program Demise The RFP for the LAMP-H system was to supposed to be released just after the IPR, which granted approval to proceed with the development phase. This deadline was not met. Shortly thereafter, both the project manager and the deputy project manager moved on to other positions. At the time of their departure, the RFP had still not been released. They were replaced by a novice project management team, which accommodated various stakeholders’ requests, whether or not their requests were supported by the requirements. Finally, all of the special interests and expanded require- ments had been accommodated within the RFP, and it was released almost 12 months late. Bids from contractors ranged from U.S. $175 million to $225 million for the R&D portion of the project, which had only been budgeted and approved for $50 million. Also, the unit cost of the LAMP-H as bid by the contractors ranged from $30 million to $43 million, whereas only $15 million per unit had been budgeted and approved. The new project manager requested more R&D funds and to extend the program for an additional year. This resulted in the withdrawal of the production funds and can- cellation of the LAMP-H project shortly thereafter. So, after 15 years and the expenditure of many thousands of hours and dollars, a system badly needed by the military was ter- minated at a waste of $5 million to U.S. taxpayers. Project Management Lessons Learned from the DOD LAMP-H Project Lesson #1—Project Vision, Mission, and Objectives Christenson and Walker (2004), as well as Shimizu and Hitt (2004), purport that the development and articulation of a project vision are key to successful project outcomes. They D E C E M B E R 2 0 0 6 P R O J E C T M A N A G E M E N T J O U R N A L 31 successful and an unsuccessful project. In this case, it was to this end that the PEO structure was established in the Department of Army. The PEO, a senior government execu- tive, was intended to lend the power and influence of his or her office to forge the consensus necessary among various stakeholders to successfully complete a project or program. He or she can do this effectively only if he or she under- stands the acquisition process and is not apprehensive about providing project sponsorship. Unfortunately, this was not the case with the PEO for Troop Support, who came from an entirely different background and never understood the acquisition process. This caused the PEO to be appre- hensive about forcefully sponsoring the LAMP-H project, while ignoring the recommendations of the project manager regarding the LAMP-H project. The PEO’s inability to forge a stakeholder coalition on the LAMP-H project’s account led to internal conflict and disharmony among many of the LAMP- H project stakeholders. In summary, an effective project sponsor who believes that the project is both viable and nec- essary is essential to the success of any organizational project. This sponsor must also be willing to use the authority vested in him or her to build a coalition of support among the var- ious project stakeholders (Hosking, 2005). Adequate project sponsorship is important in relatively simple projects, so it is even more of a necessity in complex projects, such as defense acquisition projects (Hosking). Lesson #3—Project Planning A third lesson learned was in the area of total project plan- ning. It has been stated that “… good upfront planning may reduce the number of changes required” (Kerzner, 2003). A corollary to this is that effective project execution requires that the number of subsequent changes be minimized if effective project planning is done on the frond end. It is impossible to perform effective project planning unless the project vision, mission, and all of the project requirements are taken into account at the beginning of the project (Christenson & Walker, 2004; Kerzner, 2003). In this case, no project mission was clearly articulated at the project’s onset, and the project requirements were changed after much of the basic project planning was performed. Such changes in project scope result in an inability to effectively estimate and control project deliverables and costs (Kimmons, 1990). The T-School inflated its requirements after project planning was completed because it enthusiasti- cally supported this project. However, the inclusion of inflated requirements invalidated all of the previous plan- ning. When more funds had to be requested in order to comply with the inflated requirements, the LAMP-H project manager lost credibility with the Department of Army, resulting in program cancellation. The problem of inflated requirements may be viewed from a mathematical perspective. Consider a symmetric hyper- bola of the form x*y = c, and consider only positive values. The plot of this equation, then, is in the first quadrant. As x becomes very small, y becomes very large, and the curve becomes asymptotic to the y axis. On the other hand, as y becomes very small, x becomes very large and the curve becomes asymptotic to the x axis. Now, consider a similar function that describes the relationships among program risk, program cost, program schedule, and system performance. Such a function would be written as r = f(c,s,p), where r equals risk, c equals cost, s equals schedule, and p equals performance. This equation, because it is four dimensional, would yield, what mathematicians call, a hyper-surface where risk could be thought of as surfaces of constant value, analogous to the constant in the first equation. These surfaces, then, would be comprised of points such that f(c,s,p) = r = constant. Any attempt to change one of the variables, say per- formance, without a corresponding change in the other vari- ables would move the resulting point to another risk surface. More specifically, if one attempted to increase the perform- ance without corresponding increases in cost and schedule one would move to a new surface corresponding to an increased level of risk. This is precisely what occurred with LAMP-H. The performance characteristics of LAMP-H were arbitrarily increased by the T-School while attempting to hold the cost and schedule constant. The result was an increased project scope, and a dramatically increased risk. Such changes in project scope as those attempted by the T- School amount to what Kerzner (2003) described as “unmanaged changes.” He wrote … Another critical interdependency is the relationship between change management and risk management. … Risks and changes go hand in hand, which is one of the reasons compa- nies usually integrate risk management and change manage- ment into a singular methodology. … If changes are unmanaged, then more time and money are needed to perform risk management, which often takes on the … www.kmworld.com January/February 2018 KMWorld 25 Corporate project teams thrive when they learn from one another’s experiences. If one team does something that works—or that fails spectacularly—others should hear about it and profit from that knowledge. In fact, the capture and transfer of lessons learned can be a differentiator between success and failure in a competitive project-based environment. That proves true across a range of functions and industries, from scientific research and development to large-scale manufacturing and consult- ing services. In 2017, member- based nonprofit APQC (apqc.org) studied six organizations to learn how they manage the knowledge that comes out of large, complex projects. The first two arti- cles in this series discussed reasons to embed knowledge transfer in your project management strategy and the role of virtual communities in facilitat- ing cross-project collabora- tion and learning. This final article focuses on the role of lessons learned in project KM as well as the value organizations can derive from getting relevant lessons into the hands of others who may benefit. Reflection and analysis helps project teams learn from successes and failures A majority of the organizations APQC studied in its research ask project teams to identify lessons learned at key decision points throughout their projects. Those collaborative sessions allow project participants to discuss: ◆ what went well (especially any new tools or methods that produced positive results), ◆ what went wrong (especially issues that the team could have mitigated or avoided), and ◆ what changes the organization should make or what the team might do differently in the future. The meetings give proj- ect teams an opportunity to address internal dif- ferences of opinion about decisions and outcomes while build- ing consensus on the best approaches mov- ing forward. Lessons learned conversations also help project man- agers examine risks associated with their projects and document how the team is man- aging and minimizing those risks. Among the organiza- tions in APQC’s research, Volvo Group Trucks (volvo group.com) has one of the most thorough approaches to capture project lessons learned (see Figure 1). The fol- lowing describes the lessons-learned process that Volvo project teams undergo at every stage gate of their projects. By Lauren Trees Project teams and KM—Part 3 The benefits of identifying and sharing lessons learned across projects PROJECT TEAMS continues on page 26 26 January/February 2018KMWorld www.kmworld.com 1. In a workshop setting, identify all project pain points and compile a list. 2. Before the workshop can close, identify the root cause of each project issue. 3. Evaluate whether each issue has potential implications for other project teams. 4. For internal project issues, establish a corrective plan within the project team. 5. For external issues, identify possible improvements and log the lessons, root causes, improvements and potential recipients in the lessons learned log for committee review. Volvo has created detailed process documentation, complete with tools and templates, to guide project manag- ers through lessons-learned workshops and help them identify and prioritize relevant issues. In addition, a commit- tee of senior project managers coaches teams as needed to fully refine their KM submissions. The committee also partners with Volvo’s project man- agement office to provide e-learning tools for project teams to leverage on demand. The key step in each lessons-learned workshop is ensuring that the project team identifies a root cause for each issue, explained Amer Catic, Volvo KM specialist and implementation leader. “You cannot just say that the purchasing process for a certain type of gearbox doesn’t work,” he said. “You have to say why it doesn’t work. Other- wise we cannot do anything about it.” At NASA’s Goddard Space Flight C e n t e r ( n a s a . g o v / g o d d a r d ) , l e s - sons-learned workshops focus on specific project events. The KM office facilitates after-action review sessions called “pause and learn” at key decision points or after project incidents (e.g., failures or near misses) that require reflection or risk management. The sessions are designed to allow project teams to transfer lessons informally within a rich context of dis- cussion. During each 90-minute session, 10 to 20 project participants work with a facilitator to examine a recent project event and come to agreement on what worked, what didn’t, what to change for next time and what can be learned from the experience. After each pause-and-learn session, the NASA Goddard KM office drafts a concept map based on the proceed- ings, which the project manager, dep- uty project manager and team members validate and sign off on. Figure 2 shows a basic concept map template. Accord- ing to NASA Goddard’s KM represen- tatives, the concept maps enhance the pause-and-learn process by enabling teams to clarify and visualize the rela- tionships between various observations and resulting recommendations. In addition, the process of validating and finalizing the maps helps clear up any misunderstandings from the session and moves the group toward consensus on key issues. At global IT and communications equipment and services company Fujitsu (fujitsu.com), project teams capture les- sons learned through a collaborative pro- cess driven by the organization’s robust project management community. During dedicated sessions called Jump Start, the project manager gathers with client repre- sentatives and other Fujitsu project man- agers who have delivered similar projects, worked with that same client or are well- versed in the client’s industry. Together, that group of stakeholders discusses project execution and outcomes. Adapted from an approach used by Exx- onMobil (exxonmobil.com), Jump Start sessions are designed to evaluate projects in an informal, nonjudgmental environ- ment and surface new ideas, tools and a wide range of issues. The sessions may occur at the end of smaller projects or at specific milestones within larger projects. Curation allows organizations to pinpoint lessons that require broader action Once project knowledge has been surfaced and documented, the next step is to filter it so that key insights and lessons rise to the top. A great deal of the knowledge that a project team cap- tures will be relevant only to the team Volvo Group Trucks’ Lessons Learned Process Figure 1 Source: APQC PROJECT TEAMS continues from page 25 www.kmworld.com January/February 2018 KMWorld 27 itself—or perhaps to a handful of sister teams performing similar work. How- ever, a subset will need to be circulated to a broader audience or institutional- ized in processes, procedures, tools or other official guidance. The organizations APQC studied use a variety of approaches to separate out knowledge that is broadly applica- ble across the organization, distribute it to the appropriate stakeholders and get those stakeholders to act on it to improve project outcomes. Some emphasize top- down strategies in which leadership com- mittees evaluate knowledge and lessons for distribution and incorporation into official guidance, whereas others have adopted more organic methods that rely on the wisdom of crowds to help pick out key knowledge “nuggets” that other project managers should take note of. Volvo Group Trucks has a struc- tured process to ensure that knowledge generated by project teams is trans- ferred to the right people and used to improve all projects (see Figure 3). As described earlier, Volvo teams con- duct workshops at each project stage gate to uncover challenges and lessons. The teams themselves perform the first step in the knowledge filtering pro- cess: For each issue raised, the group evaluates whether the issue has poten- tial implications for other projects. If the issue is internal to the project, the team is responsible for correcting it, and no one else needs to be informed or involved. However, if the issue has broader impact, then a more extensive follow-up process is triggered. For external issues (i.e., ones that affect other projects or parts of the organization), the Volvo project team is expected to log the issue, root causes, the proposed solution identified during the workshop and the suggested recip- ients (i.e., individuals who would need to implement the solution) in a lessons-learned log. A committee of senior project managers meets every two weeks to review the log, refine and validate the submitted lessons. Once confirmed by the committee, lessons are published to a central repository where other project teams can access them. Once validated, each Volvo lesson is assigned to a designated recipient. That individual, usually a process owner or high-level manager, is responsible for resolving the issue or minimizing the risk identified in the lesson and reporting back to the committee on the solution that was implemented. In addi- tion, as part of its validation process, the committee identifies certain lesson resolutions as organizational best prac- tices, which are tagged accordingly in the repository. NASA’s Goddard Space Flight Cen- ter has similarly defined processes for separating out project knowledge that needs to be addressed at a higher level. Throughout planning and execution, project teams capture all the details of their projects and outcomes in various reporting systems. However, only a small subset of the information in those systems is transferred into the center’s lessons-learned system and database, called Goddard Knowledge Exchange, which includes lessons from internal projects and other center sources. Goddard project teams evaluate numerous data sources—including problems documented in monthly sta- tus reporting, problems identified via risk management processes and pause- and-learn sessions—to identify items with implications for other projects that should be submitted to Goddard Knowledge Exchange. A Knowledge Exchange working group, consisting of the chief knowledge officer and repre- sentatives from each directorate, evalu- ates project lessons for inclusion in the lessons-learned database and decides what knowledge is both applicable and important enough to be shared at that level. Universally applicable lessons can be built into training for project leaders The review and curation activities described above are highly effective for extracting project knowledge that should be shared with other teams and used to update project-related advice and standards. And for many organiza- tions, that is the natural limit of project KM efforts. However, two of the orga- nizations APQC studied take things a step further by isolating a handful of insights and lessons that are applicable not only to a particular process or type of project, but also to project manage- ment scenarios across the enterprise. What type of knowledge is so uni- versally germane and worthy of shar- ing? For those organizations, the focus is on skills and techniques for leader- ship, critical thinking, decision making, documentation and risk management. Deciding that face-to-face training is the best way to impart those skills, both organizations have analyzed project successes and failures enter- prisewide, selected a handful of situ- ations that exemplify the themes they want to reinforce and built interactive training sessions to familiarize project Template for NASA Concept Map Based on a Pause-and-Learn Session Figure 2 Source: APQC PROJECT TEAMS continues on page 28 28 January/February 2018KMWorld www.kmworld.com managers with those cases and the underlying lessons. The best example of this comes from global defense, aerospace and security company BAE Systems (baesystems. com), which uses a case-based learning program to disseminate high-level les- sons learned applicable across projects and sectors. Rather than focusing on specific technical or project knowledge, the program is designed to impart skills related to making sound decisions in complex, shifting environments. That emphasis was selected based on needs assessments and an analysis of the root causes behind the organization’s project successes and failures. Before instituting case-based learn- ing, most lessons learned were kept within sector-level silos or were “les- sons noted but not actually applied,” said Mike Kessler, BAE Systems’ chief learning officer. “We had a lot of information overload and information management problems around lessons learned. We had to find the richest les- sons and get them into a context where people could actually use them.” To address that problem, BAE Sys- tems’ corporate learning organization developed a series of detailed, MBA- style case studies based on notable past projects. Led by the chief learn- ing officer, the learning group worked with business leaders to select the best cases to develop based on the strategic decisions or dilemmas faced by proj- ect teams. The cases are intentionally designed to cover a range of business sectors, wins and losses, captures and executions, national versus interna- tional projects, product versus service focus and key decision points. During a typical case-based learning session, participants work through one case in the morning and a second, very different case in the afternoon. For exam- ple, if the morning case focuses on a “win,” the afternoon case might describe a “loss.” The instructional approach for each case is unique based on the desired learning outcomes, but every case is pre- sented in three phases. For example, a session might include an initial review of materials to identify the assumptions and risks associated with a potential project, a deeper analysis of whether the project is worth pursuing, final analysis and practice transferring relevant knowledge to a project execution team. Each session ends with a review of key lessons and their applicability to participants’ current projects. “We keep it interesting, fast paced and a little or very stressful,” Kessler said. “You don’t get all of the informa- tion you need; you don’t get all of the time that you need to put everything together. You have to make a lot of quick judgments and think on your feet in rapid timeframes.” The case-based learning approach allows BAE Systems to address common themes across programs and sectors, such as risk assessment, customer inti- macy and competitor intelligence. The training approach also gives participants a broader view of the organization’s pro- grams and decisions. NASA’s Goddard Space Flight Cen- ter uses a strikingly similar process to extract crucial, universally relevant les- sons and embed them in project man- ager training. From the organization’s pause-and-learn sessions and the les- sons-learned database, the KM office develops case studies to share with all project teams. The project management office and the KM office sponsor work- shop forums to share those case studies and real-time lessons from current proj- ects. The format is one full day twice a year with case study presentations and panel discussions. According to Ed Rogers, Goddard’s chief knowledge officer, the workshop forums bring the lessons alive for par- ticipants and help them understand what really went on in each project, how decisions were made and what outcomes resulted. “If this was import- ant enough to cause a setback or cost overrun, then the stakeholders (usually at NASA headquarters) want to know: Did you learn? Did you understand why that happened?” he said. “It’s the same question they would ask about an engi- neering anomaly. Do you understand the root cause so we can be confident you won’t make that mistake again?” PROJECT TEAMS continues on page 29 Action Path for Addressing Lessons at Volvo Group Trucks Figure 3 Source: APQC PROJECT TEAMS continues from page 27 www.kmworld.com January/February 2018 KMWorld 29 to learn about taxonomy and returned this year to describe the advances his organiza- tion had made. ASCO developed a taxon- omy to categorize hundreds of thousands of pieces of content into six major catego- ries for the purpose of improving search and automating curation of content for various websites and services. Another application based on the taxon- omy was designed for attendees at ASCO’s annual meeting. The taxonomy was used to create a session recommender that matched conference attendees’ interests with session content, based on a brief questionnaire and attendee profiles. The recommender pro- vided attendees with personalized recom- mendations from more than 200 sessions offered during the 5-day meeting. Users of the application responded positively and provided feedback that will improve usability in future versions. In Enterprise Search and Discovery, more than a dozen sessions focused on such topics as making search effective and scalable, cloud search and applying cognitive computing to search. Grant Ingersoll, co-founder and CTO of Lucid- works (lucidworks.com), and Marc Ber- man, head of search for Onix (onixnet. com), teamed up to discuss the evolution of bots and AI. One piece of advice from Ingersoll was that if your organization can’t make search work, it will not be able to get to more advanced levels. “The key point is to learn the user’s intent,” Ingersoll advised. “Find out what they care about and scale the answers to meet the user’s needs.” Berman provided a set of guidelines for building the business case for search, including defining the current state and major gaps, and then building a prototype that has a mea- surable impact to help develop support within the organization. The SharePoint Symposium ses- sions addressed ways to collaborate in Office 365, how to create a knowledge management strategy using the Office 365 platform, and how to comply with federally mandated records manage- ment requirements, among many other topics. In the popular Stump the Gurus session, attendees asked about user interfaces, accessibility and important pitfalls to avoid in records manage- ment (the worst one being to do nothing about it). As with the conference program, vendors covered a wide range of per- spectives. Search software vendors were well represented, as were those offering SharePoint-compatible solutions. Oth- ers represented such areas as customer engagement, governance and process automation. Vendors commented on the increasing sophistication of individuals who are investigating their products and services as the technologies used in knowledge management have become more familiar. ❚ Judith Lamont, Ph.D., is a research analyst with Zentek Corp., e-mail [email protected] The workshops allow participants to hash out project decisions and outcomes and learn from their own and others’ experiences. Next steps Although the techniques used to cap- ture and transfer project knowledge vary widely, APQC recommends including a lessons-learned process in your tool- kit of approaches. Document repos- itories and communities can prompt useful exchanges, but some insights only emerge when project teams gather together to analyze their collective experiences. However, be warned: Many organi- zations put lessons-learned repositories in place and then fail to distribute and reuse the knowledge collected there. As you design your approach, make sure that you consider the potential audiences for the documented knowledge and how the orga- nization will take action to ensure it truly “learns” the lessons that are captured. ❚ Lauren Trees is principle research lead at APQC (apqc.org), email [email protected] PROJECT TEAMS continues from page 28 CONFERENCE continues from page 20 1. We’re still drowning in data and starved for knowledge. You know the signs. Tremendous need (billions of people at the bottom of the economic pyramid), exabytes of data and mil- lions of potential solutions. That pres- ents a limitless supply of dots needing to be connected, developed, tested and implemented. In the area of health alone, the data ocean is vast. PubMed (ncbi.nlm.nih.gov/ pubmed) comprises more than 27 million citations and links to the world’s massive corpus of biomedical literature. Better yet, the National Library of Medicine’s Center for Biotechnology Information (ncbi.nlm.nih.gov) provides free access to a treasure trove of research data, analysis tools, programming interfaces (APIs) and open source code libraries, giving any- one (especially small startups) a jumpstart on prototyping and testing innovative, low-cost solutions. 2. Tacit knowledge transfer is still very much alive. As we’ve seen, oppor- tunities for experiential knowledge abound. Take a break from the traditional vacation and participate in the growing “global knowledge café.” Interact with indigenous people who’ve had to mas- ter tacit knowledge transfer to survive. Connect with them at an emotional level. Then return home with an entirely differ- ent perspective and some radically new ideas as well! 3. Think globally, act locally. The common thread in all of this is localiza- tion. People living in grass-roofed huts in remote villages are closer to the problem, its context and possible solutions than the world’s best-equipped laboratories. That’s where KM comes in: combining knowledge generated in the field with the scaling capacity of the developed world. It’s mind-boggling to think of how many solutions are lying undiscovered. Or being applied in one narrow area while overlooking a wide range of additional geographies and applications. How many people are still living without bare neces- sities simply because they don’t know about a low-cost solution that might have been implemented only a few hundred kilometers away? The demand for knowledge of how to make increasingly scarce natural resources available to a world approach- ing 8 billion minds is growing. The good news is, as more minds rise out of mal- nutrition and poverty, more innovative breakthroughs will begin to flow, creating a virtuous cycle. ❚ Ar t Murray ([email protected]), D.Sc., is CEO of Applied Knowledge Sciences and co-founder of the Enterprise of the Future (enterpriseofthefuture.org) initiative. FUTURE continues from page 13 Copyright of KM World is the property of Information Today Inc. and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holders express written permission. However, users may print, download, or email articles for individual use.