In a Word Projects ought to be vehicles for both practical benefits and organizational learning. However, if an organization is designed for the long term, a project exists only for its duration. Project-based organizations face an awkward dilemma: the project-centric nature of their work makes knowledge management, hence learning, difficult.
Define: Project
In its everyday manifestations, a project1 is an individual or collaborative endeavor contemplated, formulated, or carried out to achieve something that has not been done before. In the world of organizations, however, a project is often a major, time-bound enterprise requiring concerted inputs, activities, and outputs—that can involve considerable personnel or a single person, data and information, research, services, equipment, goods, materials, and of course finance—toward a unique product, service, or lasting outcome or result. (Indeed, projects are the normal mode of organization for entire industries such as aerospace, architectural practices, construction, design, publishing, research and development, shipbuilding, and software: they live or die by contracts for consulting, goods, works, and related services.)2 Where a logic model is used to strengthen design and facilitate monitoring and evaluation—for example, in development agencies3—a project is framed by deliverables in a results chain specifying performance targets and indicators, data sources and reporting mechanisms, as well as assumptions and risks.
Anzeige
My personal philosophy is not to undertake a project unless it is manifestly important and nearly impossible.—Edwin Land
I am opposed to the laying down of rules or conditions to be observed in the construction of bridges lest the progress of improvement tomorrow might be embarrassed or shackled by recording or registering as law the prejudices or errors of today.—Isambard Kingdom Brunel
Large-scale projects from times past have been synonymous with the marshalling and division of labor by master builders and early engineers for the construction of burial mounds and temples then, as populations grew, fortifications, amphitheaters, roads, bridges, aqueducts and other hydraulic applications, cathedrals, harbors, railways, dams, etc. At the beginning of the twentieth century, Henry Gantt,4 a proponent of Frederick Winslow Taylor’s theories of workflow efficiency, and Henri Fayol, a pioneer of modern management, synthesized planning and control techniques. Today, engineering continues to make good use of projects but applications cut across pretty much all spheres of human activity, such as business and science.5
Projects drive change, and their good organization and coordination are the best way to concretize that. Project management—a discipline that emerged as a profession in the mid-twentieth century and sometimes seems to define working lives—is the application of knowledge, skills, and techniques to realize projects and their intended benefits efficiently and effectively over the period specified within scope, resources, and other limitations. Conventionally, its processes fall into five broad process groups: (i) initiating, (ii) planning, (iii) executing, (iv) monitoring and controlling, and (v) closing.6 What is more, six parameters are always given weight in its methodologies: (i) time, (ii) cost, (iii) human resources, (iv) scope, (v) quality, and (vi) actions.7 Project management is here to stay8: in fact, a growing number of organizations practice project portfolio management to analyze and collectively administer pools of (ongoing or proposed) projects and their interfaces based on such parameters, aiming to reduce uncertainty while honoring singular constraints imposed by external real-world factors.
To be true to form (and its etymological roots), a project must be a one-off, unique set of activities meant to accomplish a desired outcome by a cut-off date. Crucially, therefore, the temporary nature of a project stands in sharp contrast with the business as usual, aka operations,9 it both engenders and relies on. (Temporary means that every project has a definite beginning and a definite end, even though the duration need not be short.) And so, the management of projects and the administration of business as usual should be quite different and as such require discrete competencies in strategy development, management techniques, and collaboration mechanisms, not forgetting—the subject of these Knowledge Solutions—knowledge capture and storage and knowledge sharing and learning.
Anzeige
Successful Project Management: “Plan, execute, evaluate” sounds simple, but most projects aren’t well planned nor are they evaluated well. The tendency is to jump right into execution and as soon as execution is completed (which usually isn’t soon), move on to the next project without evaluating what happened on the present project and what could have been improved. Successful project management requires more front and back end resources (and less middle) than are usually allocated.—Anonymous
What is actual is actual only for one time. And only for one place.—T.S. Eliot
The Knowledge Quandary of Project Settings
In any project-based organization, sound knowledge husbandry is central to the delivery of current and future project performance. Knowledge is a strategic asset and a critical source of competitive advantage. In addition, apart from their innate worth, projects have for long also been a favored, flexible instrument for design thinking and systematizing complex processes of creativity and innovation. For these reasons, it might at first glance be a surprise that only for about 10 years has attention been specifically directed at what strengths, weaknesses, opportunities, or threats may relate to knowledge management in project environments10—compared to the more substantive work on organizational learning.11
If you want things to stay as they are, things will have to change.—Giuseppe di Lampedusa
But let us look again: as it happens, knowledge management where learning is project-based confronts tough challenges; the causes are multiple and a short list of the chief extenuating circumstances will suffice. To note first and last, projects are transient: novel (but temporal) associations must be forged then fortified. Yet, pressing matters compete for what time, discipline, and skills ought to be made available for that; all the while, the certainty that team members will go their separate ways to take up other work when the project closes militates against earnest intentions to engage in deep knowledge sharing, never mind debriefings.12 (Because knowledge is embodied in individuals, processes, and practices, short-lived organizational forms will necessarily operate in distinct circumstances and associated relationships in their respective external environments, thereby conditioning how knowledge might be harvested and shared.)
I love deadlines. I like the whooshing sound they make as they fly by.—Douglas Adams
Next, no two projects are similar, even when they are framed by comparable historical and organizational environments13: in the same industry or market, they will differ markedly from one another. So, the discontinuities in flows of personnel, data and information, research, and other inputs that illustrate such variety make it hard to develop steady-state routines, maximize stocks and flows of knowledge, and seed learning across projects. (It may be tricky in the best of instances if, as purists surmise, information is inseparable from the people who create it, react to it, or pass it along.) Additionally, in certain if not most settings, such discontinuities are exacerbated by the fragmentation of project teams in isolated professions: since meaning must be shared if knowledge is to be understood, accepted, and exploited, codification and transfer of knowledge within a pluridisciplinary team—where no one member has ready (if any) access to peers—is complicated.
Moreover, reckoning that the project they are working on is the only one of its kind, as it might well be depending on perspective, project teams are prone to assume that the knowledge they hold is also unique, or at least does not warrant being made explicit and validated for the benefit of a distant hierarchy14: this leads to “reinvention of the wheel” and the replication of mistakes. What is more, by their very nature, most projects are designed and implemented in a “hothouse” of planning and control: given the odds stacked against whatever is attempted without previous certainty of success, managers and their supervisors strive to deliver projects on budget and on schedule, with corresponding lack of emphasis on knowledge capture and storage and knowledge sharing and learning, let alone reflective practice or learning in teams. [Witness the millstones (sic) of associated business processes even though projects, as temporary organizations, clamor for empowerment and support, not the command and control that permanent organizations thrive on.]
It is better to laugh about your problems than to cry about them. It’s not that I’m so smart, it’s just that I stay with problems longer.—Albert Einstein
Last but not least, projects are rich in politics15: agitators impact learning within and across them subject to individual authority levels, project sponsor actions, organizational environment influences, organizational arrangements between projects, inter-project assimilation practices, and connections with other projects. Despite their huge variety, project management tools that, notwithstanding their intrinsic usefulness, single-mindedly concentrate on initiating, planning, executing, monitoring and controlling, and closing make no impression when knowledge, not just data and information, must be managed. (At any rate, the attention they bring to bear on efficiency and effectiveness makes the act of capturing and transmitting knowledge a lesser priority during project design and implementation. This state of affairs is compounded by the fact that the potential knowledge requirements of prospective projects do not lie within the purview of the current project’s concerns.) As things too often stand, the end of a project is consequently the end of collective learning and project amnesia sets in: domain, process, institutional, and cultural knowledge fades. Partnerships, communication channels, contacts, and other intangible relational and structural assets evaporate too as intellectual capital dwindles.
Knowledge Management in Project Environments—The Poor State of the Art
Surely, project-based organizations ought to reap hefty benefits—over and above the monetary value of the intrinsically creative and innovative nature of their work. Since projects involve the development of products and services, the prospects for fresh ideas to emerge that might be fructified elsewhere and for cross-functional learning to occur ought to be good. From good practices and lessons, one might also expect such organizations to develop or better utilize core capabilities, build sturdier technological platforms, and reduce project development times, among others.16
Ideas are like rabbits. You get a couple and learn how to handle them, and pretty soon you have a dozen.—John Steinbeck
To date, beyond commonplace statements about the necessity to establish efficient knowledge systems to disseminate knowledge and experience across projects, what approaches have been taken to build organizational capacity with project-based learning have followed “cognitive” and “community” (or “personalization”) models of knowledge management. The first, and by far the most common, has relied on codification17 through process-18 and documentation-based19 methods for extraction, storage, and reuse of knowledge, more often than not relying on electronic repositories. The common feature and limiting factor of such methods is that contributions come about at the tail end of a project, not during it (when the seams of learning are probably richest).20 If each project is distinctive, what good practices and lessons have been gleaned can only be nonspecific, meaning that they are of the know-how, not know-why variety. That is fine, since strengths and weaknesses can be generic, but it can only inform so much learning before doing.21 The second approach, courtesy of the present, welcome vogue for communities of practice and other such social networks, has shone a powerful light on the tacit dimension of knowledge and encouraged dialogue between individuals, not between knowledge objects in a database. However, the embeddedness of tacit knowledge within social groups, promoted by storytelling and joint work, means that shared mental models or systems of meaning, buttressed by trust and norms, must exist to enable others outside these to understand and accept that knowledge. Both approaches, which call for different sets of incentives, are complementary and necessary but neither has sufficiently lent a hand. In project settings, what good practices and lessons have been extracted and stored in databases are not widely used because they are poorly represented22 and archived. Conversely, where team members made time to help others cope with similar problems, crystallized their insights, and made them easy to find they are not accepted by reason of the “Not Invented Here,” “Proudly Found Elsewhere,” or “Invented Here, But Let’s Reinvent It Anyway” syndromes. What is more, pace the interorganizational contractual obligations that characterize many projects, the temporal, disciplinary, cultural, and spatial differentiation of project teams ineluctably frustrates the efforts of members to understand and apply the insights of other social groups to their own context of practice and gives them no breathing space in which to build their own networks of actors because they are so task focused.23
Nothing is too small. I counsel you, put down in record even your doubts and surmises. Hereafter it may be of interest to you to see how true you guess. We learn from failure, not from success!—Bram Stoker
I’m lazy. But it’s the lazy people who invented the wheel and the bicycle because they didn’t like walking or carrying things.—Lech Walesa
Is there a strong, inherent contradiction between organizing in the short term for a long-lasting outcome or result and doing so for long-term, organizational performance improvement? How might a project-based organization be simultaneously oriented to both practical benefits and organizational learning?
Managing Knowledge in Project Settings
Projects need to be reconceptualized as knowledge carriers, not end products, bridging to both contemporaneous and yet-to-come projects. How might this be achieved? To learning organizations, these Knowledge Solutions recommend three realistic and mutually reinforcing options relating to (i) project typologies, (ii) organizational design, and (iii) strategic planning and operations. Others surely exist and project-based organizations could do worse than research what they might be.
First, if project environments are to be opened up for learning, it is essential to recognize that projects are not all one and the same. Realizing this will help project-based organizations maximize opportunities for knowledge management both within and across projects by applying techniques appropriate to the nature of the projects in question. Conveniently, Turner and Cochrane (1993) have shown that projects fall into four discrete types, which means project managers should use appropriate start-up and implementation methodologies.24 The following summarizes the spectrum of their goals-and-methods matrix, highlighting the project management approach best suited to the conditions the four types exhibit. Leveraging the knowledge management architecture the author elucidated in Learning in Development (2010), it quickly weaves in preferential, exemplar knowledge management approaches25:
-
Well-Defined Goal and Methods Initiatives with well-defined goals and methods are typified by engineering and construction projects. Drawing from rich historical experience and known techniques, team members move swiftly into specialized activity-based planning of what must be done in the milieu of a stable project configuration. In this type of project environment, operative aids to knowledge management include regular, effective meetings and presentations during which team leaders—acting as conductors—lead skilled implementers in well-defined activities set against milestones, communicate experiences and learning, and hold problem-sharing sessions or project clinics. Briefings can also be organized to support knowledge sharing in a structured project environment permitting sequenced communication, connection, collaboration, and capitalization. (Project management approach: task and activity scheduling. Knowledge management approach: leadership, technology.)
-
Well-Defined Goal, Poorly Defined Methods Initiatives with well-defined goals but poorly defined methods comprise product development projects. In these instances, while the functionality of the required product is known, how that is to be achieved is not sufficiently clear. In this type of project environment, advisable aids to knowledge management include collaboration mechanisms to identify peers who may have encountered and dealt with similar problems in the past; an accent would be placed on the definition of techniques. Ways to brainstorm and stimulate creativity and innovation would also be sought. Technology would play an important role in connecting peers and team members, for example, with wikis, to advance joint work. (Project management approach: milestones for components of product. Knowledge management approach: leadership, learning, technology.)
-
Poorly Defined Goal, Well-Defined Methods Initiatives with poorly defined goals and well-defined methods include systems development projects. In such cases, in the search for sharper definition of the goal, milestones representing completion of life cycle stages come to the fore but should not blind team members to the complicated and complex and to the need for emergent strategies, with willingness to embrace failure on the way. In this type of project environment, useful aids to knowledge management center on people issues and the sponsoring of informed dialogue. Coaching and mentoring, knowledge facilitators, and internet forums would all score highly as team members agree on the goal in close working relationships. (Project management approach: milestones for life cycle stages. Knowledge management approach: learning, organization, technology.)
-
Poorly Defined Goal and Methods Initiatives with poorly defined goals and methods encompass research and organizational change projects. Here, a chaotic context owes to unclear directional sources. From the onset, team members must define the mission, engage in scenario planning, navigate and practice the strategy, refine the objective, and assiduously cater to team-building and engagement. There is no stable project configuration: inspiration, negotiation, and communication are paramount in a conflict-prone state of affairs. In this type of project environment, valuable aids to knowledge management include (i) harnessing top talent, (ii) being flexible about the procurement of new skill types, (iii) stimulating creative thinking, (iv) identifying peers in and outside the organization, (v) tapping internal knowledge markets, and (vi) managing change. (Project management approach: mission definition, refinement of objective, team building. Knowledge management approach: leadership, learning, organization, technology.)
Method is much, technique is much, but inspiration is even more.—Benjamin Cardozo
Often people attempt to live their lives backwards: they try to have more things, or more money, in order to do more of what they want so that they will be happier. The way it actually works is the reverse. You must first be who you really are, then, do what you need to do, in order to have what you want.—Margaret Young
The true method of knowledge is experiment.—William Blake
Second, and for traditional, project-based organizations, the bad news: the command-and-control hierarchies that configure them may speed the preparation of relatively simple deliverables within pressured deadlines but run counter to the exploitation and exploration of knowledge for learning and organizational performance. Hierarchies cannot straightforwardly, to maximize their organization’s knowledge-related effectiveness, conduct any of the following: (i) monitor and facilitate knowledge-related activities; (ii) establish and update knowledge infrastructure; (iii) create, renew, build, and organize knowledge assets; or (iv) distribute and apply knowledge assets effectively. This should matter a lot to project-based organizations. Auspiciously, the resolution is close at hand and they need not despair: if their strength lies in projects, surely, might an organizational configuration parallel to, but integrated with, that of offices and departments not be advantageous?
The rise of communities of practice bodes well but is per se insufficient: the learning infrastructure of knowledge-intensive organizations, that project teams would tap and enrich in chorus, must be enlarged. To help manage knowledge in project settings, Verteramo and Carolis (2009) have made a vital distinction between customary (sector and thematic) communities of practice26 and (technical) practice groups—the former being in the main dedicated to learning, with contributions from a swath of disciplines; the latter translating as a project-based organizational structure for experts engaged in subject-specific domains transversal to projects, such as project management, business development, etc. Practice groups, the origin of which lies especially in the legal profession, would represent bodies in which discrete and objective facts as well as practical information can be found; learning loci in which professional competencies can be improved; and social networks in which both exploitation and exploration of knowledge take place. More structured, stable, and formalized than communities of practice, practice groups can be an effective organizational solution for managing knowledge in project-based organizations. Projects nourish practices and are nourished in turn: through projects, personnel acquire or develop competencies and improve practices of interest; through practices, ideas, and innovations that generate other projects are sparked and recognized.
Most Japanese companies don´t even have a reasonable organization chart. Nobody knows how Honda is organized, except that it uses lots of project teams and is quite flexible.—Kenichi Ohmae
Third, to activate the transformation of projects as knowledge carriers to the future, the priority of knowledge management should be reflected in strategy and its operationalization, with inputs at all stages from communities of practice, practice groups, and, of course, offices and departments. In brief, strategic plans should systematically identify the particular instruments needed to enhance the organization’s knowledge management capacities at the requisite level, be it the global, regional, national, provincial, commune, or local level, or else the industry, sector, or market level. In terms of operating outputs, the project cycle would need to be retooled to integrate knowledge management throughout project design, implementation, and evaluation, evidently in light of the four discrete types discussed earlier. In both instances—strategic and operational, protocols for identification, creation, storage, sharing, and—yes—actual use of knowledge should be set.
The opinions expressed in this chapter are those of the author(s) and do not necessarily reflect the views of the Asian Development Bank, its Board of Directors, or the countries they represent.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution-NonCommercial 3.0 IGO license (http://creativecommons.org/licenses/by-nc/3.0/igo/) which permits any noncommercial use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the Asian Development Bank, provide a link to the Creative Commons license and indicate if changes were made.
Any dispute related to the use of the works of the Asian Development Bank that cannot be settled amicably shall be submitted to arbitration pursuant to the UNCITRAL rules. The use of the Asian Development Bank’s name for any purpose other than for attribution, and the use of the Asian Development Bank’s logo, shall be subject to a separate written license agreement between the Asian Development Bank and the user and is not authorized as part of this CC-IGO license. Note that the link provided above includes additional terms and conditions of the license.
The images or other third party material in this chapter are included in the chapter’s Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.