Skip to main content

Myths, Mistakes and Assumptions

Editor’s Comments

“Don’t assume” is advice that, over the years, has been handed out by those who have “been there” to those who haven’t yet been there. It’s advice well worth considering because many of these assumptions turn into traps. In Unquestioned Assumptions: Costly Mistakes, Don Wessels discusses how assumptions, often mistaken as standard business practices, go unquestioned during project manager selection, often with very negative consequences.

Regular contributor, Chris Vandersluis, revisits a subject he’s talked about here a number of times in the past. He says they have become a fact of life for senior management and, in Dashboarding Redux, he takes a look at the different types of dashboards available and how they can provide an onscreen view of key performance indicators, with your choice of how and what to display. But, he says, beware of possible pitfalls.

Blogger Andrew Miller, questions the need for budgeting in running a project, but acknowledges that budgets are important as long as their sensibly set and approved. Mike Lecky weighs in with some thoughts on the ongoing discussion about the PMO.

If you’re reading this during ProjectWorld in Toronto, we hope you’re finding your visit rewarding and that you’ll drop by our booth to say hello. Wherever you are, we hope you find this a thought-provoking issue of Project Times and that you’ll share your thoughts with us.

Myths, Mistakes and Assumptions

Editor’s Comments

“Don’t assume” is advice that, over the years, has been handed out by those who have “been there” to those who haven’t yet been there. It’s advice well worth considering because many of these assumptions turn into traps. In Unquestioned Assumptions: Costly Mistakes, Don Wessels discusses how assumptions, often mistaken as standard business practices, go unquestioned during project manager selection, often with very negative consequences.

Regular contributor, Chris Vandersluis, revisits a subject he’s talked about here a number of times in the past. He says they have become a fact of life for senior management and, in Dashboarding Redux, he takes a look at the different types of dashboards available and how they can provide an onscreen view of key performance indicators, with your choice of how and what to display. But, he says, beware of possible pitfalls.

Blogger Andrew Miller, questions the need for budgeting in running a project, but acknowledges that budgets are important as long as their sensibly set and approved. Mike Lecky weighs in with some thoughts on the ongoing discussion about the PMO.

If you’re reading this during ProjectWorld in Toronto, we hope you’re finding your visit rewarding and that you’ll drop by our booth to say hello. Wherever you are, we hope you find this a thought-provoking issue of Project Times and that you’ll share your thoughts with us.

Unquestioned Assumptions: Costly Mistakes

Decisions about project management tend to follow a standard process. Senior management gives middle and/or upper management a project order, and mid-level people respond by quickly selecting a manager — perhaps too quickly!

It’s a process that can contain enormous consequences for any business entity. Yet all too often, upper management unwittingly falls into traps when choosing the manager and finds out much too late the wrong person is leading the charge. By that time, the project has either struggled or failed, and the company’s bottom line has taken a huge hit.

The traps here are those assumptions, the so-called standard business practices that go unquestioned during project manager selection. A better word to describe them is myths.

How Myths Become Acceptable Practices

To find the root cause of these myths, start with this supposition: project management is a paradox. On the one hand, you have senior or upper management, vowing to “think out of the box” and vehemently proclaiming “the same old ways of doing things don’t work anymore.” The paradox becomes evident when these same promises fall by the wayside as the company relies on business-as-usual methods for selecting the manager.

Consider the selection process, assuming that there is one. The focus usually falls on someone who has had previous project success or provided a strong contributing performance in a team role. However, if the company is so inundated with projects that preferred managers are unavailable, middle management may reach deeper into the mix, a choice comparable to a roll of the dice. All-stars at the team level do not always develop into capable managers, a truth constantly rediscovered by sports franchises and their counterparts in the business world.

So consider those previously unquestioned myths that have become the foundation of project management. It’s a foundation less than solid.

Myth #1: Technical Leads Are the Best Choice for Project Leadership

The origin of this precept is easily understood. Technical experts generally get the inside track for leadership of the next project because of their outstanding performance in the previous assignment, usually in a non-managerial role. After all, doesn’t it make sense to choose an analyst or technical engineer to handle a challenging and complex technical assignment? Well, yes and no. True, the manager should have the knowledge and expertise to make informed and creditable decisions, but there is still the issue of leadership, which takes more than numbers crunching or the weighing of variables.

An outstanding technician does not automatically become a top-flight project leader. That next big step depends on several objective factors, e.g. previous performance and people skills, and subjective ones such as an assessment of the candidate’s managerial potential. Such decisions take time. Unfortunately, time is rarely available in today’s overburdened corporate world. So, the decision becomes based solely on the tangible (technical) as opposed to the intangible (leadership qualities).

This is not to suggest that technical people cannot or should not be managers, but a stronger emphasis on leadership skills needs to be part of the selection evaluation if the project is to have its best chance for success.

Myth #2: The Tool Solves Everything

The tool in this case is a software program, such as Microsoft Project. There is nothing wrong with the tool when its usage conforms to its purpose, which is scheduling. This type of software is outstanding for setting and scheduling various components of a project.

Now the key: the tool is excellent as long as its use is confined to scheduling. It was never designed to cover other extremely important facets of project management, such as additional planning and modifications. When a project is modified, the changes may not conform to the tool’s structure. That doesn’t stop many managers and teams from trying to fit the wrong glass slipper on Cinderella.

“I’ve seen teams spend countless hours trying to get everything perfect in the tool and when there are changes, they spend even more time trying to make it fit,” said one frustrated consultant. “That’s not managing a project. That’s a disservice.”

Teams overly rely on the tool to the point of costly project delays. The fault is not with the tool; it’s with leadership.

Myth #3: A Training Workshop Will Produce a Successful Project Manager

Most companies understand the necessity of project manager training, but fail to realize that a three-day workshop is not the answer. Workshops are valuable, but limited. They provide the basics along with other helpful elements, but the rest is up to the individual and upper management. Unfortunately, the training rarely continues beyond this point.

Many acknowledge that classroom training isn’t all a manager needs yet companies, due to either budget or time limitations, do not provide an environment for ongoing training or learning, including real-world experience. Once again there are the usual suspects: limited funds for training, whether classroom or on-the-job; pressure from shareholders in publicly traded companies for short-term results; simultaneous projects limiting the number of quality managers available; and a management-by-objective business model that creates an environment less likely to produce experienced project managers.

Case Study: A Tiger by the Tail

Any one or more of the above myths can produce disastrous results. This was exemplified recently by the experience of an IT organization within a major health care corporation inundated with projects. Its best managers were unavailable, and the only option was to bring in consultants and less experienced staff members. To make matters worse, the IT group relied on the project tool to compensate for the absence of a skilled manager. All the elements for failure were there and the results were catastrophic. Shareholders could not have been pleased when the loss to the company was an astounding $300 million. The corporation’s stock took a huge loss, and the project was terminated as were a number of managers.

Contrast this nightmare with the experience of Scott Brown, director of an enterprise IT renewal program for a leading automotive remarketing company. His program, which is designed to replace all core operating applications, including standardized tools and processes, continuously evaluates and implements common tools for business and technology users. Despite the program’s successful start, Brown says considerations outside of the tool’s scope cannot be excluded if a project is to be successful.

“In a nutshell, a tool does not equal process, and without training and process re-engineering, all implementations fail,” Brown says.

Brown refers to his method for avoiding the pitfalls of the myths as “E3: establish process, educate and enforce.

“Very little thought has been given to understanding or documenting business process prior to initiating the next great idea,” Brown says, adding a caveat to managers who de-emphasize process over a company culture likely to accept the myths as gospel.

“Culture eats process for breakfast,” he says. “It’s the single biggest challenge to avoiding these pitfalls.”

Strategies to Overcome the Myths

Clearly, it’s important for management to re-evaluate all of those assumptions that tend to jeopardize rather than facilitate. Start with an emphasis on the process of developing plans and people long before anyone is sent to a workshop. Planning should include other important considerations including a mentoring program in which experienced project managers train future managers, who have completed workshops.

These strategies will be successful only if companies are willing to put the time and resources into development. The best managers will display knowledge, aptitude, reasoning and leadership skills, but these are not always innate. They require practice to mature.

They also require time.


Don Wessels is project management senior consultant for Management Concepts, Vienna, Virginia, a professional services company with training, consulting and publishing expertise. Management Concepts partners with individuals and organizations to improve performance through consulting, training programs and certificate courses. For more information, please call (703) 790-9595 or visit www.managementconcepts.com.

Dashboarding Redux

I thought I’d take the opportunity to bring several conversations I’ve had with you here together under the heading of Dashboarding.

I’ve talked about the attractiveness of dashboards in here before, but the continual movement towards dashboard displays for senior management in all types of industries means we’re not going to be able to get away from them any time soon. For those of you who have not seen this phenomenon in the project management industry, you won’t be able to avoid it for long. A project dashboard is an onscreen view of several key performance indicators (KPIs), which show the measures for different aspects of your business in easy-to-understand displays. There’s no restriction on how to display this information or what to include in the dashboard. The sky’s the limit!

A dashboard may be dynamic or static. A static dashboard lets you see the indicators somewhat like a printed report. A dynamic view might let you click on the screen to change the display by filtering or selecting certain data or to drill down into one indicator to see the source information it was established from.

The views in a dashboard can be very creative. Rather than a simple columnar text report, you might be looking at a green/yellow/red traffic light report or perhaps a tachometer with an indicator on how far “in the red” this indicator is. There might be a curve view showing costs, or a graphical flag showing red for danger, or a checkered flag for something that’s complete. There can be histograms, pictures, colors or anything else that might allow the viewer to get their answers at a glance.

The data that drives a dashboard is also not restricted to project management information or even information from one application. It’s not uncommon to see some indicators from the project management system, some from the financial system, some from production software, and so on. There can even be indicators that compare the data from one system to another such as the budget cost from the project management system and actual cost from Finance.

As attractive as all that sounds (and believe me, management finds this kind of thing very attractive) it comes with a range of pitfalls. Let’s take a look at a couple of obvious ones.

The Wizard of Oz Syndrome

This is stunningly common. Management decides that they’ve got to have a dashboard right away. It’s so compelling that they make up a “dashboard” project. The hapless project manager realizes quickly that creating the dashboard isn’t the problem… getting the data to drive the indicators is. Management has little tolerance for a story of how it will be months before the data is complete enough or of sufficient quality to be trusted to move a dial on a dynamic dashboard and so, our luckless project manager becomes the Wizard of Oz. He or she creates the beautiful front-facing view and then manually fills in all the elements to make the indicators move where they think they should.

The pitfall here should now be obvious. The assumption of management is that what they’re looking at is an objective view, built from the ground up, to show summaries and analyses of critical data. In fact, what they’re getting is a totally subjective view that is being typed in by a small number or even a single employee.

Measure It All!

The challenge for some organizations is finding the “key” in key performance indicators. They decide to put into the dashboard everything they can measure. The dashboard quickly fills with information of all sorts and doesn’t leave the organization any more empowered. One of our standards for dashboard design is to ensure that every indicator on the dashboard results in the viewer being empowered to take business decisions.

The Glass is Half Full

One of the big challenges with dashboard data is determining that all the data required has been collected. I met with a very senior CIO a few months ago who was so excited when I showed him some dashboard examples that he asked if we could create it for him as our first part of the Enterprise Project Management deployment.

“Can it be ready for Friday?” he asked.

“Sure,” I replied, rather shocked that he’d asked.

“Really?” he said.

“Yes,” I said. “It can be ready Friday. Well, not this Friday. But some Friday …some time.”

He wasn’t amused. The problem, I explained is that, while I could create the dashboard itself in a very short amount of time, the data that we needed to drive such a screen was part of an extensive process that would take months to design and deploy.

“What if I could give you an indicator for resource capacity planning, but it only measured half the total projects?” I asked. “What could you do with that view?”

The answer of course is: nothing. What if the half of the projects that weren’t measured contained 80% of the resource requirements?

Even if we make a design that we train and deploy to everyone, we need to be sure that the dial we’re looking at can be counted on. In our office, we insist on a dashboard indicator that shows the reader the level of compliancy within the view. They should be able to see at a glance if the data is all being measured before they make a decision based on the indicator in question.

Multi-aged Measures

It’s not enough to know that all the projects are included in the measure of this indicator. When we’re talking about project management data, we also need to know how timely it is. What if a particular indicator is made up from some projects that were statused yesterday, some projects that haven’t been updated since last week and some projects that haven’t ever been statused? Clearly the timeliness of the data colors significantly the value of that metric. When we create dashboards around here, we always insist on indicators that show how recently the data has been updated and show a warning if some of the data is significantly out of date.

What’s the Source?

We want to avoid as many subjective measures as possible so whenever we can, we thwart the Wizard of Oz syndrome by showing indicators of where the data has come from and, even better, by allowing a drill-down into the source data whenever possible.

Gaming the Process

Once you deploy a dashboard and people figure out what it’s measuring, there is bound to be someone who tries to “Game” the process. They will try to show how well they’re doing by entering data into the system that generates a particular effect. (Yes, I know that’s bad.) This is human nature and, fortunately, doesn’t happen all that often. We can do a lot though to disincentivize such behavior by implementing checks and balances right on the dashboard. Whenever we can find data that has some correlate (such as progress in a task and hours spent on a timesheet) we try to tie them together and show warnings or indicators when these numbers don’t make sense.

Dashboards can be a powerful tool and, one of the things I like best about them is they bring our project management perspective right into the executive suite. If you’re being called upon to create a project dashboard, then take pause to make sure the decisions that will be made from it are going to be looking at the right data and the right analysis.


Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at chrisv@hmssoftware.

Budgeting: What Is It Good For?

Absolutely nothing, say it again …(sung to the tune of Bruce Springsteen’s “War”). I am, of course, being somewhat facetious when I say that budgeting is not good for anything. It is good for a lot of things …giving a comfort level on potential costs, ensuring funds are allocated to pay for projects, etc. Those are all good things.

My biggest concern with budgeting is that, no matter how much time is spent on it, someone will always come along and change it. Have you ever been on a project where you and your team put a budget together estimating the costs of the project, only to have someone (usually an executive) come in and say “too expensive, make it cost less”? I am sure that most of us have.

So what do you do at that point? Do you stand firm on the estimates? Do you push back and say that it cannot be done for less? Do you lower the estimates to appease the executive? It is a tough position. If your estimates are good, you need to do a little of everything. If you are going to lower the estimates to hit a target number, then your identified project risk should go up correspondingly. If I lower my budget by 10%, my risk of not having enough funding goes up by at least that much.

The way I approach these situations is standing firm on the initial estimates, but also identifying areas where there may be an opportunity to reduce the actual costs, going forward. There may be opportunities to farm out all the IT work to one organization, thereby achieving economies of scale. There may be opportunities to bring in contractors for three months to do the work instead of hiring a full-time employee. There may be opportunities to reduce the annual operating costs. These are the types of opportunities that we, as project managers, need to identify.

I have seen many a project fail by arbitrarily lowering budgets to meet a targeted number. I have never seen a project where those arbitrarily lowered budgets were met. I would submit that the actual costs often end up being more than even the initial budget because of having to duplicate work or re-address issues that were not solved properly in the first place. There is a happy medium for budgeting, somewhere between too high and too low. As a PM, it is your job to ensure that happy medium is found.

 


Andrew Miller is President of ACM Consulting Inc. (www.acmconsulting.ca), a company that provides supply chain and project management solutions. Andrew is PMP certified and has led a variety of clients through complex systems implementations and organizational changes. He is an Instructor of the Procurement and Contracting course, part of the Masters Certificate in Project Management program through the Schulich School of Business Executive Education Centre (SEEC) in Toronto. Andrew has an International MBA from the Schulich School of Business with majors in Logistics and Marketing. He can be reached at [email protected].