Imagine you have the ability to set the project stage for its execution however you want! What would you set up? What would you ask? Would you even know what you truly wanted or needed to better ensure your project success? In presentations that I have given, in classes that I have taught, and to project managers that I currently lead, my message is always the same: project management is hard. Arguably, it is among the most difficult knowledge professions an individual can pursue. The difficulty stems from a variety of factors with some being in our control and some, not so much. So, back to my question, what would you do if you could create a project environment however you wanted? This white paper and accompanying presentation attempts to answer this question by describing seven conditions that, when present, help to create project environments for teams to thrive in.
Introduction
Thamhain said, “…virtually every organization in our fiercely competitive business environment is under pressure to do more things, faster, better, and cheaper.” (2014, p. 280). In response to this pressure, executives are looking to project teams to rapidly alter business capability, increase revenue generation, and/or drive out costs to maintain operating margins and overall profitability. More than ever, projects are coming to the forefront and with that, project teams are increasingly being put into the spotlight to execute. And yet, project management remains stubbornly hard to successfully perform. Really hard. From my own personal experience as a project and program manager, from managing project managers as a PMO lead, or through the students I have met while instructing, the message is the same: project management is difficult. The reasons vary and include:
- The dependence on other people who must come together from different walks of life to collaboratively work on a commitment together;
- Sponsors whose agendas may change with or without communication to the project;
- Customers that really aren't sure what they want, even if they say and think they do;
- Business environments that rapidly change, thereby forcing organizations to quickly expand and contract their project portfolios; and
- The complexity of today's systems that make-up projects, albeit the underlying computer technologies, the infrastructure of construction, and/or the intricate dependencies and liabilities that make up pharmaceuticals.
From the research and publication in the industry, as well as the collective experiences personally aggregated or assembled from project managers directly managed or instructed, I put forward a list of conditions that can positively create environments for project teams to thrive. These conditions are domain-agnostic and readily applicable to projects, regardless of them being information technology, construction, transportation, banking, or any other application area. In addition, these concepts apply to projects of all sizes, whether they are US$100,000 or tens of millions in total project budget. While the intensity in which the condition is employed may vary, the underlying concept does not.
It needs to be pointed out that this is not meant to be an all-inclusive list, nor are these conditions a guarantee of project success. Scores of other considerations, some within and some outside of the control of the project manager quickly come into play and will ultimately determine the success of the project. This paper is meant to describe, along with specific characteristics, seven critical conditions that improve and create an environment for project teams to thrive. For each of the conditions listed, the following objectives are intended for the project leader.
Exhibit 1: Objectives by condition.
Projects are More Than the Project Manager–Team Composition
A project will only be as successful as the team that has been assembled to deliver it. While a strong project manager can help to reduce the impacts of an inexperienced or less capable team, there is a limit to what can be done. An old project management adage is that a strong team can support a weak or inexperienced project manager, but a strong project manager cannot support a weak team. This makes it all the more important for the right resources to be secured for the project's activities. When building the project's resource breakdown structure, it is vital to identify the roles, capabilities, and skills necessary to complete the various activities. This alternatives analysis may result in trade-offs that the project management team must decide are in the best interest of the project. Regardless, thriving teams recognize it is a mistake to simply look for “a pair of hands” to bring on to the project. They know the extra pair of hands comes with a “management tax” that includes additional oversight, care-and-feeding, re-work, and, in some cases, replacement. In fact, “Teams that are hastily organized with people who are poorly matched to the job requirements are frequently subject to conflicts, low morale, suboptimum decision making, and ultimately, poor project performance” (Thamhain, 2014, p. 436).
In productive environments, due care and attention is completed to ensure the most appropriate resources are selected to join the project team. This involves appropriate representation from the end user community, the sustainment organization (often referred to as operations), and subject matter experts that are only to be brought on for the duration of, or portions of, the project. Including members of the project team, and other relevant stakeholders in the resource selection process will reduce the chance of bringing on an inappropriately skilled individual or someone that simply does not fit with the rest. An additional benefit is that this joint-decision making approach increases the buy-in of the entire team and can serve to be a team-building activity unto itself.
Equally important is that the project manager needs to have an active voice in declining resources that may be detrimental to the project performance. This may be attributed to individuals that don't mesh well with the others or that are inadequately skilled to a point that it detracts from a performing team's culture and execution. Accepting a less desirable resource will serve to hurt the project manager's credibility with the project team or impair project performance or both.
A common and very beneficial tactic for staffing a project is the secondment of key individuals from either the end user and/or operational communities. In these arrangements, an individual with the requisite influence, capability, and respect from a stakeholder domain is selected to represent those needs within the project. During their project engagement, the individual balances the perspectives of the two worlds that they now represent. At the end of their project tenure, the individual is expected to return to the host organization, either in their previous work capacity or something similar. They continually bring forward the needs of their stakeholder group while also representing the project needs back to that very same group. While effective, there is considerable pressure and challenge placed on the individual to equally balance these competing demands. This pressure manifests itself in being in a semi-constant state of conflict as the person must represent opinions and arguments to both stakeholder groups. As well, there is uncertainty about what their role will be once their project involvement draws to a close and how they will be evaluated and measured during their project engagement. To reduce this stress and reinforce that there is a “life after the project,” the individual's work performance evaluation should be directly tied to their performance on the project.
When using secondments, the project manager needs to be aware of various considerations that affect the individual and, therefore, can affect the team. First, is the fact that seconding resources frequently involves a significant transition for the individual. The individual is thrust into the project world from a world where they understand the day-to-day workings and routine interactions. The operating norms and culture of their old world are seldom consistent with the norms and heightened sense of urgency that is found within project environments. This shift needs to be supported and observed by the project manager to minimize the “storming” phase made famous by Tuckman. Continued assurances need to be validated and communicated to the individual that they have a “home” to return to after the project. If not, the project manager needs to acknowledge the potential for a lower performance due to the individual being distracted.
Organizational Stability–A Foundation for the Project
Regardless of application area, most projects of size will almost certainly span multiple years. And, while the project is running through its life cycle, the sponsoring organization is likely changing underneath the project manager's feet. Examples of these changes include, but are not limited to, changing sponsors, shifts in organizational strategy in response to “evolving” economics, replacement of delivery methodologies, downsizing of the workforce, and updates to the preferred vendors available to project teams. Notwithstanding this tumultuous period of change, the sponsoring organization still expects its projects to be delivered to the scope, schedule, and budget that they were committed.
Project teams perform best during periods of stability when accountabilities are understood, goals and strategies remain constant, and expectations are clear. For projects that don't have these luxuries, the project manager needs to perform extra steps to “mimic” this stability to his/her project team. This can be best accomplished by ensuring that the goals of the project are clear at the outset of the project lifecycle. Thereafter, the project manager should take strides to ensure that stakeholder groups are continually reminded of these goals at every logical opportunity, such as steering committee meetings, town hall events, organizational publications, etc. Such activities will serve to create a corporate memory that can be used to provide a stabilizing force during periods of change. Inclusive of this would be painting the journey as the project proceeds. This translates to documenting successes, such as delivering to plan, as well as the challenges encountered and how the team overcame them. This underscores a central project management theme of striving to deliver “something” as soon as possible. Quick delivery will increase the creditability of the project team, while the early time to value approach will enhance the return back to the organization. This allows the project team to ensure the organization is kept abreast of why the project was initiated, as well as allowing for continued alignment to strategic objectives.
In addition, the project team should ensure that its interfaces with key stakeholder groups, both internal and external to the organization, are established, documented, and kept current. This allows the project team to maintain continuity with other functional teams and vendors throughout the project life cycle.
Finally, and similar to any other organization, the project manager should make efforts to plan for the turnover/succession of key resources within the project. Proactive planning of resource departures will increase the stability of the project and reduce disruptions to project velocity. While never simple, a project manager can create a succession plan of key resources based on the criticality of the resource's departure on the project; especially at certain periods of time within the project lifecycle. The project manager should also look to early identification of potential flight risks based on the resource's ambition, perceived capability for the tasks, and historical turnover nature of the role. Examples of high turnover roles would consist of document control personnel, help desk staff, uniquely skilled roles, etc.
Sponsorship Awareness
Without question, one of the most important, if not the most important, stakeholders is that of the project sponsor. Without the project champion, quite simply, there would be no project to execute. The sponsor is normally highly influential within the host organization; they are respected, and should be a critical advocate of the project manager and his/her team. By definition, "… the sponsor normally functions in an active role, which includes such activities as:
- Assisting the project manager in establishing the correct objectives for the project;
- Providing the project manager with information on the environmental/political factors that could include the project's execution;
- Establishing the priority for the project (either individually or through consultation with other executives) and informing the project manager of the established priority and reason for the priority;
- Providing guidance for the establishment of policies and procedures by which to govern the project; and
- Functioning as the executive-client contact point" (Kerzner, 2003, p. 354).
Project teams that experience high degrees of project performance have a sponsor that performs many of the activities that Dr. Kerzner has outlined. In addition, the sponsor must have insight into the organizational situational awareness for the project. This translates to understanding and communicating what the project objectives are and how those outcomes align to organizational strategies and roadmaps. This provides the project team with the information to confidently represent the goals to the various project stakeholders throughout the lifecycle. It also serves to unify the project team behind the sponsor's vision and form the guiding basis for making decisions later.
It is essential for the project sponsor to understand the project life cycle and the work that is required to successfully move a project from initiation to close out. In other words, the concept of progressive elaboration is recognized and project details are not demanded prior to the project team having the time to perform the necessary due diligence in assembling the answer. In thriving environments, project managers do not defend the necessity of proper planning and the use of milestones to mark increasingly detailed information. Furthermore, the high-performing environments have the sponsor recognize the accomplishments obtained by the project team and help to celebrate those successes. This is motivating and provides assurances to the team that the sponsor is an active participant in the journey.
As mentioned by Kerzner, the sponsor is expected to provide the project manager with information and resources to navigate hotspots and political headwinds within the company. Given the fact that projects drive change into organizations and typically span years in duration, it is almost a certainty that projects will venture into political waters. Project managers, contract or full time, are ill-equipped to deal with these turbulences without assistance from the sponsor. This assistance may come in form of funding, strategic prioritization when the project competes for resources, and mentorship in positioning the project to other influential stakeholders.
Similar to the fact that the project manager cannot be expected to know what they don't know, the sponsor may not necessarily be aware of the headwinds that the project is encountering. This underscores the important nature of the relationship between with the sponsor and project manager. The project manager needs to be able to ask for specific assistance when resistance is encountered that is beyond the project team to address. Engaged sponsors will provide feedback on the request and, if necessary, action the response to re-establish the project momentum.
Accountability
Merriam-Webster defines accountability as “an obligation or willingness to accept responsibility or to account for one's actions.” (http://www.merriam-webster.com/dictionary/accountability). For anyone that has ever been a project manager or been required to rely upon others for their day-to-day work, “accountability” takes on a very special meaning; and it's not always a positive perspective. In thriving environments, the term “accountability” describes the standard operating procedure of the project team and the word itself is rarely used or needed to be used. Groups and individuals willingly take on the tasks and activities that belong to them. Mistakes and delays, when they occur, are communicated early and without fear of undeserved reprimand or the need for deflection. Individuals that are dependent on others have a trust that the work will be completed to the quality required and within the constraints of schedule and budget that were agreed upon. Further, rather than saying yes to work that they know they do not have the capacity/capability to complete, individuals will request assistance or be comfortable in saying “no.” The project manager, in turn, will not punish the individual for this honesty, but instead work with the individual to develop alternatives or other means of closing the gap.
Regardless of whether the project team is inherited or selected at outset, some project managers passively accept the culture that develops. Proactive project leaders will, instead, attempt to shape their team toward an accountability-driven philosophy. While this may look to be altruistic, the rationale may be more self-serving than what is on the surface. Bad luck news can usually be managed quite effectively if given enough notice to react. Being informed of a missed deliverable immediately before a deadline does not provide the project manager with many options to course-correct or develop alternatives; however, an early warning of a possible delay earlier would allow for many different paths of remediation; the gift of time. In other words, a project manager is well served by having a team dynamic that is open and honest with information, even if the news is negative. So, the demanding investment of creating a team culture whose centerpiece is accountability will reap rewards to the project manager in the form of providing him/her with news early enough so that issues can be managed.
Creating an accountability-driven team requires a significant and continuous investment by the entire project team. This is made more difficult by the fact that accountability is not something that can be forced or dictated. A project manager cannot say to his/her team, “be accountable” and reasonably expect them to magically become accountable. Instead, this philosophy needs to be nurtured, demonstrated, and reinforced. This begins with the project manager being accountable to himself/herself and by being open and honest with the team including:
- Calling out individuals that are not fulfilling their obligations;
- Acknowledging and advocating those that do execute to the desired standard;
- Visibly demonstrate that they will hold the team accountable to the previously made commitments; and
- Delivering on the promises they have made.
To do this, the project manager must regularly seek updates and, when there are slippages, bravely and professionally confront the situation to determine the root cause. The accountable project manager doesn't do this with the intention of punishing. Instead, the intent and actions that follow are centered on achieving a better understanding and arriving at alternatives to allow for performance results to come in as expected.
As part of the nurturing of an accountable culture in the project team, there are a several practices that become routine. This is achievable since “…performers also want others to be held accountable. They thrive in an environment where they know that everyone is expected to step up and be responsible, where they can trust that slackers and poor performers won't just slip by” (Covey, 2006, p. 203). This is a concept known as social loafing and needs to be monitored by the project manager. “Social loafing is the tendency of individuals to expend less effort when working collectively than when working individually” (Langton, 2013, p. 174). To reinforce accountability and minimize social loafing, an individual's accountability should be made to align to the needs and deliverables of others. Generally speaking, a person's accountability is heightened when they understand that others cannot complete their work efforts without their items being included. As a part of this, obligations, especially decisive ones, should be specific, written, and with an acknowledgment of the receiver. Specificity removes assumptions and doubts about the commitment, such as who is doing it, when it is due, implications of not being completed, etc. Having the commitment in writing promotes completion by eliminating a “convenient” or “short” memory from being used employed. Finally, having the receiver acknowledge the responsibility they have willingly undertaken. This provides assurance that there is an understanding and willingness to perform the duty. “In truth, people respond to accountability—particularly the performers. The want to be held accountable. They feel trust grow with bosses, leaders, team members, peers, and other stakeholders as they are given the opportunity to account for performing well” (Covey, 2006, p. 203).
Comprehensive Organizational Process Assets
Breaking a brand new trail in a forest or jungle is very, very hard work. It involves route indecision, considerable and constant laborious efforts, and re-work due to inevitable backtracking. The same may be said for developing a process for delivering a project, while trying to actually deliver the project. A common cliché to this attempted effort is, “like trying to change a tire on a bus while it's moving.” For all the processes (47) that make up PMI's project management framework, as discussed in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (PMI, 2013), project momentum is significantly reduced when the project team needs to first develop the process before using it; with some processes impacting objectives more than others. To this end, project teams become increasingly more efficient, thereby enhancing probabilities of success, in surroundings where they can focus more on executing the processes versus creating/developing them. This introduces the concept of identifying, making available, and leveraging the organizational process assets for a project. These assets are, typically, meant to facilitate faster project ramp-up, as well as avoiding risks and pitfalls that become detractions from project objectives.
What, specifically, do these assets provide to enable project teams to operate at higher levels of performance? They supply clear processes, accountabilities, stakeholder discovery, tools and templates, advice, historical references, and mentorship to project teams throughout the project lifecycle. “They [organizational process assets] include any artifact, practice, or knowledge from any or all of the organizations involved in the project that can be used to perform or govern the project” (Project Management Institute, 2013, p. 27). These assets often describe the “how and who” to a process, which eliminates the need for the project manager to figure it out for himself. Knowing the rules and guidelines allows the project to, instead, focus on the activities to complete the process.
When employing assets toward the project, the governing organization and the project team should define how to adapt and tailor the processes to the project. The goal is to allow the “fast to go fast,” while adequately managing the risk and oversight for the larger, more complicated projects. Examples of this include, but are not limited to:
- Adjusting the number of and frequency of the stage gates required for a project;
- Deliberate adjustment to the intensity required of project artifacts; and
- The stakeholder discovery, as prescribed by a methodology and/or artifact, is more abbreviated for simpler, less risky projects.
Clarity of “The What”
As an industry, and within the Project Management Institute (PMI) itself, there has been increased emphasis in confirming that there is an accurate understanding of what the project is trying to accomplish. This is evidenced by:
- PMI, in 2014, reported: “Inaccurate requirements gathering was reported by 37% of organizations as a primary cause of project failure” (2014 Pulse of the Profession® Report, Project Management Institute, 2014, p. 2).
- PMI, in 2014, reported: “Poor requirements management practices are the second meeting cause of project failure, second only to changing organization priorities” (2014 Pulse of the Profession® Report, Project Management Institute, 2014, p. 2).
- The creation of the PMI Requirements Management community of practice.
- The addition of the Collect Requirements Process in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition (Project Management Institute, 2008).
- The addition of the Stakeholder Management Knowledge Area in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (Project Management Institute, 2013).
- Requirements originate and evolve with the project stakeholders.
- The recent release of the PMI Business Analysis for Practitioners Practice Guide and,
- The scores of literature being published on scope management in agile-based projects.
Not surprising, the PMBOK® Guide – Fifth Edition has very strong language about the importance of the early capture of requirements in the project, “The project’s success is directly influenced by active stakeholder involvement in the discovery and decomposition of need into requirements and by the care taken in determining, documenting, and managing the requirements of the product, service, or result of the project… Requirements become the foundation of the WBS. Cost, schedule, quality planning, and sometimes procurement are all based on these requirements,” (Project Management Institute, 2013, p. 112).
Notwithstanding the groundswell of attention, it remains alarming how often project teams cannot accurately articulate what the project is attempting to achieve, regardless of its position in the project lifecycle. Quite obviously, some uncertainty is to be expected (and defended) in the early phases of the project. However, the closer toward the project close out, the more vital it is that the project team and sponsorship be unified in terms of what all the outcomes are to be expected and how they will be measured.
When project teams are succeeding, there is an understanding of the detail that is expected of the requirements and scope. Projects early in the project lifecycle may not yet have all the deliverables and associated requirements defined to low levels of specificity and measurements. In contrast, projects entering the construction/build phase have a very clear understanding of what the requirements are, the quality to which they need to be produced, and how they will be successfully measured; more so, the project team's understanding of the importance of stakeholder identification and the role those stakeholders contribute to the creation of the project’s scope. As an extension, the team is also aware of the consequences of introducing new stakeholders and requirements into the project later in the project lifecycle. While this may occur and be necessary, it is considerably more expensive than early identification of the stakeholders and their associate needs.
One unique circumstance that is worth highlighting is dealing with innovation or R&D-style projects. In these projects, the ability to derive requirement clarity of the product, service, or result may be difficult, if not impossible. In these circumstances, the scope of the project may be, in actual fact, the development of a prioritized requirement specification for later implementation by another project. With this understanding articulated at the outset, and the project’s objectives clearly understood, this approach is perfectly acceptable and used frequently; the scope of the project becomes identifying the requirements of the product, service, or result.
Deciding How to Decide
Effective environments for project teams have a clear and transparent decision-making framework that is established early in the project life cycle. How soon should the framework and supporting structures be set up? Put simply, they need to be established before an actual decision of consequence needs to be made, especially when the integrity and objectivity of the decision needs to be safeguarded against stakeholder biases and “evolving agendas.” The analogy would be similar to trying to create a contract after a conflict has already started. Project environments without a decision-making structure are recognizable, as the time to arrive at directions are lengthier; there is repeated confusion about who to engage and who should participate in the decision; decisions are continually re-visited; decisions are made by individuals without the necessary authority; there is increased re-work; and, ironically enough, it takes considerably longer to arrive at a decision. Once established, the process should be published and communicated to the project team as often as necessary. In the best of all possible environments, all members of the core project team and sponsorship understand how decisions are made, who has the authority to make the decision, and the steps necessary to arrive at the decision and the communication outwards.
Ideally, the decision-making apparatus should be tested early in the project lifecycle with a series of relatively small-consequence decisions. This is done to ensure that the key participants are aware of and support the process. The project manager should expect that decisions, which are brought to an authoritative individual are supported, encouraged, and responded to in a prompt fashion. Even more important, decisions that the project team has been previously empowered to make should be pushed back to the project team for determination. Of course, the same construct should be established within the project team. In other words, a project manager should push decisions down to members of his/her team that have the correct authority. Once made, and unless truly warranted, decisions that have been made by the correct individuals should be acknowledged and respected by the project, including leadership and sponsorship. Overruling those decisions should only be done when necessary with the rationale provided for future decisions. Each time an individual’s decision is vetoed there is a loss of credibility to both the individual and the integrity of the decision-making framework. So, while sponsors and project managers have considerable authority within projects, they should exercise caution when reversing decisions made by their teams. Unquestionably, the general rules of decision making still apply and should be adhered to. This equates to decisions being documents, signed off (as required), communicated outward, and tested for understanding. In addition, the project manager/team needs to follow up with the appropriate individuals to ensure that the outcomes of the decision are being acted upon and/or implemented.
Conclusion–The Underlying Themes to These Conditions
For many individuals, part of the excitement and draw to the project management profession is the novelty that it brings. With each project, there is an excitement of uncertainty that comes with it being initiated. A project manager is faced with a series of outcomes and must create a plan to accomplish this. At the outset, there is a tremendous amount of uncertainty and the project manager, along with his/her team, will replace that uncertainty with plans and artifacts that continually shape the end result. This is one of the central themes of project management and a key underpinning to the seven conditions that have been presented in this paper. These conditions provide real-world scenario analysis and examples for discussion, as well as recommending courses of action. Each condition is a means by which the project manager will transform uncertainty into a firm commitment that can be safely executed upon. Difficult conversations, circumstances, people, and decisions can all be effectively managed with more certainty. While not everything can be moved from uncertainty to certainty, there is more that can be done than many individuals realize. Some project managers don’t drive to this certainty due to not appreciating the importance of properly establishing the project framework(s); perceptions of not having the “authority” to do so (or being afraid it will cost them their job); being too busy doing status reports; or a host of other reasons. From experience, allowing uncertainty to needlessly persist will only hurt the project manager and the project team in the long run.
As indicated in the introduction, project teams operate in a world of complexity that can be mind-numbing. Technologies, solution density compounded with multitudes of alternatives, evolving legislations, and corporate process matrices are forever changing with the expectation that project teams can readily adapt to all to create a world that is Toffler-eseque in complexity. For project managers, the instinct should be to pursue the simplest path forward possible. Occam’s Razor, a problem solving principle, states that all things being equal, the simplest path forward is the best path forward. The conditions described above are all meant to create paths toward the principle of simplicity over complexity. They are meant to cut through the noise and clutter and help to ensure the project team is focused on what matters most in the most efficient manner possible; successful realization of the project objectives.
Exhibit 2: Antoine de Saint-Exupery.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” (Antoine de Saint-Exupery, http://izquotes.com/quote/161512)
