Ten Project Management Myths

Projects are complicated, which is why an evidence based project management methodology (PMBOK, 2013) is so useful. This method, if used in its entirety, almost gives off the impression of being seamless and ‘air tight’; considering almost every angle, roadblock, and issue that could possibly surface during a project. This might be true from a technical standpoint, but for the sake of argument let’s propose that experience, knowledge, and the ‘great next idea’ makes the  difference between a ‘bad project’ and a ‘great project.’ Success is not just measured whether a strategy realizes what it intends but whether or not it delivers value for the company and the customer.

Distinguishing between fact and fiction in project management case examples becomes increasingly difficult as one recognizes that the project management method represents a normative architecture for:

• Initiating
• Planning
• Executing
• Monitoring & Controlling, and
• Closing….projects.

Things rarely roll out as planned and projects are no exception. The maxim to ‘plan the work, and work the plan’ is no longer enough to guarantee success. Project environments are constantly changing and their founding ideas and stakeholders are not all equal. Distinguishing between fact and fiction when reviewing the project management literature (and case examples) is not so much about proving the method false but to confirm that this ‘exhaustive system’ is not actually as complete as it first appears.

The following Ten Project Management Myths give a peek into the complex world of project planning, execution, and management.

1. Project Management Methodology will guarantee all projects are a great success: There are many case examples of project failures that are evaluated post hoc only to ‘discover’ that several PMBOK strategies were executed poorly (if at all). The impression that the literature leaves is that the project management method will guarantee the success of any idea as long as the tools are used appropriately.

The truth is that some ideas have no customers. Without customers there is no profit. And without profit there is no sustainability. A project that is unable to deliver value for the business, and its customers, should not be evaluated as a success. The phrase should more accurately reflect that project management method increases the success rate for effective and legitimate ideas.

2. Once the goals and requirements are drafted in the Project Charter no further ‘selling of the idea’ is needed: Project stakeholders and sponsors are engaged during the charter review and requirements development phases. This can leave some team members with the impression that the project’s ‘business case’ has been bought-and sold, and no more selling is needed.

The truth is that new stakeholders will surface as the project is implemented, and stakeholder engagement will similarly change. Competition in industries also changes the business landscape in which projects are executed, with changing requirements, stakeholder needs, and project priorities changing as a result. New stakeholders will need to be ‘caught up to date’ with the current status’ of the project.

3. Once project sponsors are assigned no other champions are necessary: Project Sponsors are identified earlier and during the initiation stages of the project to help prove the project ‘business case’ and confirm the project requirements. The central nature of this role explains why the PMBOK references the project sponsor’s role so many times in the manual. Their role also involves evaluating change management requests and determining how to discuss risks as they surface.

The truth is that, in practice, not all project sponsors (or owners) are equal. Subject matter expertise, availability, and leadership/engagement styles influence the quality and impact of the project sponsor’s role. An effective project sponsor is someone to be honoured and treasured, as not all sponsors will remain actively (or effectively) engaged in the project. The latter characteristics impact project metrics and performance which often falls on the project manager to resolve. Project roles evolve over the life-cycle of most projects.

4. When there’s a will, there’s a way: Everyone has experienced working in a business or project setting where almost ‘herculean’ efforts were required from a few members of the team to complete the project on time, on budget, on schedule, and per the project requirements. Volunteer models depend on these heroic efforts but this should not be required to guarantee your project’s completion.

Disengaged project sponsors, members, and external stakeholders may show that the project has run ‘off track.’ If this isn’t the case it may at least show that the process and strategies used to deliver on the project missed opportunities for more stakeholder engagement. The project’s market, audience, and customer reach may be smaller as a result as these process and strategy requirements are missed.

5. Relationships are everything: Project relationships and roles represent two of the most important resources. Relationships help set up momentum and engagement, and roles confirm expertise and the scope of responsibility throughout the project life-cycle. Requirements are also identified and evaluated with the use of this knowledge, insuring that project processes and strategies are aligned.

The truth is that not all relationships are equal. As roles change and priorities shift the project manager is required to keep up focus on the original (and evolving) project requirements. Failure to do so can result in dissatisfied customers and unpaid project invoices. Some relationships can limit, if not derail, a project from its intended goals.

6. Love will set us free (i.e., conflict is unhealthy): The project culture needs to discuss the priorities, needs, and preferences of all stakeholders involved. The project’s culture, and the environment in which the project is implemented, influences stakeholder engagement, project momentum and alignment of the tools and processes used and must be considered with every decision.

But this does not mean that conflict is unhealthy. The truth is the likelihood of conflict increases with project scope and complexity. This also is more likely to occur with less experienced teams or when the attention to planning is lacking. Avoiding conflict will likely impact the scope, quality, cost, and schedule of the project.

7. One size fits all: Commercial off the Shelf (COTS) packages have becoming increasingly popular in the business market. Informed by industry standards these Commercial off the Shelf (COTS) packages often save time and money by avoiding the need to design and build from scratch. In many respects, the project management method represents a COTS package; when used wisely this method can improve your company’s performance on key projects.

But this does not mean that the same project management components are used for every project, or that every project performs in the same way. Utilizing the five project management process groups the team explores the stakeholder AND project requirements to require what tools are needed. This includes whether to use a waterfall or agile approach to project planning (and scheduling) as well as deciding how much authority is delegated to the project roles. Although change management process should be handled according to the sequence depicted in the PMBOK (2013), deciding what types of change requests can be resolved at lower (vs higher) levels is determined by each project team and environment. Understanding the project team’s capabilities and the project culture becomes crucial towards identifying best practices for each environment.

8. Project delivery methods are usually selected objectively: Identifying the best practices for forming a company’s project management office begins by engaging subject matter experts and participating in available training. The next step is to standardize the tools used by the company’s PMO and insure the templates, processes, and rules are consistent. These are communicated to future project stakeholders to insure alignment and guide efforts throughout the project life-cycle.

But this does not necessarily mean that tools are selected objectively (or that planning documents will actually be reviewed and referenced by project sponsors, owners, and stakeholders). The truth is that project tools are often selected based on traditions and experience of the project team. The choice of project tools is similarly limited based on the company’s expectations, resources, and commitment. The time and costs needed to manage an increasing list of processes and tools is also emphasized during the selection process; with risks increasing as the project process and tool selection efforts focus on simplification and efficiency.

Tools and processes need to emphasize project and stakeholder requirements. If there is push back the company’s commitment to the project requirements, project management method, and goals should be reevaluated.

9. Capability = performance: The choice of project team members emphasizes ability, experiences, and knowledge. These competencies can make a big difference during the initiation and planning stages; setting the tone, pace, and direction for the rest of the project.

But capability does not necessarily determine project performance. Other factors influence the project (and team members) performance such as availability, commitment, and buy-in. Project member identification also needs to take into consideration value and goal alignment when building the project team.

10. Risk management guarantees that risks will be addressed: A central part of effective project management involves managing the risks. This includes identifying the project risks, evaluating their impact and chance of occurring, and deciding if/how to address the risk. Performing the risk identification process at the onset of the project supports their management (and mitigation) throughout the project life-cycle.

Optimally, risks that are addressed early in the project are resolved and never surface again. But more likely the project team will find significant risks that need to be monitored and managed throughout the project life-cycle. Less experienced teams are more likely to accept specific risks, or leave them unresolved, than more experienced team members which can impact the project later on. The value of committing to effective risk management throughout the project cannot be overstated.

Effective project planning, and risk management, begins with the identification of project team members. This is followed by identification of the project processes and tools necessary to keep up focus, engagement, and alignment with the project and stakeholder requirements. Although following the exact method as explained in the project management body of knowledge (PMBOK, 2013) will not guarantee success it will improve the team’s evaluation and focus throughout the project’s life-cycle.

Part of effective project planning is evaluating whether the project is worth pursuing. This also involves identifying if the project management method is supported by the corporate culture. Taking short-cuts may drive efficiency in the beginning but will impact the project requirements, and quality, in the long-run. Do not let these project management myths limit your team’s ability to drive value for customers.

What other project management myths has your team discovered? How are they resolved?

Travis Barker, MPA GCPM

Consulting@innovatevancouver.org

http://innovatevancouver.org

http://twitter.com/innovatevan

Innovate Vancouver is a business development & consulting service and technology startup located in Vancouver, BC. Contact Innovate Vancouver to help with your new project. Innovate Vancouver also gives back to the community through business consulting services. Contact us for more details.

Resource:

A guide to the project management body of knowledge (PMBOK®ʼ guide). (2013). Newtown Square, PA: Project Management Institute.