Understanding and overcoming communications complexity in projects
Vijay Kanabar, PhD , Boston University
Roger Warburton, PhD, Boston University
The pressure to conquer communications complexity is intense for project managers of medium to large projects. In emerging situations of increasing complexity and ambiguity, it is acknowledged that up to 90% of the work of a project manager involves communications, and that poor communication increases the risk of project failure.
With large projects this issue is exacerbated. As a project grows in size, it involves more team members and stakeholders, and communications complexity increases geometrically. The equation “number of communication paths equals to n (n-1)/2” is familiar to project management professionals. Why is this true? What are the elements that contribute to this reality? What is our approach to mitigating this risk due to the increased number of communication paths?
In this paper, we present an overview of project communication and its elements and attributes. We identify several key communication drivers that play key roles in contributing to project complexity. Arguably, even complex communications systems have simple roots, and understanding these roots will help us to understand and overcome complexity and ambiguity in project communications. A project manager will find the proposed architecture of project communications invaluable in managing the project.
There is an assumption in much of the project management literature that projects are relatively stable environments, where the accepted paradigm is “plan, then execute the contents of that plan with the minimum of deviation.” It is, however, becoming more accepted that the execution of projects is fraught with change, and that turbulent environments and interactions between projects and programs is generating additional layers of complexity (Cooke-Davies et al., 2007; Leybourne, 2007).
In this circumstance, complexity can be defined as “having many diverse and autonomous but interrelated and interdependent components or parts linked through many (dense) interconnections” (businessdictionary.com). Evidence abounds of projects of huge complexity, some of which were bounded in basic and understood routines and tasks, but complex by virtue of size (e.g., Boston’s “Big Dig”), and some of which are complex as a result of being innovative (e.g., Dubai’s “Buij Khalifa” building), or by being “untried” (e.g., the BP Gulf of Mexico oil disaster).
Additionally, it is an unfortunate fact that project scope and user requirements are often defined in terms that are less than optimal, leading to requirements being articulated in ways that are open to multiple interpretations. This ambiguity, which can be defined in terms that are appropriate to project work as “doubtfulness of meaning, or uncertainty of intention” (businessdictionary.com) means that the allocation of tasks and activities is likely to be less precise, and the outputs or deliverables are likely to be rather more “abstract.”
Complexity and Ambiguity in Projects
There is also a significant linkage between the concepts of complexity and ambiguity as far as projects are concerned. Complexity is generated by the need to address projects with changing deliverables in turbulent environments in which organizations are often attempting to deliver with limited or stretched resources. As the requirements of a project in fast-moving and changing circumstances are likely to be less well defined by necessity, then a level of ambiguity gets built into the requirements, and it is often up to the project manager to resolve these issues for and on behalf of the project team.
One element of the literature sees projects as “complex adaptive systems” (Stacey, 1996; 2001), and this is particularly appropriate if the project is one of a series, or a “program” of interlinked projects with dependent deliverables, resourcing issues, and timing requirements.
There is also a connection here to the literature on improvisation in projects, in that often issues relating to complexity and ambiguity can be resolved using creative thought, an intuitive “gut feel” for what will work in a particular circumstance, and the adaptation of previously utilized routines, These are all identified as components of organizational improvisation. Additionally, bricolage, which relates to resolving issues effectively with only the resources at hand, is a meaningful skill in such circumstances.
The improvisation literature has been evolving significantly since the mid 1990s, and specific attention has been directed at improvising generally (Cunha, Cunha, & Kamoche,1999; Chelariu, Johnston, , & Young, 2002, and many others, including Karl Weick, Mary-Jo Hatch and Mary Crossan), and at improvising project managers (Gallo & Gardiner, 2007; Kanter, 2002; Leybourne, 2002; 2006a; 2006b; 2006c; Leybourne & Sadler-Smith, 2006) since around the turn of the millennium. There has also been a move toward project-based techniques that concentrate on exploratory and adaptive management (Cicmil & Hodgson, 2006), particularly where projects are used to manage product and service development activity.
There is, of course, also a strong and robust link with communication within projects here; the more stakeholders and participants there are in a project, the more lines of communication there are. This gives rise to a greater opportunity for ambiguity and lack of clarity in messages and other forms of project information exchange.
Reasons for Communications Complexity
Communication is a major problem in project management. Several surveys reveal that projects have struggled or failed due to a lack of ability to communicate all aspects of the project clearly to stakeholders. Let us review some of the statistics (IT Cortex, 2002) Bull Survey: A total of 203 telephone interviews were conducted with IT and project managers from the finance, utilities, manufacturing, business services, telecommunications, and IT services sectors in United Kingdom. The main IT project failure criteria identified by the IT and project managers included poor communications (40%) and ranked third in a list of other criteria. A respected survey on project risks, “The Chaos Report,” does not mention project communications directly as a keyword, but the top two reasons for project failure are directly concerned with communications failure and they are: lack of user input 12.8%, and incomplete requirements and specifications 12.3% (Group, 1995). A quick analysis of similar surveys indicates the risks and issues that relate to communication complexity and communication breakdown taking place within many projects.
At a fundamental level, we have identified several drivers for communication complexity:
- Number of Communication Links
The equation to calculate the number of communication links, (n-1)/2, is possibly deeply entrenched in the longer term memory of all project management professionals. So, why is this key driver for communication complexity? Let us assume that you are in charge of a medium project with a dozen key team members. This formula results in sixty-six different communication paths. From a project management perspective, if there is a change to the project scope and you communicated this noticeably vaguely, sixty-six communications (e.g., e-mails) could fly around and would eventually add to your burden.
Exhibit 1: Communication links
- Sending and Receiving Models
Even a simple conversation in a link between two people can be challenging due to the interference that takes place in the communication model. The sending and receiving model between two people would involve the following processes:
- • Person sending the message after encoding it.
- • Receiver translating the message after decoding it.
- • The message goes through a medium after being filtered.
- • There is a feedback message that must be sent back to the sender to ensure communication closure.
When two people from different countries are communicating, communication is undoubtedly a challenge. Books have been written addressing the issue of communications challenges when projects are global in nature. But what about communicating with someone from the same region, for example, a Boston-based project manager communicating with a stakeholder from New York? The Boston accent is well known (“paak the caar in Haarvard yaad”!). There are also ambiguity and confusion inherent in many common terms. Some words used in the Boston area but not in many other American-English dialects (or used with different meanings) are (Wikipedia, 2005):
- • bubbler or water bubbler – “drinking fountain”
- • barrel – a trash can, garbage can
- • frappe – “a blend of ice cream, milk, and syrup”
- • grinder – another name for a submarine sandwich
- • jimmies – “chocolate ice cream sprinkles”
- Complexity Grows Geometrically with Project Size.
It is not a surprise to anyone that as projects grow larger in size, project complexity increases. This has been empirically documented in several cost-estimation models for the software industry. For example, research data from the well-known COCOMO model by Barry Boehm show exponential increases in estimated effort documented as exponents on their parametric model (Boehm, 2000). From a communications perspective, a large project becomes a significantly challenged project. Subsequently, projects such as the Boston, Massachusetts domiciled Big Dig project and the Channel Tunnel project have become “folklore” examples of complex projects (Hass, 2010).
The public works project in Boston, known fondly as the Big Dig, went from estimates of $2.6 billion to a final price tag of $14.8 billion. Conceived in the 1970s and finished, more or less, in 2005, the Big Dig is modern America’s most ambitious urban-infrastructure project, spanning six presidents and seven governors, and costing $14.8 billion.
The United Kingdom/France Channel Tunnel sustained cost overruns of 70% on the original contract. The banks and the shareholders who financed the Channel Tunnel knew (or should have known) that the risks of building giant projects are very great. “No projects are harder to achieve,” a consultant advised the Channel Tunnel’s five lead banks in 1984. “To work on giant projects is always exhausting and often demoralizing.” He should have added “bankrupting.” Despite the consultant’s warning, the banks pressed ahead. They were under pressure from their governments, both of whom wanted to do something grandiloquently ambitious on the “world” stage without major government investment. The banks were under pressure from their good customers among the large construction companies to lend money for something “world class” and they were also pressured internally to keep up the pace of business. This became the largest, privately financed project in history.
Research and analysis at Boston University into the many challenges of the Big Dig project point to poor risk analysis and issues management (Warburton & Greiman, 2009).
- People and Human Resource Issues
Another fact that all project management professionals are familiar with is that a project manager will spend up to 90% of his or her time communicating. So, it is clear that if you are not communicating well you are not managing the project well; however, we all communicate in different ways, and due to previous experience some get the message across better than the others. To be successful at communicating we have to also make sure that the people and stakeholders we interface with understand the problem. The keyword “communication” is derived from the Latin communis, which implies “shared information.” According to Allan Barker, “Until you have shared information, you haven’t communicated. Additionally, until a recipient has understood it, the way that you intended it to be understood, you haven’t shared with them” (Barker, 2000). The key complicating problems with communication are people issues, power play, and politics in project management. Sharing information will not occur unless you have succeeded in overcoming the limitations of the organizational structure that you operate your business in. Project managers are frequently operating within a matrix structure and do not have a strong powerbase. Also, they must use skills of inquiry and negotiation to get things done, which adds to the complexity of simple communications in projects.
- Inadequate Documentation of Communications Plan and Project Communications Requirements.
The communication management plan is the primary output of the communications planning process as documented in A Guide to the Project Management Body of Knowledge (PMBOK® Guide). This plan is created by the project manager and becomes part of the project plan. The purpose is to inform all stakeholders how and in what form communications will be handled on the project. It answers the fundamental questions pertaining to the project, such as:
- • What information needs to be communicated?
- • Who will communicate this information and make decisions subsequently?
- • How will other pertinent information be distributed and in what format?
- • How will schedules and other reports throughout the project be distributed?
- • What communication will take place and to whom in the event that there is a variance?
Planning precise project communication requirements during project planning phase is important. This is rarely done very well. Documenting customer requirements and understanding the appropriate generation of project information before the project execution begins will ensure that the right stakeholders receive the right information. This prevents the politics and people issues that could hamper a project.
Overcoming Communications Complexity
In order to discuss our strategy to overcome communications complexity, we have used a ‘bottom-up’ (i.e. working from the individual project manager/team member and the demands of their tasks and deliverables ) approach and focused on the individual project manager and attempt to mitigate the communications issues identified in the previous section. The PMBOK® Guide processes provide a strong foundation to over communication challenges. The five processes introduced below constitute the elements and attributes of effective communication within projects:
- Identify stakeholders: In the initiation phase, we identify all individuals, groups, and organizations both internal and external that will be impacted by the project. We classify information about them in terms of their interest in the project and the power they have in the organization.
- Plan communications: During the planning phase we determine the information and communication needs for the project, and consider the communications approach to be used.
- Distribute information: In accordance with the project communications plan, we make the needed information available to project stakeholders in a timely manner. We also respond to unexpected requests for reports and information. This process belongs to the executing process group.
- Manage stakeholder expectations: We communicate and work with stakeholders to understand and meet their needs, address risks and issues that arise during execution, and manage expectations within the scope of the project plan.
- Report performance: Collecting and distributing performance information to the stakeholders. This is a “monitoring and controlling” process group activity.
Overcoming Complexity Due to Size. As a project grows in size, it involves more team members and stakeholders, and communications complexity increases geometrically. So, let us first address the basic challenge with large projects. When we have a large number of communication links it is important to divide them into subgroups. ( Exhibit 2
Exhibit 2: Why to use Sub Groups
Let us now divide the project into four subgroups, which are is illustrated in the exhibit below:
Exhibit 3: Divided in to Sub Groups
With four subgroups, we notice that the number of communication paths that a project manager has to be concerned with is only six.
Exhibit 4: Resulting Communication Path
In summary, the total communication paths:
Exhibit 5: Total Communication Paths
Defining a rigorous project communication plan is very important for project success. Questions, such as the following, need to be asked of all stakeholders: What information needs to be communicated? Who will communicate this information and make decisions subsequently? How will other pertinent information be distributed and in what format? How will schedules and other reports be distributed throughout the project? What communication will take place and with whom in case there is a variance? (Kanabar & Warburton, 2008)
So, a good communication management plan would cover the following topics (Down & Taylor, 2008):
The project communication plan: It would have columns covering the following attributes:
What needs to be communicated
When and how often
Method for communicating
Person responsible for sending
The project organization chart: This identifies the special organizational structure created for the duration of the project.
Project communication requirements matrix: This is a chart that shows how communication flows in a project. Many project managers are not proactive in exhaustively identifying the project communications requirements. Project managers and analysts put rigorous effort in identifying product requirements leading to identification of good specification. Similarly, substantial effort must be made to document the customer communications requirements within the project communications plan. For example, if a customer wants a prototype and a phase end progress report, both of these constitute requirements that must be documented in the project communication plan. Significant effort is required to create an exhaustive list of requirements pertaining to the project. A project communication matrix shows who develops the information and who receives it. The direction and flow of information show readers how the information transfers to different parties. The following is an example of data in the matrix:
Project manager: Communicates status weekly and participates in monthly stakeholder meetings; also, in the project management information system he or she would update project schedule and budget information.
Similar data would be identified for stakeholders, estimating teams, and Project Management Information System (PMIS).
Role report matrix: A role report matrix identifies the reports that a project manager will create for the various people in the team. Following are two examples that describe the people or role that receive the report.
Stakeholder, John Smith, receives weekly schedule, cost, and risk reports
Quality control manager, Jill Towns, receives quality report, risks and issues report, and status report.
Leveraging a lessons learned knowledge base: Various project management maturity models reveal that organizations avoid inconsistent procedures and ad-hoc approaches to project management because these cause frustration and loss of productivity. Creating a good repository of lessons learned and investigating them at the start of each process dramatically improve the productivity of the project manager and project team. Examples of lessons learned would be:
Use of formalized processes and reuse of tools and templates in an organization.
Investigation of risks that occurred in previous projects.
Consideration of actual costs for a project (which would act as a foundation for estimating the current project).
Distributing project information effectively—don’t hesitate to use a dedicated resource: One can communicate verbally or in written form visually or in writing, and one can do so informally or formally. As e-mail, tweeting, instant messaging, and teleconferencing have become popular in the workplace, the need for quality communication is now very important. E-mail is regarded as informal written communication. Project managers may use e-mail to communicate things that are non-controversial, non-threatening, and non-personal. E-mail is not the best medium for a lot of communication, especially anything that is performance related. It doesn’t take much more than a forwarded e-mail or an error in “broadcasting” to the wrong group to destroy team morale. Project managers who have very good communication skills, both verbal and non-verbal, can achieve amazing results in large projects. For large projects, because most communication is executed through e-mail and critical details might not be communicated well, assigning a dedicated resource to consolidate details and communicate effectively is a strategy that we strongly recommend.
Building virtual communication skills: Large projects will certainly involve vendors who are remotely located and even virtual teams located in different parts of the country or the world. Using communication tools effectively is important to managing virtual teams. When communicating with virtual teams, very little face-to-face interaction takes place, and teleconferencing and videoconferencing technology should be leveraged to monitor and control projects. For large projects, e-mail should be aborted in favor of real-time communication using video conferencing technology, for instance. “Real-time communication allows opportunities for interruption if you see someone has misunderstood and begins to discuss something irrelevant. Interruption is not a possibility with e-mail so we have to work harder in our original messaging to be more explicit” (Dignen, 2010).
Dealing with conflict in the project environment: learn how to communicate and influence: Almost all project managers will encounter conflict within their project environment. The modern view of conflict is that conflict is not necessarily bad. It is a natural tension that arises in the project environment when the resources are limited and the schedule is too tight to create a new product or service for the first time. Goleman views conflict management as negotiating and resolving disagreements; it includes the following competencies (Goleman, 1998):
handling difficult people and tense situations with diplomacy and tact
spotting potential conflicts, bringing disagreements into the open, and helping to de-escalate
encouraging debate and open discussion
orchestrating win-win solutions
Conflict can be paralyzing. Teams and individuals will work in isolation. You will be unable to make decisions at critical points. A lack of enthusiasm and low team morale among the team members will hamper the productivity of the project. Project managers coming from engineering or related disciplines are occasionally at a disadvantage when it comes to communications and managing conflicts in the project environment. Such managers must develop communication skills to deal with such conflict, in a range of topics such as: listening, expressing, reading and using body language, decoding hidden attacks and requests, uncovering hidden agendas, clarifying language, negotiating with assertiveness, winning friends and building alliances, keeping order, finding consensus, building morale and, finally, delivering effective presentations. Books such as How to Communicate by McKay, Davis, and Fanning (1997 cover such topics and can act as a guide for project managers to fine tuning the complicated world of human relations. Solving problems by negotiating the issues more frequently to a win-win conclusion and working together as a team more effectively are the key skills that one should develop through self-education and experience (Kanabar & Warburton, 2008). One final note: lack of trust creates hurdles in conflict management. The project manager must demonstrate honesty and express the desire to build trust.
Managing project scope—revalidate, monitor, and control: Even small projects result in scope creep. Mega-projects experience scope creep of unimaginable proportions. Constantly reviewing the scope and minimizing it or right sizing it are very important. In large projects, substantial duration has possibly elapsed between scope definition and design. So, a key to success would be right sizing the scope via effective communication with stakeholders. If there is uncertainty, iteration and methodologies such as agile must be used.
Communicating project progress via milestones: Milestones are a powerful project-management tool for medium to large projects. Even smaller projects benefit from milestones, but managing by milestones is inevitable on large projects. You should designate a milestone once every quarter to focus the team toward the project goal and certainly this will motivate the project team. When defining fixed-date milestones in large projects it would be wise to have a buffer preceding the date (Leach, 2005). Project managers can certainly have floating milestones (avoid using either a planned or actual date) to represent key technical accomplishments. Floating milestones are a great aid to networking development for marking completion of major project accomplishments (e.g., completion of design) and are therefore also great accomplishments to celebrate (Leach, 2005). We don’t discount the value of project dashboards and other useful reporting tools, but nothing comes across as clearly as a milestone to communicate a clear and simple message about project performance.
Document and communicating changes using integrated change control processes: Changes will occur in projects during the execution phase. Potential project changes originate from many sources (Kendrick, 2004):
- Internal (plan variance analysis, performance reporting, project reviews, risk identification, team-generated ideas, opportunities, loss of staff), and
- External (change requests, regulatory changes, modified standards, market research, new technology, meddling sponsors, natural disasters).
In large projects, integrated change control will encompass many different types of changes and you can analyze each proposed change, using the appropriate process for its type (Kendrick, 2004):
Scope: scope change control, quality control
Schedule: schedule control
Cost: cost control
Procurement: contract administration
Risk: risk response planning, risk monitoring and control
Staffing: organizational planning
Process: process improvement, organizational change
Overall: project review
Catastrophic: problem escalation, canceling projects
Regardless, our goal should be to manage changes coherently, and minimize the impact. Within this context, the project manager must (1) understand change control roles (especially stakeholders) and (2) formally use a change control plan.
Communicating project status using earned value: Poor cost estimating is a major source of problems and risks in a project. It is not uncommon for large projects to experience cost growth and overshoot the budgets. The ominous words, “the project is way over budget” are frequently heard in most organizations (Kanabar & Warburton, 2008). Project cost management has three key processes, which must be executed well if a project is to perform well and they are:
- Estimate cost: Process identifies the total cost (of all resources) needed to complete the project scope. Literature research reveals that rigorous estimating and cost management increase reliability and reduce chances for project failure (Hass, 2010).
- Determine budget: Aggregate the costs to establish a cost baseline with a schedule. This is where we assign costs to activities in the work breakdown structure. The biggest expense on most projects is the cost of labor or resource effort. Management authorization of too low a budget is a key reason for project cost overruns.
- Control cost: Monitor and control the cost variance in the project execution phase. Planning to use earned value analysis and to report and communicate changes to project budget using the earned value method (EVM).
The importance of using the earned value method to monitor and communicate project progress has been demonstrated widely. “What earned value will do is provide an early warning signal to the project manager, to senior management, and to the customer. It will indicate that the project will likely require so much money to complete, unless actions are taken to change future events. Sometimes project scope will need to be reduced. Sometimes risks will need to be taken. Sometimes additional funds will need to be made available to complete the project.” (Fleming & Koppelman, 2005). Project managers should leverage tools such as TCPI to get accurate earned value results to bring projects back on track.
Project quality and poor technical performance: The thrill of achieving a tight deadline and meeting project budget goals is very short-lived. Quality indeed is “Job 1” for a project manager. Even excellent organizations such as Toyota have realized that its reputation for quality can quickly vanish if defective workmanship and poor technical performance come into play. Quality crisis rarely erupts abruptly. Take a look at the Toyota quality crisis. A review of Toyota recalls done by the authors in 2007, two years before the full-blown crisis, revealed brake and hydraulic foundation defects, and more (Kanabar & Warburton, 2008). Quality problems in a project lead to cost overruns. We have seen that repeatedly in projects and even in the Big Dig project, when weak glue and insufficiently tested design led to a fatality and substantial expenses. Project managers must focus on communication tools to manage and report quality.
Communicating risks and investigating new solutions: Risks are present in all projects, big and small. The key strategy with risk management is that “prevention is better than the cure.” Of course, there are “good risks” that result in opportunity and must be maximized. The risk management plan is a key live document that the project manager will manage. The risk management plan identifies risks, defines them, mitigates them, and provides a framework to monitor and control them throughout the project. This document will play a significant role in project monitoring and control and, if managed well, will result in project success. Risk management includes communicating concerns to stakeholders and elevating them to senior management in a timely manner. Not all risks are “bad,” and the project manager should use any opportunity to analyze the project for “good risks.” “Rigorous risk management preempts challenges and seizes new opportunities (Hass , 2010). From our experience, project success will depend on successfully communicating risks to the stakeholders. The project manager should provide adequate resources to enable such communication and provide a formal approach to communicating risks and issues to the appropriate person in a timely manner; failing to do so will result in you being at the helm of “Project Titanic.”
Understanding the influence of complexity and ambiguity within the project domain is the key to effective project communication. Communications complexity can result in communications failure in large projects. At a theoretical level, the project manager must design team clusters with well-formed independent boundaries to manage communications in a large project. Designing well-formed smaller sub-groups will reduce the communication efforts for all parties concerned and reduce the chances of project failure. In this paper we have also identified the fundamental key points that a project manager can adopt. For instance, creating a comprehensive communications management plan will go a long way in ensuring project success. Asking stakeholders and team members what form of communication they want to receive and in what frequency, and asking team members and subgroups what they want to communicate to you as the project manager, will provide excellent insights. A dedicated “communications issue log” consisting of attributes such as: issue#, date, submitted by person assigned, status, date resolved, and resolution should be a useful tool to enhancing communication issues and should be maintained in an open website. We also recommend using such techniques as distributing project information effectively using a dedicated resource.
Barker, A. (2000). Improve your communication skills. London: Kogan Page.
Boehm, B. W., I Abts, C., Brown, A.W., Chulani, S., Clark, B.K., Horowitz, E., Madachy, R.,
Reifer, D. & Steece, C. (2000). Software cost estimation with COCOMOII. Upper Saddle River, NJ: Prentice Hall.
Chelariu, C., Johnston, W. J., & Young, L. (2002). Learning to improvise, improvising to learn: A process of responding to complex environments. Journal of Business Research, 55(1), 141-147.
Cicmil, S., & Hodgson, D. (2006). New possibilities for project management theory: A critical engagement. Project Management Journal, 37(3), 111-122.
Cooke-Davies, T., Cicmil, S., Crawford, L., & Richardson, K. (2007). We’re not in Kansas anymore, Toto: Mapping the strange landscape of complexity theory, and its relationship to project management. Project Management Journal, 38(2), 50-61.
Cunha, e M. P., Cunha, da J. V., & Kamoche, K. (1999). Organizational improvisation: What, when, how and why. International Journal of Management Reviews, (1), 299-341.
Davis, M., Fanning, P. & McKay, M. (1997) How to Communicate: The Ultimate Guide to Improving Your Personal and Professional Relationships MJF Books
Dignen, B. (2010). Teaching Virtual Communication Skills. Retrieved June 19, 2010, from Professional English Online: http://peo.cambridge.org/index.php?option=com_content&view=article&id=189:teaching-virtual-communication-skills-by-bob-dignan&catid=3:blog&Item=2.
Down, W., & Taylor, B. (2008). Project management communications. Indianapollis, IN: Wiley Publishing.
Fleming, Q., & Koppelman, J. (2005). Earned value project management. Newtown Square, PA: Project Management Institute (PMI).
Gallo, M. & Gardiner, P.D. (2007). Triggers to a flexible approach to project management within U.K. financial services. International Journal of Project Management, 25(5), 446-456.
Goleman, A. (1998). Working with emotional intelligence. New York, NY: Random House/Bantam.
Group, S. (1995). Chaos report. The Standish Group Report.
Hass, K. (2010). Managing complex projects. Retrieved July 15, 2010, from Project Times: http://www.projecttimes.com/articles/managing-complex-projects-part-1.html.
Hass, K. (2010). Managing complex projects that are too large, too long and too costly. Retrieved July 1, 2010, from http://www.projecttimes.com: http://www.projecttimes.com/articles/managing-complex-projects-that-are-too-large-too-long-and-too-costly.html.
IT Cortex. (n.d.). Failure causes statistics. Retrieved July 18, 2010, from IT Coretex.com: http://www.it-cortex.com/Stat_Failure_Cause.htm.
Kanabar, V., & Warburtron, R. D. (2008). MBA fundamentals project management. New York: Kaplan Publishing.
Kendrick, T. (2004). The project management tool kit. New York, NY: AMACOM.
Leach, L. (2005). Critical chain project management. Norwood, MA: Artech House.
Leybourne, S. A. (2002). Project management and the implementation of strategic change within the U.K. financial services sector. Unpublished Doctoral Dissertation – University of Wales/Cardiff Business School.
Leybourne, S. A. (2006a). Managing improvisation within change management: Lessons from U.K. financial services. Service Industries Journal, 26(1), 73-95.
Leybourne, S. A. (2006b). Managing change by abandoning, planning and embracing improvisation. Journal of General Management, 31(3), 11-29.
Leybourne, S. A. (2006c). Improvisation within the project management of strategic change: Some observations from U.K. financial services. Journal of Change Management, 6(4), 365-381.
Leybourne, S. A. (2007). The changing bias of project management research: A consideration of the literatures and an application of extant theory. Project Management Journal, 38(1), 61-73.
Leybourne, S. A., & Sadler-Smith, E. (2006). Going-with-your-gut: The role of intuition and improvisation in project management. Inernational Journal of Project Management, 24(6), 483-492.
Stacey, R.D. (1996). Complexity, creativity and management. San Francisco, CA: Berrett-Koehler
Stacey, R. D. (2001). Complex responsive processes in organizations: Learning and knowledge creation. London: Routledge.
Warburton R. & Greiman G. (2009, October) Deconstructing the Big Dig: Best Practices for Mega Project Cost Estimating, PMI Global Congress 2009 – Orlando, FL
Wikipedia. (2005, April). Boston English. Retrieved July 12, 2010, from Wikipedia : http://en.wikipedia.org/wiki/Boston_English.
©2010, Leybourne, Kanabar & Warburton
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC