managing project problem‐solving patterns

Managing project problem-solvingpatternsSteven Cavaleri

Central Connecticut State University, New Britain,Connecticut, USA

Joseph FirestoneExecutive Information Systems, Inc., Alexandria,

Virginia, USA, and

Fred ReedThrivesigns Consulting, Honey Brook, Pennsylvania, USA

Abstract

Purpose – The purpose of this paper is to present a process for managing projectproblem-solving patterns. It focuses on shifting the emphasis of project teams toward a morecollaborative and knowledge-based style of dealing with challenges to project performance.The methods proposed in this paper encourage project managers to integrate processes for becomingmore agile by tapping into lesson learned and knowledge gained to create higher quality solutionsto problems.

Design/methodology/approach – This paper proposes a conceptual framework for recognizingproblem-solving patterns and transforming problem solving from an individual passive event to amore open, agile active, systemic process. Several actual case examples are provided to illustrateapplications.

Findings – The paper examines how taking a more open approach to problem solving in projectsleads to better solutions. The proposed method and lessons from actual cases offer support to theseproposals.

Research limitations/implications – The proposed models in this paper originate from theconclusions and observations drawn by the authors over many years of experience. However, they arenot the product of a systematic research effort. This paper is intended to provide a new lens for projectmanagers to view projects. It does not purport to declare findings of any research or analyze any sortof research.

Practical implications – The conceptual framework provided in this paper is a practical onederived from the practices used in leading companies. The paper provides practical guidelines to aidproject managers in recognizing and managing problem-solving patterns to create better solutions toproblems.

Social implications – Modern society is plagued by the effects of ineffective problem-solvinginitiatives in business, government, and not-for-profit organizations. Flawed proposed solutionsexact a toll on organizations, their members, and the constituents they serve. This paper proposesa way of improving the quality of problem-solving processes that may benefit a broad scale ofpeople.

Originality/value – The concept of a problem-solving pattern and a typology of problem-solvingpatterns presented in this paper, provide project managers with a new way of conceiving of howproblem solving can be used to improve project performance and adaptability.

Keywords Project management, Problem solving, Agile project management, Knowledge management,Problem solving pattern, Soft systems thinking

Paper type Research paper

The current issue and full text archive of this journal is available at

www.emeraldinsight.com/1753-8378.htm

Project problem-solving patterns

125

International Journal of ManagingProjects in Business

Vol. 5 No. 1, 2012pp. 125-145

q Emerald Group Publishing Limited1753-8378

DOI 10.1108/17538371211192937

IntroductionToday, project managers encounter ever more complex dynamic projects leaving lessroom for error and demanding more highly effective problem-solving methods be used.Sterman (2002, p. 46) notes:

Project management is at once one of the most important and most poorly understood areas ofmanagement. Delays and cost overruns are the rule rather than the exception in construction,defense, power generation, aerospace, product development, software, and other areas.

It is strategically important that companies avoid project delays and cost overruns, yetoften paradoxically, they are slow to adopt new problem-solving strategies. There aremany reasons that effective problem solving has become strategically important tofirms. First, complex environments pose greater risks of destabilizing projects byincreasing the probability of adopting faulty solutions. Second, by treating problemsolving as being an active continuous process, rather than as a reactive series of discreteevents, strategic advantage may be gained. Problem solving can be a more reliablemeans for reducing costs and waste, while improving productivity and speed. Finally,problem solving holds a key to organizational adaptation – especially when teammembers are encouraged to create new solutions based on lessons learned andknowledge gained over time. By contrast, conventional project management wisdomholds that increasing both project planning efforts and team member training willprovide superior results. However, such training strategies often prove to be of limitedvalue because they ignore the causes of lethal non-routine problems, and neglect theadvantages of solutions based on situated learning and local knowledge.

Projects rarely fail due to the effects of routine problems, but crises result fromnon-routine problems. Non-routine problems are typically not amenable to conventionalproblem-solving efforts because there are few well-established rules to insure thateffective action will be taken. If clear and highly effective algorithms for effectivesituation handling existed there would be fewer major technology disasters, like theNASA space shuttle Challenger, the Dow Chemical disaster in Bhopal, India, or the BPDeepwater Horizon oil-rig failure. This paper addresses the need for project teams to notonly improve performance by designing better solutions, but also to increase teammember knowledge and understandings within the process. Precedence for moving inthis direction already exists. For example, Spear (2009, p. 218) found that one of Toyota’smanufacturing suppliers, holds project teams to a higher standard than merely reachingperformance improvement goals. He cites a case at this supplier where a project team fellshort of reaching its performance improvement goal, but this was considered my projectmanagers as being less of a concern to the project than the lack of learning andknowledge gained by team members:

Thus, in falling short, they not only missed their target but missed the chance to push furtherto understand factors that they had assumed to be true but that their experience had provenfalse. The process had gotten better, but their understanding of it had improved as much as itmight have had they made clear their expectations at the start and the assumptionsunderpinning them, thereby having something tangible to investigate when thoseassumptions proved false.

This paper also presents a conceptual framework and method to improve projectproblem-solving effectiveness by leveraging team adaptability, action learning, systemsthinking, and knowledge. Our focus on systems thinking and action learning is similar

IJMPB5,1

126

to that found in “soft” systems thinking and Checkland’s soft systems methodology(Checkland and Scholes, 1990). Both approaches seek to incrementally promote learningprocesses leading to greater clarity of exactly how various system elements interact tocause performance dynamics. However, the approach proposed here goes further toexplicitly incorporate scientific methods of inquiry and knowledge validation processesinto the larger learning milieu that emerges in complex projects. Specifically, twofoundational principles serve as the underpinning of our approach. First, the preceptthat quality of thinking employed in problem-solving pattern (PSP) management willdirectly govern the level of effectiveness of problem-solving processes. The integrity ofthese processes will, in turn, determine the efficacy of those solutions designed and theproject sustainability of those actions taken on behalf of these solutions. Second, solutionquality is directly related to the degree of openness, quality of knowledge, and agility inproject PSPs. Greater openness in these patterns increasing the capacity of teams todetect flawed solutions and preempt their implementation. An agile knowledge-basedstrategy for improving project problem-solving processes is presented here to illustratehow teams can move toward using a more open problem-solving pattern (OPSP). Forexample, in agile software development processes, team leaders often seek to identifyfatal flaws in software products at the earliest possible time to prevent unnecessaryinvestments of resources of a product version that will never be viable. Such adaptiveshifts in project direction, especially on new product development teams, can providesignificant savings. Yet, traditional project management practices often focus on effortsto neutralize project complexity through more precise planning and exerting morepressure on tighter controls. Ultimately, such efforts prove ineffective because as projectcomplexity and dynamics increase it becomes progressively more difficult for projectmanagers to accurately plan for the future or control performance in a destabilizedsystem. Several case examples are presented in this paper to illustrate how firms canadopt such an approach. Finally, a diagnostic tool is presented that identifies PSP types,and a step-by-step process of managing problem solving using a knowledge-basedfoundation is proposed. The starting point to begin this transformation is by examininghow a firm’s PSP influences the quality of the solutions developed in projects.

Problems and problem-solving processesTo some scholars, the very notion that problems can even exist is controversial. Forexample, Flood (1995, p. 71) notes:

The common understanding of “problem” is that it is an identifiable bad thing and that allforms of organization experience them and must solve them so they can maintain or return to,normal organizational life [. . .] there is no such thing as a problem or a solution, nor is theresuch a condition as normal organizational life.

Similarly, Ackoff (1999, p. 13) observes, “one of the most damaging misconceptionsplaguing most people, including managers, is that problems are objects of directexperience. Not so, they are abstractions extracted from experience by analysis.” Theterm problem is often defined broadly as a perceived disturbance in expectations aboutthe current state of affairs (Popper, 1999, p. 4). In other cases, managers define problemsin radically different ways from each other. Thompson and Cavaleri (2010) report onresearch, based on interviews with executives in the petro-chemical industry, that theabsence of a common language for inquiry and a similar process for experimentation,


127

hindered knowledge processing efforts among managers causing them to becomeoverloaded by an overreliance on using unbounded problem statements. That is,managers tended to describe problems without delimiting the array of realistic potentialcauses. Such behavior patterns diminish their ability to effectively employ specificknowledge to solve problems. Further, Repenning and Sterman (2001, 2002, p. 285)propose that project managers tend to make false diagnoses of problems and thenincorrectly attribute the cause of the problem:

Managers’ tendency to attribute performance shortfalls to problems with the workforcerather than the production system is reinforced by the so-called fundamental attributionerror, or dispositional bias. Attributing a problem or behavior to individuals rather than thesystems in which they are embedded is a pervasive and robust phenomenon.

Defining problems and causes inaccurately not only originates in individual perceptionsand shared team assumptions, but also in a broader project environment whereprevailing assumptions spurious knowledge claims about problems and causes tend togo unchallenged. There are several analytical methods capable of routinely challenginginvalid problem assumptions including, system dynamics (Lyneis and Ford, 2007),knowledge management (Wiig, 2004), and agile project management (Appelo, 2011). Forexample, so-called agile project management methods require a shift in employee beliefsaway from assumptions about the causes of change implicit in traditionalplanning-focused management methods (Appelo, 2011). Agile project managementextends iterative development processes into more volatile environments byencouraging practices, such as continuously improving the ability of team membersto recognize emerging opportunities to increasing value and reduce waste caused bychange (Augustine et al., 2005, pp. 85-9). Adopting such unconventional assumptionsprovides a new context to redefine the meaning of problems, and therefore, what itmeans to engage in problem solving. The fluid meaning of the way problems are definedby team members can be more clearly seen by examining the differences among thevarious assumptions about problem solving they are likely to adopt.

Contrasting views of problem solvingTo many traditional project managers the foundation of project management is found inthe project plan. This is an abstract description of what is to be executed, when, how, andto what effect (Koskela and Howell, 2002; Johnston and Brennan, 1996). This constructserves as a template for project managers to employ a systematic, logical, andmathematical method to plan and control project activities. The prime goal is usually toachieve maximum value within resource constraints. In this perspective on projects,abstractions become converted into concrete project elements. For example, flesh andblood people become operationally described as being “human resources”, while workinteractions become workflows and so on. Next, a conceptual foundation is laid uponthese abstractions where standard project management activities, such as planning,optimization, and control methods are used to ensure that all resources become fullyleveraged and used cost effectively. These abstractions rest on the assumption that anyrelevant future state that may arise is predictable and familiar. Given the acceptance ofthis paradigm, project managers often see their prime job as being to predict andprepare. As such – these abstractions articulated by project managers in their calculusleading to policies and actions emerge solely from what is known, by them, of pastexperience. For example, a particular “skill” that serves as a key component of a team

IJMPB5,1

128

member’s skill set is one of several elements used to abstract how individuals becomecast as being regarded as human resources. This is an abstraction of actual behaviorsand accomplishments found useful in the past. As long as a defined skill remainseffective in assigning individuals to projects, it supports effective control and planningof the project. However, when abstractions and assumptions become breached by theforce of unexpected situational changes – problems arise. For example:

. a person quantified by their skill set proves to be ineffective in a real and uniquework situation;

. a machine breaks down under heavier than usual load; and

. a specification changes as a consequence of unforeseen changes in a productmarket.

In this conception, problems become prevented by mitigating the effect of brokenabstractions caused by unanticipated changes that threaten expected successes. Forexample, one could potentially insulate these abstractions from changes in theenvironmental context – such as putting a machine in a dust and vibration-proof room, orstandardizing worker activities and the workplace to minimize the effect of skillvariability. In spite of such interventions, unanticipated changes can spark problemsthat, depending on their severity and timing, may put an entire project at risk bytriggering disruptions and reallocation of critical resources to “put out the fire”(Repenning et al., 2001). Conventional approaches to project management rely too heavilyon unchallenged assumptions of the future to bear strong resemblance to the past.

Limitations of conventional project management. As the number of variables bearingon the success of a given project management element become less predictable in adynamic world, then, pressures for project teams to reinvent themselves routinelyemerge. While there is relatively little debate that project teams do, in fact, need todiscover ways to reinvent themselves, questions of exactly how project teams shouldreinvent their problem-solving capacities are often more difficult to answer. One viewargues it is unduly risky to assume past experience will serve a successful guide to thefuture. This paradigm virtually ignores the significance of project dynamics, unintendedeffects of faulty policies, unexpected change, and ambiguity in the way problems aredefined. Depending on a project’s mission, this way of defining projects can lead projectmanagers to ignore potentially high-risk situations. For example, many softwaredevelopment projects start off based on comprehensive plans only to have these plansunravel in disarray. This often is the result of unexpected project dynamics. Thesedynamics may result from higher order system complexities, such as interactionsamong project features, the rework cycle, project controls, and ripple and knock-oneffects (Lyneis and Ford, 2007). Conversely, they may also emerge from effects of theaction of subtle forces as simple as those arising from the continuing applicability ofMoore’s law in software development projects. Moore’s law asserts that computingpower has and will continue to grow exponentially. This axiom imposes a great burdenon software projects to accommodate change and adapt to truly new contexts, needs, andopportunities. In response to this pressure, various agile software project managementapproaches such as Extreme Programming (XP) and Scrum were developed. Here,change is not just tolerated in projects, but embraced and even welcomed (Beck, 1999).By welcoming change rather than resisting it, an agile project team is able to providetheir customer/sponsor with something of great value. It is the ability to quickly


129

and inexpensively pivot a project’s direction in favor of pursuing new opportunities.There is much that can be learned about making sudden turns in a project’s directionfrom the annals of agile project management experiences. However, we find the morecritical insight to be gained from these experiences are to be found in understanding howlearning and knowledge processes enable agile teams to design higher quality solutions.

The “agile” connection to problem solving. Project managers may experiencechallenges in launching initiatives designed to increase a project team’s problem-solvingeffectiveness. Knowing which steps to take toward this goal can be as confusing as theKing’s directions to Alice in Alice in Wonderland. “Where shall I begin, please yourMajesty?” [...] “Begin at the beginning,” the King said gravely, “and go on till you come tothe end: then stop” (Carroll, 1865). When it comes to improving problem-solvingeffectiveness in project teams, the starting point is becoming more open, agile, andleveraging team knowledge processes. “If agile methods have a motto, it is ‘embracechange’. If agile methods have a strategic point it is ‘maneuverability’” (Larman, 2003).Agile project management rests on the counter-intuitive principle of minimizing effortsput into project planning, thereby eliminating potential waste, when project changesrender the plan obsolete. Less planning suggests that the definition of a “problem” as athreat to planned expectations would change somehow in an agile process. By contrast,traditional project management employs problem solving to minimize the value lostfrom undesired surprise and change. On the other hand, agile projects seek to maximizethe value gained from welcomed surprise and change. In general, agile project methodsare also lean because they are intent on increasing project value delivered, over time, andminimizing waste. However, agile project management is distinguished by its emphasison maximizing earned value by exploiting change – while simultaneously minimizingthe waste associated with change. Thus, decisions in agile projects are made, and actionstaken, at the latest responsible moment to avoid commitments that could be renderedwasteful by future changes. A problem in an agile software development contextcould be:

. making a decision before it was necessary and therefore eliminating a possibleresponse option; and

. overbuilding leading to obsolescence before value is harvested.

In practice, projects are rarely formed by using ideal prototypical versions of eithertype – agile or conventional project management. Problem-solving approaches areoften hybrid variations of both types. Similarly, the problem-solving processesemployed in projects will share some basic components and features of both types.

Routine action and adaptation. Clearly, project task activities are not only a matterof responding to change and solving problems. Yet, project teams need to continuallyseek new ways of resolving the ongoing dynamic tensions between routine andadaptive behavior. This tension often forces managers to make trade-offs of effort andresources to achieve divergent goals. In almost all projects, there are tensions between:

. productivity and stability;

. volume and quality; and

. loyalty to employees and pressuring them to perform.

IJMPB5,1

130

For example, problems can arise when imbalances occur. These trade-offs are illustratedby the challenges facing a software development firm – Binary Software Corporation.

Case – Binary Software CorporationBinary Software Corporation was a start-up contract software engineering companythat won an important contract by making the low bid on new product developmentwork for another emerging business. In order to deliver on that bid, they used tools thatthey were most familiar with and focused their effort on minimizing wasted effort indirectly meeting the critical business needs of their customer. As a short-term strategy,it worked brilliantly – both the software company and their customer grew rapidlyand gained follow-on business from their early success. But, the software developmentcompany had an evolving problem. As their customer’s business grew, it attracted theattention of bigger, more sophisticated customers of their own that demanded morefeatures and accommodations to their unique needs. Because the initial developmenteffort was so focused on efficiently delivering immediate value – one might say in avery effective “lean” environment – they essentially failed to manage the project in an“agile” way, or one that would minimize the cost of the changes these new demandswere placing on the software. Agile software practices such as extensive automatedtesting and constant refactoring (i.e. simplifying the code while maintainingfunctionality) were not routinely done, and consequently substantial technical debtaccumulated through the entire project. This debt, caused by borrowing effort frommaintaining agility to pay for immediate feature delivery, could not be feasibly paidback in the follow-on contract. Under the demand for new and unanticipated features,they could not divert enough effort from delivering immediate value to put towardimproving the agility of their code or development process. At the same time, thegrowing technical debt imposed a direct and persistent cost on the effort required tomake the changes and additions to the system that the new customers weredemanding. Paying that cost of built-in waste with each new feature delivered meantthat even less resources were available to bring down the technical debt. Caught in avicious cycle of working increasingly harder and less smart, they eventually reached apoint where they could not profitably deliver new features. Notice that at essentially alltimes, the software developers were customer focused and producing valuable featuresat the possible lowest cost. The problem arose from not appropriately balancing theeffort to deliver value through routine effort with the effort to remain agile and notexpecting the unexpected from the very beginning.

The solution to this particular problem required a personal rather than technicalsolution. In spite of the deepening business crisis for the software developer’s customerwho was unable to meet their new market needs in a timely way, the relationshipbetween the two organizations was perceived from the beginning as a partnership ratherthan the often typical adversarial contracting relationship. The project’s customerrealized that the technical debt was being accrued while delivering value thatcontributed greatly to their initial success, and that they should share in paying it down.Through a combination of additional funding to specifically reduce the technical debt(i.e. rebuilding substantial components of the existing code), and increasingcollaboration between the two organizations to match features and market needs in away that mitigated the cost imposed by the remaining technical debt, they were able toadapt in a way that kept both businesses viable. What they learned was that, if they had


131

it to do over again, they would better balance immediate and long-term concerns, as wellas measure and monitor technical debt in order to maintain that balance.

Bi-modal project team operationOver time, and by necessity, project managers often must allocate increasingly scarceresources to extricating a project from unfavorable circumstances. They may also facethe challenge of reinvigorating a team when it gradually becomes plagued by bothdeclining rates of adaption and innovation over time. Declining adaptive capacity maynot reveal itself in a failure of routine operations. Rather, it may appear as an inability torespond to crisis or change. The challenge of simultaneously operating systems capableof improving both routine and adaptive performance can be overwhelming toemployees. Unless a project has significant slack resources, operating as a bi-modalintegrated system, this usually fails. We propose that projects can successfully operatebi-modally – by effectively managing PSPs to optimize performance and adaptation.Adaptation depends on an entirely different set of processes than routine behavior,including action learning, knowledge creation, knowledge sharing, innovation,adaptation, exception handling, etc. These tend to be intensely social processes. Theyrequire focused human interactions and attention to learning from experience.Continuous problem solving drives improvement by actively engaging employees inboth performing work and improving the work they are performing. Problem solvinggenerally involves effort which results in two kinds of payback:

(1) mitigating costs of a particular problem; and

(2) reducing the cost of future potential problems.

The first kind of payback is often achieved by “adapting”, which in this context meansapplying existing knowledge to the solution of the problem. The second kind ofpayback requires “learning”, which creates or modifies knowledge that may come intouse in the present and future cases. Notice that over the long haul, project successdynamics may actually become inverted over time. We propose the following projectmanagement axiom based on a tendency toward problem implosion. Here, a problemmay actually be a boon if the immediate cost of adapting and learning is more thanmade up for with gain in value arising from new knowledge. This fundamental notionserves as foundation for experimental, problem seeking, or inquiry modes of behavior.In this mode, opportunities are taken or learning is expanded as much as possible,while still constraining costs. An example of this sort of practice in agile softwareprojects is what is called a spike. Typically, a spike is time-boxed, or constrained to amaximum amount of effort in order to cap the cost of the effort. Within that time-box,however, the primary objective is to learn as much as possible that might reduce thecost of problems later. So, for example, a developer on a spike might compare using anopen source library with building their own code to address a need similar to one thatthe project is facing. By uncovering, adapting to, and learning from the problems thatarise in the spike, the hope is that the eventual value gained as a consequence of what islearned will outweigh the time-boxed cost. Clearly, the key for project teams to achievegreater agility is to become more adaptive to change. Enhanced agility results frommanaging PSPs toward greater openness. Conversely, conventional project teams arefocused on business processing and its direct outcomes.

IJMPB5,1

132

Effectively managing project PSPs enables teams to balance the two criticalfunctions needed to achieve optimal levels of project effectiveness, namely problemprocessing and business processing. Business processes are “the handling andmanagement of transactions between workers, customers, suppliers, and other agents ina value chain or network, aimed at satisfying customer demands for products andservices” (McElroy, 2003, p. 188). Business processing depends on requiring teammembers to follow routine step-by-step methods for achieving clearly known outcomes.In other words, its main task is to perform the work to complete the project in line withspecifications. By contrast, problem processing seeks to leverage new knowledge tosolve problems that do not have clearly routine solutions and improve how the project isdone. Both forms of processing are necessary for project success and should be balancedover the course of the project (Figure 1).

Learning in and through agile project teamsHow adaptation takes place and what things are learned clearly depends on the degree towhich principles of agile management are being applied. For example, the problem of akey person becoming unavailable to a project team through illness, attrition, or whateverreason is a common situation. In a traditionally managed project with an extensiveproject plan, this is clearly a problem. Not only will the project timeline be skewed by theresource reduction, but this person may have a critical rare skill or knowledge that couldblock progress on critical tasks. Risks of delaying and destabilizing the project may alsoarise also as a result. Alternatively, by selecting an adaptive strategy to deal with thisproblem, a project manager has several options, such as finding a replacement memberwith similar skills or outsourcing some of the work to keep progress on target.

Figure 1.The three-tier PSP

managementreference model

Business Outcomes

Business Processing

Solutions

Problem Processing (PP)

PSP Management (PSPM)

• Business Strategies• Organizational Models• Business Processes• Product Strategies• Marketing Strategies• HR Strategies

Problem SolvingPattern Management

EnvironmentPSPM Outcomes

ProblemProcessing

Environment

BusinessProcessing

Environment

The PSPM Reference Model

• Profitability• Market Share• Growth• Ethics• Sustainability

• PSP Strategies• PSP Policies and Rules• PSP Infrastructures• Learning Programs• Innovation Programs


133

What might be learned is that a better plan in the future could mitigate the risk byavoiding staffing that relies on critical skills in a single person. Similarly, in a productdevelopment project, products could be specified and designed to reduce the need forrelatively rare skills in their implementation. Notice that in hardening a project againstunexpected contingencies, some nominal amount of waste is created. In the examplesabove, either some extra redundant capacity of the rare skill has been added, or thepotential value obtainable from this rare skill has been left “on the table” unused.In general, a changing project environment the unexpected dynamics afford differentopportunities for creating value at different times. Precisely executing a project planmeans foregoing other unplanned emergent opportunities as well as expending extraresources to maintain the conditions necessary for the plan’s success across the broadestrange of contingencies. Such project risk management strategies always incur anopportunity cost as the resources used in protecting against potential, not actual,contingencies could have been better used when those potential contingencies do nothappen (de Klerk, 2001).

The unexpected loss of a team member on an agile project team would unfold quitedifferently than in the prior example. How? First, agile work practices encourageflexibility and robustness allowing a team to rapidly adjust to changes. For example, theXP practice of pair programming concurrently serves the apparently opposing needs ofachieving higher quality product development as well as transferring useful knowledgeand skills throughout the team. Pair programming is a type of division of labor insoftware development where “two programmers develop software side by side at onecomputer” Cockburn and Williams (2000, p. 1). Critics might argue such agile workpractices introduce subtle forms of unexpected waste into the system. In simple financialterms pair programming appears to double the cost per line of software codedevelopment. However, the net benefits of pair programming, such as improved codequality, require less debugging and labor downstream. In practice, actual results dependon the nature of the project and the team (Padberg and Mueller, 2003). The ongoingprocess of adjusting pair programming practices within a specific project context inorder to optimize performance by balancing productivity, costs, and agility, is wherelearning and knowledge become critical drivers of decision making. Incrementalrevisions to project policies become increasingly dependent on situated learning whenthe dynamics of project elements deviate from expectations and past policies becomeless relevant to the case at hand facing team members. Situated learning is highlycontext specific and relative to the unique circumstances that evolve, over time, inproject teams and among its members (Lave and Wenger, 1991). Sense (2007) argues it isessential to design project teams in ways that promote opportunities for members toreflect and spur personal learning from experiences gained from project activity.Koskinen et al. (2003) also studied the effect of team designs on learning. Their findingsindicate that project team may be designed to facilitate more opportunities for moreface-to-face interaction among team members, and reinforce knowledge-sharingbehavior among them.

Leveraging learning to fuel adaptive projectsAgile teams operating in a context defined by high dynamic complexity often rely onlessons gained from situated learning to evolve innovative practices more suited theircurrent situation. When new team members are added to such a project they tend

IJMPB5,1

134

to learn these innovative locally effective behaviors by actively participating in thepractices of the team. As their social connections within the team become stronger theirroles evolve from legitimate peripheral participation – taking in the ways of the teamat its present state of development – toward fuller participation where they shareresponsibility for improving practices through problem solving. Their increasingparticipation on the project team also changes the context of problem solving andlearning, such as learning how to better employ pair programming. Because agileprojects cultivate a project team culture that embraces change, normal organizationalforces that suppress adaptation to change and problems arising from it are minimized.Once a problem has been recognized in an agile team both adapting and learning occurin an integrative and self-reinforcing way. Such problematic situations can be adaptedto at an accelerating rate when existing team and organizational knowledge is broughtto bear in responding to changes. This process is enhanced by the quality and quantityof knowledge brought into it, as well as the wisdom to apply it successfully (Firestoneand McElroy, 2003). How might an agile project team in a manufacturing setting try tosolve the problems resulting from an overheating machine?

Adapting to the problem of an overheating machine might be addressed bysomeone recognizing a similar condition in the past and knowing which remediesworked, such as increasing cooling flow by removing obstructions. The currentproblem will not, of course, be exactly the same as past problems which is often whymultiple relevant past experiences are valuable in triangulating the current problem.

Learning takes place when knowledge is created, tested, and disseminated back intothe organization where it may be later brought to bear on new problems. For example,it may be hypothesized that the overheating machine problem might be solved byadjusting the operating RPM to minimize resonant vibrations. Such a strategy wouldclearly have to be put to the test across different machines to be considered reliableproblem-solving knowledge, and would require substantial adaptation in futurepractice to find a successful RPM. In both adapting and learning, the scope of existingknowledge leading into the solution as well as the scope of dissemination of newknowledge leading out of it is a critical factor in the success of the organizationalproblem-solving process over time. The scope of such flows of knowledge – incomingand outgoing – are often ignored by project managers. However, collectively theycompose the PSPs that define problem-solving effectiveness in teams and entirecompanies. PSPs that maximize these scopes of knowledge flows are thereforepreferred to patterns that limit them one way or another. The first step in managingthese PSPs is to be able to recognize the existing type of pattern that has evolved, overtime, in a project team. Next, project managers must decide whether the existingpattern is aligned with the strategic needs of the project and firm. Finally, the project’sleaders will identify the most desirable pattern and design a plan to change the team’sproblem-solving operations to shift in a more ideal direction.

Problem-solving patternsA PSP is the recurring organizational configuration of human interactions designed tosupport a project team in seeking, recognizing and formulating problems. It canfacilitate or dampen team capacities to learn, communicate, and create new knowledgeto improve team performance. The PSP includes these processes, as well as the projectelements performing them. These structures include factors such as: individuals,


135

teams, projects, friendship groups, organizational sub-divisions, committees of“experts,” communities of practice, communities of inquiry, and the organization itself.When the difficulty of problems rises above a minimum threshold, and cannot besolved using ordinary means, then new solutions and policies must be created on an adhoc basis within the project team. A PSP gives focus to employees by providing acoherent task-centered framework to promote greater learning, innovation, andorganizational adaptability. There are four basic types of PSP that may be designed orsimply evolve through outside the awareness of project managers.

Types of PSPsThere are many types of PSPs. Leaders may choose the type that fits their strategic intentand supports the major routine and adaptive processes of the project. It is feasible toenhance the effects of the various PSPs, over time, by incrementally moving the companyin the direction of a target PSP. Typically, project managers take actions that, thoughunintended, habitually limit their problem-solving process in the followings ways:

(1) limiting the “vertical” scope of experience and knowledge being applied byconstraining problem solving to specialists or managers found at a certainhierarchical level within the organization; and

(2) limiting the “horizontal” scope of experience and knowledge by solvingproblems internally to the operating unit in which they are found, regardless ofhow similar it might be to past of future problems in other units.

These two conditions when taken together define four basic types of PSPs (Figure 2).All projects have PSPs. Some are designed by project leaders or others evolve by

default, often hidden from the sight of unknowing project managers. The first step

Figure 2.The vision: movingtoward the OPSP

PSP Phase Space

MobilizedPSP

ClosedPSP Frozen

PSP

OpenPSP

IJMPB5,1

136

to start managing PSPs is to recognize the current or default PSP pattern existingwithin the project and the larger organization. Most often, project PSPs mirror thecompany PSP, but not always. For example, when Apple Computer developed theMacintosh computer, CEO Steve Jobs, consciously designed a different developmentenvironment for the Mac team to limit the impact of less desirable aspects of the Applecorporate culture might have on the team’s innovativeness. The four primary PSPs arenot a mutually exclusive, but they serve as a conceptual framework to clarify thedifferences among the various PSP types. The most common type of PSP isthe closed PSP.

The closed PSP. The closed PSP is a type of PSP characterized by a concentration ofauthority among a relatively small group of managers to recognize, define, formulateand solve problems, as well as to disseminate solutions. Usually, decisions regardingproblem solving are restricted to a company’s top management team; while most of thefirm’s other employees contribute their work effort to enhancing only the operationalside of business processing. Firestone and McElroy (2003, p. 48) define businessprocessing as “a hierarchical network of interrelated, purposive activities of intelligentagents that transforms inputs into valued outcomes, a cluster of task clusters, is abusiness process.” Business processing differentiates itself from its mirror image,knowledge processing, by focusing on performing work rather than creating knowledge.The closed PSP can be very effective in achieving desired outcomes when the topmanagement team’s problem-solving level of competence is sophisticated. However, it isoften difficult for teams using a closed PSP to duplicate the types innovative outcomescreated in companies that are adept at using OPSP. For example, the Toyota ProductionSystem relies on a subtle DNA where continuous distributed problem-solving processestrigger learning, knowledge, and innovation. Spear and Bowen (1999, p. 99) observed atToyota that:

If the rules of the Toyota Production System aren’t explicit, how are they transmitted?Toyota’s managers do not tell their workers and supervisors specifically how to do theirwork. Rather, they use a teaching and learning approach that allows their workers to discoverthe rules as a consequence of solving problems.

The mobilized problem-solving pattern. The mobilized problem-solving pattern (MPSP)is one in which many of a company’s project team members are enlisted into ongoingproblem-solving efforts and solution dissemination processes. This pattern is alsocharacterized by tightly managed projects governed by the firm’s top management teamwith the input of project team members. Only those problem-solving approaches favoredby the management cadre can be used. Companies can successfully employ suchpatterns, provided, that the level of shared problem-solving competence among its topmanagement cadre is high. Further, their range of new ideas must have enough varietyto cope with the challenges posed by the complexities faced by the project team. Thesepatterns are often more effective than the closed PSP pattern since they involve moreproject team members in the problem-solving process, though the range of potentiallyacceptable problem-solving methods may be quite narrow. MPSPs also pose challengesthat are difficult to surmount. MPSPs fall prey to the effects of inertia where teams areunable to go beyond reliance on a small elite group of decision makers to generate newproblem-solving strategies. This pattern not only operates in a constrained manner, butit can easily become insulated and self-sealing. Those employees who remain closest tokey customers and core processes can easily become locked out of decision-making


137

and policy-formulation deliberations. An example of such an organization is GeneralElectric with its centrally directed imposition of Six Sigma-based approaches to problemsolving.

The frozen PSP. The frozen PSP is one in which hierarchical stove-piped teams andorganizational structures have evolved to deal with problem solving and becomecalcified. Within these stovepipes the PSP is either of the closed or mobilized type.Communication flows across stovepipes are limited resulting from any number ofobstacles, such as varying versions of the corporate culture among project teams, orlack of trust among them. Resulting problems exceeding the stovepipe’s bandwidth(cross-stovepipe problems); can cause problem-solving initiatives to become stuck.This is often the least effective type of organizational PSP. Perrow (1999) argues thathighly complex dynamic systems are prone to cascading effects of ineffective solutionscoalescing in unintended ways to cause system-wide failures called normal accidents.This pattern reflects a lack of system integration. A more beneficial pattern for mostfirms can be found in the OPSP.

The OPSP. OPSPs form in projects where there is widely distributed authority toseek, recognize and formulate problems, arrive at new solutions, and disseminate thosesolutions to other project teams is the norm in that company’s culture. Here, structuralbarriers to self-organizing processes are minimal, enabling both human processes andinformation technologies to function optimally. More importantly, these structuresfacilitate self-organizing processes, enabling active participation in decisions byproject team members. By providing employees with opportunities for input into allphases of the problem-solving process the OPSP also enable broad-scale knowledgesharing. It also affords a relatively high level of internal transparency in knowledgeprocessing, fostering greater levels of employee trust in newly revised project policies.Besides, Toyota, other companies identified as “high-velocity” companies that excel atopen knowledge sharing and relatively OPSPs include, Alcoa, AvenueA, Pratt & Whitney, and Southwest Airlines (Spear, 2009).

All four PSPs can work well from time to time in certain situations. That is why allfour types have a certain measure of stability. However, the OPSP is most likely to beassociated with the effectively promoting greater agility and adaptation. OPSPs workwell when they enlist ideas from a broad spectrum of participants in problem solving,learning and knowledge management.

Enhancing PSPsEnhancing the effectiveness of an organization’s PSP is often simply a matter ofmanaging a project in a way that moves it toward the OPSP position. Of course, thisassumes that the OPSP is best problem-solving mode to use under any circumstances.While this is often true, it is not always so. Some project team cultures are hindered bylow levels of interpersonal trust or dysfunctional communication. Ordinarily, suchteams might be advised to address the underlying causes of these dysfunctions beforebeginning the move toward a more OPSP. Since all project teams have a default PSP. Itis important to recognize this PSP and compare its position relative to the OPSP –unless there are mitigating circumstances that would suggest moving toward anotherPSP. The distance between the two positions forms a gap and is indicative of thedirection future transformative PSP initiatives should take. To recognize any PSP,requires paying attention to how an organization treats problem-solving processes.

IJMPB5,1

138

Moving the position of an organization’s PSP is a process fundamentally driven byrefocusing the attention of employees from performing work by implementing existingsolutions to improving those solutions, as well as to replacing them with newly createdones. This process of enhancing an organization’s PSP is termed PSP management.PSP management activities include all initiatives directed at enhancing the abilities ofan organization’s employees and collectives to increase their performance by:

. seeking, recognizing and formulating problems;

. solving problems by developing new solutions; and

. communicating solutions to people who may need them.

Figure 3 shows these activities as elements of a larger problem-solving process.First steps: seeking, recognizing, and formulating problems. Problem-solving

processes in project teams normally begins with three basic diagnostic steps:

(1) seeking;

(2) recognizing; and

(3) formulating problems that are designed to activate a continuous seven-stepcycle.

Problem-seeking activities serve to bridge the chasm that exists between the OPSP andthe problem-solving process – in most organizations. These functions play a vital role

Figure 3.Managing the PSP

Formulating the Problem

Problem Situation: Seeking the Problem

Recognizing the Problem

Arriving at Solutions and Testing/evaluating them before Putting Them

into Practice

Spreading the Word about theNew Knowledge

Monitoring and Evaluating the Effectsof acting

Planning and Acting Using theNew Knowledge


139

in the PSP, because they continuously reactivate the PSP. Without them, initiating a PSPbecomes dependent solely on passive problem recognition. This reduces the control ofPSPs and the resultant growth of knowledge that results within a project. In someprojects, problem-seeking activities may become dormant. This is especially true wherethe pervasive culture within a company is centered upon the belief that finding newsolutions to problems is unnecessary for improving performance. Some project leadersmay believe that it is more effective to do problem seeking by objective third parties, suchas management consultants. In such cases, active problem-seeking behavior amongproject team members often lies dormant in those types of cultures. This can leadmanagers to view active problem solving negatively as a source that underminesteamwork. The unintended effect is to discourage employees from actively seeingproblems and looking around for trouble with the project. Project executives can takeaffirmative steps to shift project team members in the direction of active problem seekingby reframing it as being a launching pad for innovation, rather than as rocking the boat.Rewarding employee efforts aimed at “looking for trouble” can legitimize this type ofproblem-seeking strategy. When project managers welcome change it implies catalyzingit, rather than trying to prevent it from happening. Creative use of the forces of changecan often fuel team member growth and development in directions that supporttransformations toward agile project management. For example, when a customerchanges their mind because they have a better idea, everyone benefits by embracing thatchange. The project team’s attitude toward problem solving arises from the belief peoplecan never know in detail what will happen in the future (Liker, 2008, p. 154), and so, beliefsshould be subject to constant scrutiny to guard against “black swans” (Taleb, 2007).

Next steps: developing, testing, and evaluating new solutions. Enhancingproblem-solving processes is a necessary step, but alone is not sufficient to move aproject team closer to the ideal OPSP position. It is equally important to build employeecapabilities. Developing better quality solutions to problems among a project teamrequires multiple skills and abilities. There are two important stages in helping teammembers become more effective at developing new solutions:

(1) more freely coming up with new ideas; and

(2) knowing how to evaluate the potential value of new ideas beforecommunicating them to others.

No single methodology can guarantee that it will produce both new and highly effectiveideas (i.e. ones that merit seriously evaluating them in comparison to their competitors).However, there are strategies designed to increase the probability of producing betterideas. Project team members may draw upon various resources in attempting to createnew ideas. First, an enterprise’s larger internal environment can provide a rich source ofnon-project employees holding potentially valuable insights. Project team members canalso launch inquiries to acquire potentially helpful information by tapping a widevariety of popular web-based search and “Web 2.0” tools. A company’s capacity forpromoting new ideas is based on three factors capable of cascading down to projectteams. The first factor is the degree of transparency in the company, while the second isthe ability of its employees to remember past experiences. The final factor is theinclusiveness of the larger company’s networks, communities, and other collective socialgroupings that may potentially support a project team. Companies can also

IJMPB5,1

140

facilitate such creative ideation processes by taking a number of positive steps such asthe following:

(1) implementing policy allowing knowledge workers to access Web 2.0 and 3.0technology for interactions with others outside the firewall;

(2) introducing comprehensive organizational support systems to promote greateropenness to new ideas;

(3) constructing “knowledge bases” that actually distinguish knowledge frominformation;

(4) implementing training in using social technologies; and

(5) implementing IT applications to enhance the capabilities of individuals tocreate new ideas.

Openness to new ideas in the problem-solving process simultaneously expandsopportunities for knowledge creation and sharing, which in turn, can reiterativelyfacilitate the development of better quality solutions to problems. This kind of opennessalso supports processes leading to increases in organizational adaptability. Adding tothe variety of new ideas available to a project team also helps counter the effects ofenvironmental complexity. For example, May (2006, p. xi) reports that Toyota:

[...] implements a million ideas a year [...] It’s the reason why they’re one of the planet’s tenmost profitable companies. It is why they make well over twice as much money as any othercar maker, and with fewer than 15% of the market. It’s why their systems, processes, andproducts are the envy of the world. It’s the greatest source of their competitive advantage andstaying power. It’s their engine of innovation [. . .] At Toyota every idea counts. It’s anenvironment of everyday innovation, the direct result of a fanatical focus on getting a littlebetter daily.

Toyota’s success illustrates that the underlying reasons for their strategy of opennessto new ideas is not as much about a political ideology of corporate democracy as muchas it is about practical considerations pertaining to effective problem solving. Toyotahas discovered the practical consequences of adopting a business strategy designed topromote widespread active problem solving in project teams, thus generating superiorbusiness performance. Toyota is also a hyper-adaptive (high-velocity) organization(Spear, 2009). From the perspective of project team members, everything in their team’sinternal knowledge base is simply information – no more, no less. In the absence ofextensive knowledge validation processes, employees simply cannot evaluate whichparts of a knowledge base constitute organizational knowledge, and which are justinformation (Firestone and McElroy, 2003). Hence, project teams seeking to movetoward a more OPSP need not to just become more agile, but to do so by leveraging thelearning and knowledge processes available to them.

Putting solutions into action: sharing, using, and evaluating knowledge. Distributedactive problem solving (DAPS) helps to contribute to the formation of a realorganizational knowledge base to be leveraged as a valuable reference in futureperformance improvement initiatives. DAPS represents a quantum leap forward inbusiness strategies. It concurrently improves business performance, innovation, and thecompany’s capacity for adaptation. It is possible to fortify such systems by goingbeyond simply capturing lessons learned, to building real knowledge bases containingboth knowledge claims and meta-claims (Firestone, 2003; Firestone and McElroy, 2003).


141

When project team members engage in active problem solving, they must ultimatelyrely on knowledge gained from past experiences that prospectively guides theirimagination of how their anticipated future actions will cause certain effects. Realknowledge bases tracking performance through meta-claims makes problem solvingmuch easier for them. That is why it is imperative for project managers to seek greaterleverage in improving performance by tapping real knowledge bases.

Once new knowledge has been used to solve problems in a company the reliabilityand trustworthiness of that new knowledge must be assessed through the firm todetermine its potential for ongoing utility. New knowledge is not only a tool forimproving performance, but it also shapes the perceptions of team members infocusing their perceptions and interpretations of future problems.

ConclusionsUsing collective and distributed forms of problem solving are growing increasinglypopular. They provide project managers with more a highly effective means to deal withunprecedented types of unforeseen problems that arise over the lifespan of projects.Conventional problem-solving methods tend to work well when problems are routineand have known solutions. However, today projects operate increasingly withindynamic environments where conventional planning and control systems break down.The effects of such breakdowns include project delays, scope creep, cost overruns, andlow quality. One strategic alternative project managers can take to improve theeffectiveness of problem solving is to move to begin to systematically manage PSPs.PSPs describe basic elements of the way problems are defined, recognized, solved, andsolutions distributed in projects. Project managers are often inclined to rely on closedPSPs because they see the alternative patterns as being too slow or costly. While thisjudgment may seem justifiable to some managers, it ignores many other risks and coststhat stem from system failures and ineffective responses to unpredictable projectdynamics. It is fundamentally unjustifiable because, in major projects, failure andunderperformance are the norm – not the exception. Despite the conventional wisdom tothe contrary, radical change and wicked project dynamics are common, not unusual.Still, some project managers stubbornly adhere to using simplistic problem-solvingmethods capable of being effective only in the exceptional circumstances of routinestatic environments. A decade ago, Sterman (2002, p. 46) observed:

Project management suffers from numerous problems of costing and scheduling. Costoverruns of 100 to 200% are common. Projects are often delayed to the point where themarket conditions for which they were designed have changed. Many projects suffer from the“90% syndrome” in which a project is thought to be 90% complete for half the total timerequired. Project management is often counterintuitive.

Has project performance really changed significantly in the past decade? While that isthe topic for further investigation, there are promising signs that some companies haveadopted increasingly sophisticated methods that are more equal to the challengesbeing posed today.

Project failures often originate in problem misdiagnosis and misattribution ofproblem causes. However, more significantly, faulty larger systems, such asinappropriate PSPs, limit project knowledge in ways that hinder effective control ofproject dynamics. Firms cannot afford to dismiss problem solving as only being anactivity done by individuals to address isolated events. In fact, distributed

IJMPB5,1

142

problem-solving processes serve as an ideal platform for improvement processes, suchas quality management, organizational learning, and knowledge management.Knowledge plays a critical role in effective problem solving because it is the basis fordeveloping more highly effective solutions. Shifting a project team toward a more activetype of learning and knowledge processing will not only enable greater agility andopenness in problem solving, but it will also facilitate the creation of higher qualitysolutions to problems. Newer project management methods, such as Scrum (Schwaber,2004) and Toyota’s yokoten (Liker, 2008) appear to be useful innovations that combinedistributed problem solving with agile and knowledge processing features. Clearly,there is a need for continuing future research to identify and refine practical methods forimproving the quality of project knowledge for achieving more highly effectivesolutions. In particular, the system dynamics method when combined with knowledgeprocessing holds the promise of addressing many of the complexities currentlyoverlooked in current project management practices. We propose that a fundamentalstep in the right direction is for project managers to simply recognize their project’s PSP.

References

Ackoff, R.L. (1999), Re-creating the Corporation: A Design of Organizations for the 21st Century,Oxford University Press, New York, NY.

Appelo, J. (2011), Management 3.0: Leading Agile Developers, Developing Agile Leaders,Addison-Wesley Signature Series (Cohn), Addison-Wesley, Boston, MA.

Augustine, S., Payne, B., Sencindiver, F. and Woodcock, S. (2005), “Agile project management:steering from the edges”, Communications of the ACM, Vol. 48 No. 12, pp. 85-9.

Beck, K. (1999), ExtremeProgramming Explained: Embrace Change, Addison-Wesley, Reading, MA.

Carroll, L. (1865), Alice’s Adventures in Wonderland, Macmillan, New York, NY.

Checkland, J. and Scholes, J. (1990), Soft Systems Methodology in Action, Wiley, Chichester.

Cockburn, A. and Williams, L. (2000), “The costs and benefits of pair programming”, Proceedingsof the First International Conference on Extreme Programming and Flexible Processes inSoftware Engineering (XP2000), available at: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

de Klerk, A.M. (2001), “The value of project risk management”, Proceedings PortlandInternational Conference on Management of Engineering and Technology (PICMET’01),Portland, OR, USA, Vol. 2, pp. 570-6.

Firestone, J. (2003), Enterprise Information Portals and Knowledge Management,Butterworth-Heinemann, Boston, MA.

Firestone, J. and McElroy, M. (2003), Key Issues in the New Knowledge Management,Butterworth-Heinemann, Boston, MA.

Flood, R. (1995), Solving Problem Solving, Wiley, New York, NY.

Johnston, R.B. and Brennan, M. (1996), “Planning or organizing: the implications of theories ofactivity for management of operations”, Omega: International Journal of ManagementScience, Vol. 24 No. 4, pp. 367-84.

Koskela, L.J. and Howell, G. (2002), “The underlying theory of project management is obsolete”,paper presented at the PMI Research Conference, Seattle, WA, June.

Koskinen, K., Pihlanto, P. and Vanharanta, H. (2003), “Tacit knowledge acquisition and sharingin a project work context”, International Journal of Project Management, Vol. 21 No. 4,pp. 281-90.


143

Larman, C. (2003), Agile and Iterative Development: A Manager’s Guide, Addison-WesleyProfessional, Boston, MA.

Lave, J. and Wenger, E. (1991), Situated Learning: Legitimate Peripheral Participation,Cambridge University Press, Cambridge.

Liker, J. (2008), Toyota Culture:The Heart and Soul of the Toyota Way, McGraw-Hill, New York, NY.

Lyneis, J. and Ford, D. (2007), “System dynamics applied to project management: a survey,assessment, and directions for future research”, System Dynamics Review, Vol. 23,pp. 157-89.

McElroy, M. (2003), The New Knowledge Management, Butterworth-Heinemann, Boston, MA.

May, M. (2006), The Elegant Solution: Toyota’s Formula for Mastering Innovation,The Free Press, New York, NY.

Padberg, F. and Mueller, M. (2003), “Analyzing the cost and benefit of pair programming”, NinthIEEE International Software Metrics Symposium (METRICS’03), Sydney, p. 166.

Perrow, C. (1999), Normal Accidents, Princeton University Press, Princeton, NJ.

Popper, K. (1999), All Life is Problem Solving, Routledge, London.

Repenning, N. and Sterman, J. (2001), “Nobody ever gets credit for fixing problems that neverhappened: creating and sustaining process improvement”, California Management Review,Vol. 43 No. 4, pp. 64-88.

Repenning, N. and Sterman, J. (2002), “Capability traps and self-confirming attribution errors in thedynamics of process improvement”, Administrative Science Quarterly, Vol. 47, pp. 265-95.

Repenning, N., Conclaves, P. and Black, L. (2001), “Past the tipping point: the persistence offirefighting in product development”, California Management Review, Vol. 43 No. 4.

Schwaber, K. (2004), Agile Project Management with Scrum, Microsoft Press, Sebastopol, CA.

Sense, A. (2007), “Structuring the project environment for learning”, International Journal ofProject Management in Business, Vol. 25 No. 4, pp. 405-12.

Spear, S. (2009), Chasing the Rabbit: How Market Leaders Outdistance the Competition and HowGreat Companies can Catch Up and Win, McGraw-Hill, New York, NY.

Spear, S. and Bowen, K. (1999), “Decoding the DNA of the Toyota production system”, HarvardBusiness Review, September/October, pp. 96-106.

Sterman, J. (2002), “System dynamics modeling for project management”, Projects and Profits,Vol. II, pp. 46-50.

Taleb, N. (2007), The Black Swan, Random House, New York, NY.

Thompson, J. and Cavaleri, S. (2010), “Dynamic knowledge, organizational growth, andsustainability the case of Prestwick memory devices”, International Studies ofManagement & Organization, Vol. 40 No. 3, pp. 50-60.

Wiig, K. (2004), People-focused Knowledge Management, Butterworth-Heinemann, Boston, MA.

Further reading

Ackoff, R.L. (1978), The Art of Problem Solving, Wiley, New York, NY.

Ashby, W.R. (1960), Design for a Brain, 2nd ed., Chapman & Hall, London.

Bowen, H.K. and Spear, S. (1999), “Decoding the DNA of the Toyota production system”, HarvardBusiness School: Working Knowledge, available at: http://hbswk.hbs.edu/item/0869.html

Cavaleri, S. (2011), “Toward a more pragmatic knowledge management: Toyota’s experiences inadvancing innovation”, Technological, Managerial and Organizational Core Competencies:Dynamic Innovation and Sustainable Advantage, IGI Global, Hershey, PA.

IJMPB5,1

144

Cavaleri, S. and Fearon, D. (2000), “Integrating organizational learning and business praxis:a case for intelligent project management”, The Learning Organization, Vol. 7 No. 5,pp. 251-8.

Cavaleri, S. and Reed, F. (2008), “Leading dynamically complex projects”, International Journal ofManaging Projects in Business, Vol. 1 No. 1, pp. 71-87.

Daft, R. (2001), Organization Theory and Design, Southwestern, Cincinnati, OH.

Davenport, T. and Glaser, J. (2002), “Just-in-time delivery comes to knowledge management”,Harvard Business Review, Vol. 80 No. 7, pp. 107-11.

Durfee, E.H. (1999), “Distributed problem solving and planning”, in Weiss, G. (Ed.), MultiagentSystems: A Modern Approach to Distributed Artificial Intelligence, The MIT Press,Cambridge, MA.

Durfee, E.H., Lesser, V.R. and Corkill, D.D. (1989), “Trends in cooperative distributed problemsolving”, IEEE Transactions on Knowledge and Data Engineering, Vol. KDE-1 No. 1,pp. 63-83.

Fearon, D. and Cavaleri, S. (1994), “Systems integration through concurrent learning”, IndustrialManagement, Vol. 36, July/August, pp. 27-30.

Fearon, D. and Cavaleri, S. (2006), Inside Knowledge: Rediscovering the Source of PerformanceImprovement, ASQ Quality Press, Milwaukee, WI.

Firestone, J. (2008a), Knowledge Management and Reducing Risk, Ark Group, London.

Firestone, J. (2008b), “On doing knowledge management”, Knowledge Management Research& Practice, Vol. 6, pp. 13-22.

Firestone, J. (2009), “Knowledge management, social media and the culture war conjecture”,Inside Knowledge, Vol. 13 No. 1, pp. 14-17.

Garvin, D. (1993), “Building a learning organization”, Harvard Business Review, Vol. 71 No. 4,pp. 78-92.

Osono, E., Shimizu, N. and Takeuchi, H. (2008), Extreme Toyota: Radical Contradictions thatDrive Success at the World’s Best Manufacturer, Wiley, New York, NY.

Senge, P. (1998), “The practice of innovation”, Leader to Leader, Wiley, New York, NY, pp. 16-22.

Spear, S. (2004), “Learning to lead at Toyota”, Harvard Business Review, May, pp. 1-9.

Spear, S. (2011), “Relentless pursuit of perfection means just that – self-critique and facing one’sproblems”, The Lean EDGE, 16 February, available at: http://theleanedge.org/?p¼2486

Wald, M. (2011), “Electronic flaws did not cause Toyota problems, US says”, New York Times,8 February, available at: www.nytimes.com/2011/02/09/business/09auto.html

Wikipedia (2011), “Mashup (web application hybrid)”, available at: http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29 (accessed 2 November 2011).

Winter, S. (2002), “Understanding dynamic capabilities”, Working Paper No. WP 2002-05, TheReginald H. Jones Center, The Wharton School, University of Pennsylvania, Philadelphia, PA.

Corresponding authorSteven Cavaleri can be contacted at: [email protected]

To purchase reprints of this article please e-mail: [email protected] visit our web site for further details: www.emeraldinsight.com/reprints


145

managing project problem‐solving patterns

Documents