Project Management Myths – Top Five

As humans, we generally have many preconceived notions regarding aspects of our day-to-day lives. Periodically, we inject some form of personal bias into some of our key decisions. That bias can be benign or based on some loose understanding of the key fundamentals of whatever we are working on. In other cases, the bias can actually lead the individual down the completely wrong path since the bias was based on pieces of information that were fundamentally flawed or outright false.

This is of course, certainly true within the project management space. There are some key ‘myths’ that have been percolating that need some debunking, and they are itemized as follows:

Myth # 1. Planning is a waste of time and leads to too much bureaucracy

This is a pretty common fallacy amongst many organizations, especially those that pride themselves as being more dynamic or following the mantra of ‘disruptive innovation’. Don’t think about it, just do it! Well, as one takes a step back, the absurdity of this myth becomes more obvious. Does anyone actually conduct their day-to-day lives that way? If you are renovating your home, do you just ‘do it’? Is a major car purchase just done on a whim? (Well, sometimes!) But the reason this myth has become so pervasive is because individuals often find the planning phase as being too long and too bureaucratic. And while that can be the case, it does not in any way invalidate the planning itself. All important projects need some level of upfront planning. How much or how little is to the discretion of the team. But to simply discard the idea of planning all together is a recipe for problems with the project downstream.

Myth # 2. Project estimates have to be exact

I’ve seen some project managers bring out unbelievably complex math and formulas for project estimations. The kind of formulas that would make Sir Isaac Newton scratch his head. Now while it is true that the accuracy of a project estimate is important, anyone who has spent even five minutes in the project management space recognizes that it is certainly not an exact science. More often than not, estimates are the aggregate of opinions of the senior team members on the project. And like any opinion, they will not always be based on sound logic. There is also the notion of ‘anchoring’, where a previously used estimate was used frequently and the team members generally gravitate towards that number regardless of the task itself. In any sense, project estimates are just that: ESTIMATES.

Myth # 3. You don’t need a Project Charter

In a previous post, I discussed the project charter and its inherent value to the overall project plan. (For reference, please read the post: The Project Charter) The Project Charter is essentially the ‘what’ with regards to the project; i.e. what exactly are we doing or building? Now while it may seem somewhat redundant or maybe even un-necessary, project managers often discover the hard way that not everyone is always glued into what exactly is being created. Expectations about what will be part of the project can vary widely amongst team members, stakeholders and the project manager. Without an upfront document specifically outlining what EXACTLY is being worked on, situations can arise where a project is nearing completion and everyone discovers they are not on the same page with regards to what was done. Needless to say, this can be very disruptive and leads to lost time, wasted effort and burned money in certain situations. Defining the project charter up front can avoid this kind of situation and as such, time should be spent on its creation.

Myth # 4. There is no need to perform a Risk Assessment

Risks are naturally difficult to define. No one has a crystal ball. For that reason, the whole notion of performing an upfront risk assessment is often simply overlooked by the project manager. But this can have far-reaching ramifications down the road and lead to situations where problems that could have been avoided manifest themselves. Now while risks themselves are difficult to define, it is by no means an impossible task. Certain risks are actually pretty self-evident for certain project types. (resource constraints, budget, etc) So regardless of the project, some amount of time should be spent on performing some level of risk analysis. Often times, an effective and fun way to achieve this is to perform a brainstorming session with the team itself and the stakeholders. Getting the idea juices flowing with regards to project risks can at least allow the project manager to itemize them. Even if not all risks can be dealt with of have an action plan associated with them, at least being aware of their potential is half the battle. (For further reading, please consult the post: Project Risk Management)

Myth # 5. Never add scope once the project is underway

There are certain project managers that take a very firm stance when it comes to scope creep. In many cases, they will state that all features should be itemized up front and additional changes should not be sanctioned. For that reason, scope should not be added during a project’s implementation phase as it will be disruptive. Good idea in principle, bad idea in practice. It’s simply a fact of life that scope may need to be re-visited for any project. Design changes, market changes, resource changes and copious other factors will affect the scope of any project. Now while the project manager is meant to be the gatekeeper when it comes to scope changes, they should not be dealing in absolutes. Declining a change in scope can actually affect the project more than adding it would have, such as in cases where a key customer wanted a particular feature. And not receiving that feature caused them to go with another vendor. That is money lost for the company. So while being diligent about scope is important, some degree of latitude is always necessary.

Advertisements

About tomtsongas
Versatile Program/Development Manager with 20 years of diverse background and experience in managing, defining, designing, developing and evangelizing advanced software applications that exceed customer expectations Current responsibilities include: - Coordinating and monitoring the scheduling and technical performance of company programs - Preparation of proposals, plans, specifications, and finalized requirements of various projects - Researching new opportunities and technologies - Ensuring adherence to master plans and schedules - Developing solutions to program problems - Directing work of incumbents assigned to program from various departments while also ensuring projects are completed on time and within budget - Acting as adviser to program teams regarding projects, tasks, and operations.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: