Skip to main content

The Challenge of Evaluating EPM Software

Written by Cynthia Low on . Posted in Articles. 3 Comments on The Challenge of Evaluating EPM Software

It happens to me all the time. The mail arrives and in it is an RFP. They’re three dreaded letters around my office and I’ll tell you why. The “Request for Proposal” is a construct of purchasing departments, designed to compare vendors with similar products to sell. The RFP is supposed to list in exacting detail exactly what kind of proposal the client requires and the respondents are expected to prepare their proposal and give the best possible price to the client. The client evaluates all the proposals together and then knows who can give the best possible solution.


It works great when the client is looking to buy army boots or kitchen knives or storage containers. It’s virtually useless when used to purchase an enterprise system and here’s why:

First of all, let’s take a look at how we assemble the RFP. The beginning and end of the document are boilerplate. They list the process of how to respond and the legal terms of what responding may mean and what you must or must not agree to. In fact, most of this is not that useful, since if you are the winning bidder, you’ll need to go a whole new round of terms negotiations with the contracts people but either way, this is not our big concern. No, it’s the bit in the middle we want to talk about.

In the middle we’re supposed to have a list of those requirements in ‘exacting detail’. The client must assemble the various parties involved to see what they would like in our new enterprise system. Perhaps a committee is convened or a series of focused workshops to work through all the implications of each requirement. Perhaps there is a long period devoted to developing the business requirements that will resolve to system features.

If only…

In fact, what’s more likely is the project manager assigned to this project will have a short meeting, or perhaps two, during which he or she will make a request that the participants represent their departments by listing all the features that are important to them. Each person goes back to their group and sends an email saying “This is your only chance to have any impact on what we’ll need in the new enterprise system. Speak up now or forever hold your peace.” The departments respond in an uneven fashion. Some department members give the request serious consideration and submit a long list of things. Others give only a perfunctory response.

The project manager now assembles these items into a spreadsheet and adds a few columns: “Priority,” “Comment,” “Included.” The end result looks like this:

Instructions:
For each Priority enter:
M: Must have
I: Important to have but not essential
N: Nice to have
For each Included enter:
Y: Yes, this is included in your product
N: No, this is not included in your product
E: This could be included by adding additional effort which has been identified, scoped and priced into your proposal

Feature Priority
(M/I/N)		 Included
(Y/N/E)		 Comment
The enterprise system must

Gosh, it looks good so far, doesn’t it? The spreadsheet fills out quickly. For the more organized clients, on the internal copy (the one not sent to the RFP respondents) is a column called “Weighted”. This is where the relevant score weighting for each item is entered.

The project manager now merges line after line, categorizing them perhaps to make sure there are no big feature holes. In the end, what is received is a remarkable list of features that looks just like every EPM system brochure on the market today.

Now, the vendors get this list and scratch their heads. God knows, I’ve done it plenty. They look at the list of features listed and try to make sense of why some features are listed 2, 3 even 4 times but each worded a little differently. They try to reconcile some features which seem diametrically opposed to each other. They ask questions for features which seem deliberately vague like “The system must automatically transfer data with our internal LIMS environment.” Invariably the acronym LIMS is not explained and the details of what the expectation may be are not available.

But there is a profound problem with this process. Have you spotted it yet? The RFP is describing the solution not the problem. It’s a massive disconnect and no one ever talks about it. The purchaser or the project manager assembles a list of every feature all his or her users can come up with and presents that list to the vendors. But what is not at all clear is whether the delivery of those features will make the lives of anyone at the client company any better.

So, what happens? Vendors go through an exercise of preparing a hundred-page or sometimes a multi-hundred page response. The client receives several of these. The selection committee reviews them all. They all say the same thing: “We can deliver every feature you’ve described.” Sometimes vendors tick off every line item with a “yes”, even the ones that don’t make sense or are in complete conflict with other line items.

The hapless readers must wade through these documents trying to determine which vendor makes sense. The weighting scheme tells them what features are more or less important but the scores after everything is done are very close. The biggest impact on scores? The neatness of the work! I know, it sounds childish but ask around and see if it’s not true. The vendor with the most colourful, neatest, easiest to read response always scores well.

Now a short list is assembled and a couple of vendors are invited to do demonstrations. Typically the meetings are a couple of hours or less. In the most frustrating cases, the client asks that the demonstration look exactly like what their system will look like after it’s purchased, configured, populated with data, customized and enhanced. This obviously can’t be presented. But, the meeting is important because it’s the first time the vendor gets to meet the end users and ask “What on earth is it you need to accomplish? What are you suffering from? What is the problem?”

In the end, purchasing decisions are often made one level above the selection committee anyway. An executive makes that decision not based on a requirement analysis but on the recommendation of a trusted advisor, or a friend or colleague who once bought a similar system. Will it work? Sometimes and sometimes not but it’s a certainty the system purchased was not done based on what the company is struggling with.

“But that’s the best purchasing process we can come up with,” I’m sometimes told.

I truly doubt it.

If you’re considering moving to a new EPM system in the New Year, I’ve got a couple of recommendations for your purchasing process.

First, start with the problem, not a description of what you think the solution should be. List the business challenges that you are finding it difficult to overcome. They can be articulated in terms of business decisions that you find difficult to make or business process inefficiencies that you wish to improve. Saying “the system must help us decide to increase or decrease our future resource commitments with sub-contractors but delivering resource capacity planning such that we can see a projection for the next 90 days of resource requirements and resource capacity.” is incredibly more powerful than saying “The system must have resource capacity planning reports.”

A vendor who understands the business challenges will feel more latitude to craft a response which may be more creative and, even better, in ways that you’ve never imagined.

Next, put less attention on the vendor demonstrations and more on vendor references. Probably the most valuable thing you can do during this process is arrange to visit the sites of other clients of the vendor. A vendor salesperson demonstration will always look sharp but a real client will almost always be honest enough to explain the parts of the deployment that went great and those which were more challenging.

Finally, make sure that management gets on board with this process early and stays involved. There’s little more debilitating than having a selection group work at something like this for months only to find out that none of their work will be considered when someone from senior management makes the final decision.

Happy buying!

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 [email protected]

 

Chasing the Schedule

Written by Andrew Miller on . Posted in Articles. 3 Comments on Chasing the Schedule

Have you ever wondered if you are managing the schedule or if the schedule is managing you? There are too many projects where the schedule becomes obsolete early on and is eventually dropped. Why is that? Is it because of ineffective project management tools? Is it because of ineffective project managers? Is it because projects are constantly changing, thus impossible to manage? I submit to you that the main problem with schedule chasing is that most project plans never take into account all of the important activities required to achieve a milestone. So why not detail all of those activities, you may ask?
There is a fine line between not enough detail and too much detail in a project plan. I have seen project plans that are 20-30 lines that are unmanageable due to their lack of detail, but I have also seen project plans that are 2,000 lines that are equally unmanageable due to their granularity. It required entire PMOs just to manage the updates. So how do you avoid both of these problems and effectively manage the schedule?

My advice is to always look at the milestones that need to be achieved, and manage to those milestones. That is your 10,000 foot level of whether or not the project is on time. Then you need to identify the dependencies to complete those milestones successfully. This brings you down an additional level, but the project plan still remains manageable. A PM should be spending his or her time ensuring that the project team has the proper tools and a clear path in order to complete those dependent activities. They should be working on nothing else. Issues that block the team’s ability to complete those activities should be prioritized and other issues dealt with at a later date.

I realize that this is not rocket science, but too many projects focus on the number of tasks to be completed, the percentage complete, the number of resources, etc., but some of those tasks do not always relate directly to the milestones to be achieved. As soon as you lose view of the project milestones, you will lose focus on the activities that should be the highest priority and your project schedule will suffer.

Yes, it is that simple!

Understanding Earned Value Made Easy!

Written by Cynthia Low on . Posted in Articles. 3 Comments on Understanding Earned Value Made Easy!

From WBS to Performance Measurement Baseline

Earned Value (EV) has grown in popularity over the years. With 76% of IT projects failing (Crawford, 2002, 19), project management and control systems must be utilized to ensure project success. Earned value is a valuable tool that often is not utilized because it is misunderstood. The purpose of this article is to provide a simplified approach to understanding earned value. Earned value is an early indicator and forecaster of project progress. Earned value shows a “three dimensional” view of project progress. Find out how earned value links to the work breakdown structure, the schedule, and the budget. If you read on, you will see the potential for implementing an earned value methodology on your projects, starting now!

To fully understand earned value you must understand how the performance measurement baseline links to the WBS, the schedule, and the budget. If earned value is to be used it must first be understood. Often the confusion, and misunderstanding of how earned value management systems are created, results in the avoidance of this powerful project management reporting tool

Project control is often a primary focus for the project manager. What we strive to control is the project plan. The result of the project plan is a tangible outcome that can be quantified and measured. The triple constraint of scope, cost, and time must be negotiated to ensure a successful project outcome. At the foundation of the triple constraint is project scope. Often this is the most neglected aspect of the triple constraint. Management is notorious for demanding reports on budget and schedule status but not scope. Think of the last time a request was made for how the project scope was doing on your project. Project scope is maybe the most difficult aspect of the triple constraint to quantify and measure. What we do have at the disposal of the project manager is the Work Breakdown Structure (WBS). Activity based estimating allows the work duration and cost to be assigned at a detailed level of project execution.

Once the WBS is developed a schedule can be determined. Then cost and duration can be assigned. This allows for the cumulative cost curve to be developed. This rate at which the spending is planned to occur is what EV can be measured against. The cumulative cost curve can identify the value at any point in time of the work that is planned to be done – this is called the Planned Value (PV). We can measure and ascertain the percentage of the work done. The cost of the planned work that was actually spent can also be determined. With this information you are armed with a powerful tool to manage the project – EV.

Earned Value

Earned Value (EV) has grown in popularity over the last number of years, possibly due to data like Phillips (2002) which quotes the Standish Group as reporting on IT projects:

  • 31% of projects are canceled before completion
  • 88% are past deadline, over budget or both
  • For every 100 starts, there are 94 restarts
  • Average cost overrun is 189%
  • Average time overrun is 222%

Defining the Scope

The WBS
To fully understand EV we must understand how the values are developed. First start with the Work Breakdown Structure (WBS). By definition the WBS is “a deliverable-oriented grouping of project elements that organize and defines the total scope of the project”. (PMBOK© Third Edition, 2004). This in its most basic explanation is a list of all the tasks or activities that must be accomplished to deliver the project. A properly developed WBS is dissected into parts that represent a unit of work. Through the years the infamous “80 hour” rule has been handed down from generation to generation of project managers. I have even heard of project managers that keep the unit of work down to 40 hours. Why is this? When you try to assess how you’re doing – looking at 40 or 80 hours is much easier to assess than 2 months of work. If you can make better assessments of activity progress you will increase the accuracy and validity of your reporting.

How far do you break down a task? I always say, “To the level that makes sense”. For customer reporting you would go to a different level of detail than you would for management reporting and yet again to a different level of detail for the employee who will do the work. The objective should be to break the work down into parts that can be measured and identified that they are completed while not exceeding 80 hours. Using common sense is best when determining this. Keep in mind that the WBS is a tool to help manage your project; it is not a tool to micro manage.

The lowest level that you dissect the WBS to is the “work package”. By definition the work package is “a deliverable at the lowest level of each branch of the WBS”. (PMBOK© Third Edition, 2004). These are the activities that duration and costs will be assigned to. Once again, remember not to exceed the 80 hour rule.

Now that a WBS has been developed we can estimate the time and cost for each activity. Let’s reassess what we have so far. We have a WBS that consists of several levels; the project, its deliverables, tasks, and activities.

Other Scope Defining Products

What else do you have? You can look to contracts, statements of work, requirements, and other organizational representatives that may have been involved in development of the project plans (or whatever you may call them) available at this point. You also have Subject Matter Experts (SMEs) and those that will do the work. At the very least I am hoping that they are included! They have valuable inputs and need to be factored into the estimating process. You also may have access to project records of similar projects. If you do not, start archiving project records. This will help you to develop best practices as you develop your organization’s project management maturity.

Estimating Duration
Time estimating is your next step in this process. We have a very rough estimate that the work package can be done in less than 80 hours. Possibly there is a need for a more detailed WBS for the technical teams that will work on specific parts of the project. As you analyze each work package or activity, consider the time it would take under normal conditions, optimal conditions, and worst case conditions. Estimates should be realistic and there are many tools that can be used to minimize the risk that a project might run late.

Task Sequencing
When looking at tasks in a project, a strategic planning session should occur to determine task sequence. Think of this as a game of chess. Analyze the best sequence for the project tasks. Establish dependencies, mandatory and discretionary. This is a powerful use of the infamous post-it note. They can be placed and moved at will. Once all the tasks have been laid out they can be placed into a scheduling software tool of choice. Remember the software is a tool to help you with reporting; it is not project management, any more than using a word processor makes someone an author. Understanding the skills and tools required to manage projects is what makes you a project manager.

Estimating Costs
While estimating task duration, all resources should be considered, then all direct and (don’t forget) indirect cost can be computed. Remember the factoring of project duration when considering costs. Considerations regarding resource use for the time period of the task occurrence should be factored. Possibly the desired resource is not available. This will assist you in determining a reasonable and acceptable budget that you can manage your projects to. Costs can be calculated by industry inputs, subject matter experts, and cost modeling techniques. The goal is to develop a detailed budget at the work package level. Then you aggregate the costs to develop a total budget.

Cumulative Cost Curve
Now that you have a schedule and a budget, you can determine the rate of spending. This is a time distributed budget that becomes “the cumulative cost curve”. This spending curve is developed based on the planned schedule. The schedule indicates when the tasks occur and the tasks have a cost associated to them. This determines the rate at which spending occurs. Now is when the 80 hour rule will become important. With the tasks being dissected to less than 80 hours the validity of measuring the task to determine project progress is enhanced.

Earned Value Basics
Key Earned Value measures are:

  • Budget at Completion (BAC)
  • Earned Value (EV)
  • Planned Value (PV)
  • Actual Costs (AC)

Figure 1

Budget at completion (BAC) and planned value (PV)

The cumulative cost curve can be used to develop the EV measures. The entire project value is the budget at completion (BAC). Specific points along the curve are called planned value (PV). When you decide the appropriate point to measure your project progress (this could be weekly, monthly, quarterly, or any divisible factor) you can look at your cumulative cost curve and determine what work packages should be done to that point in time and how much it should have cost.

Earned Value (EV)
When monitoring project progress the schedule can be utilized to determine what work has been done. If 70 percent of the scheduled work is completed (now aren’t you glad tasks are broken down to less than 80 hours?) the value for that work is 70 percent of the planned cost (PV) given for that portion of the work. Here is an example; through one month we had tasks totaling $100,000, this would be the PV. When we measured the work completed we determine that only 70 percent is done. This results in an EV of $70,000.

Actual Costs (AC)
Next we can determine the money spent to complete the work accomplished. This is referred to as actual costs (AC). Based on the previous example we might assume that the work accomplished is $70,000, but after all check is cleared we might have spent $85,000. Thus our actual cost for the $70,000 worth of work was $85,000.

EV Calculations
What does this all mean? You have a tool that provides a three dimensional view of the project. Typical project variance has been determined by looking at the difference between the planned and the actuals. Earned value lets you look at the planned values (PV), actual expenditures (AC), and the actual work completed (EV).

Schedule Variance (SV) and Schedule Performance Index (SPI)
The previous example showed us that we have a SV of negative $30,000. This is calculated by subtracting the PV of $100,000 from the EV of $70,000. This identifies that we did not do all of the work we said that we would ($100,000). We are behind the planned schedule. We can also determine a rate of work performed efficiency (SPI) by dividing EV by the PV. This results in a schedule performance index of 70.

Cost Variance (CV) and Cost Performance Index (CPI)
Also the previous example showed us that we have a CV of negative $15,000. This is calculated by subtracting the AC of $85,000 from the EV of $70,000. This identifies that the work accomplished did not cost what we estimated the work to cost. We have gone $15,000 over budget. We can also determine a rate of efficiency of spending (CPI) by dividing EV by the AC. This results in a cost performance index of .82.

Variance Ranges
Knowing the acceptable variance is a must for effective project management. What if the acceptable variance is 25%? We can determine that our budget estimating is acceptable by a CPI of .82. In regards to SPI we also can see that our schedule variance is unacceptable by a SPI of .70. We had better estimates for the cost of work than we did for the time to do the work. This is what we need to manage to. We can now better control our projects.

Predictive Measures
We can also predict where our project cost will end up. There are several Estimates at Completion (EAC) formulas. These formulas can be used to determine the upper estimates and the lower estimates. One of the formulas is dividing the BAC by the CPI so we can get a mid estimate. If our BAC for this project is at $1.5M, we can assume that with a cost performance index at .82, we will have an EAC of $1,829,268. If we subtract this value from the BAC we can determine the Variance at Completion (VAC) as -$95,744. Remember what I said about acceptable variance? If we have an acceptable variance of 25%, we would be within tolerance ranges. Twenty-five per cent variance on $1.5M equals $1,875,000, thus the EAC of $1,829,268 is acceptable.

Summary

What does this all mean? We have a tool, EV, which allows us to identify how much we should spend based on how much work we said we would do. But as all plans go, these are subject to change. We must determine acceptable ranges of variation when we first plan our project. How does an organization determine what an acceptable variance range is? First determine the level of difficulty for the project. Second determine the level of experience of those working on the project. Last determine how the organization assesses variance. I have seen organizations set variance levels as; +/- 10%, +/- 25%, +/- 50%, +10/-5%, +25%, -10%, and +75/-25. The different ranges should be articulated in the beginning and should be based upon the level of confidence that you can assign to your estimating efforts.

What have we learned? Earned Value is a control and monitoring system used to assess project performance. You can measure schedule progress, task progress, and cost progress. EV can be used to predict project performance and determine where the project will end up. Corrective actions can be taken to possibly put the project back on track or to stay within acceptable tolerance. We have identified that the values we use in EV are based on the WBS, schedule, estimates, and cumulative costs. Connecting these aspects will make EV an easy and valuable tool.

Go ahead give it a try!

References
Crawford, J.K. (2002). The strategic project office. New York, N.Y.: Marcel Dekker, Inc.
Phillips, J. (2002). IT project management: On track from start to finish. Berkeley, CA: McGraw-Hill/Osborne
A Guide to the Project Management Body of Knowledge, third edition, (2004). Newtown Square, PA. Project Management Institute.

 

 

Wayne Brantley, MS Ed, PMP, CRP, CPLP is the Senior Director of Professional Education for the University Alliance (www.universityalliance.com). Wayne has taught and consulted project management, quality management, leadership, curriculum development, Internet course development, and return on investment around the world to Fortune 500 companies. He is a certified Project Management Professional (PMP) by the Project Management Institute, a Certified Professional in Learning and Performance (CPLP) by the American Society of Training and Development, and a Certified Return on Investment Professional (CRP) by the ROI Institute. Wayne is currently an adjunct faculty member at Villanova University.

The Rules of Lean Project Management: Part 6

Written by Claude Emond on . Posted in Articles. 5 Comments on The Rules of Lean Project Management: Part 6

Opening, Adapting and Closing Often

I continue here to expand my set of “rules” of Lean PM, following Hal Macomber’s comments on my original four rules series in his blog (http://www.reformingprojectmanagement.com/2008/11/09/883/).

Another lean principle Hal said I had left out was the necessity to PDCA everything (the Deming Wheel – http://en.wikipedia.org/wiki/Shewhart_cycle). Hal notices in his blog that “much has been made of the tools, techniques and methods of lean ways of working. But behind it all is Deming’s (Shewhart’s) Plan – Do – Check – Adjust cycle. It’s the embodiment of the scientific method. No company does it better than Toyota. Make it your habit.” Hal has however revisited the PDCA acronym by replacing the original meaning of the “A” (Act) by Adjust. And I will also revisit, because I believe the PDCA cycle, as stated, does not clearly illustrate what should be project work.

In the current edition of the PMBoK (3rd ed., 2004), PMI also acknowledges the importance of the PDCA cycle in project management, but goes on promoting its own version of it, the IPECC cycle (Initiate, Plan, Execute, Control and Close). There are slight but significant differences between those two cycles, differences that mirror those between recurrent operations and projects:

  • PMI “I” (Initiate) is inherent to projects (they start somewhere), hence not included in the more generic PDCA cycle
  • PMI “P” (Plan) is similar to Deming “P” (Plan)
  • PMI “E” (execute) is similar to Deming “D” (do)
  • PMI first “C” (Control) is equivalent to some extent to Deming “CA” (Check, Act). Continuous improvement in project management requires a special kind of acting to handle major project uncertainties and inherent changes. So for projects, Adapt would be a better word than Act and, I believe, more representative of high-uncertainty projects reality than the word Adjust
  • PMI second “C” (Close) is also inherent to projects (they have to close, while we do not want to close operational business processes), hence also not included in the more generic PDCA cycle. Granted, one could argue that Acting in the case of a project includes Closing it.

Hal said that we had to “PDCA everything.” The word everything is, for me, the key to the Lean PM philosophy and is related to LPM rule No. 2 (Track small concrete promises that you can see evolving over time). Everything, for me, means: each activity, each deliverable (daily and weekly promises/deliverables if you think Lean or Agile PM), each work package, each phase/stage of the project as they evolve.

So I submit that, for projects, we have to IPDCAdC continuously. Initiate, Plan, Do, Check, Adapt and Close everything. Open-Adapt-Close often. Open new work, adapt to change as you do it, and close it to the satisfaction of all stakeholders. And one must not forget that some projects need to be terminated before they are completed, if they cannot deliver what is required; so Close can also mean Stop!

In acknowledgement of Hal’s revisited comment, here’s Rule number 6 of 8 of Lean Project Management: The Open-Adapt-Close Often rule.

Rule No. 6 of LPM. Open-Adapt-Close, Open-Adapt-Close, Open-Adapt-Close… all the time.
The IPECC cycle is a recurring process; this recurrence is the true key to successful projects, lean-influenced or not. In order to close a project, you have to open-adapt-close formally at the phase level, to open-adapt-close formally at the work package level, to open-adapt-close for each required deliverable (small concrete promises), to open-adapt-close each required activity undertaken.

Here

Written by Ilya Bogorad on . Posted in Articles. 3 Comments on Here

I am writing this on the New Year’s Eve, getting ready to say farewell to 2008 and welcome 2009. This is the time when we raise our glasses and wish each other the best of things and revisit our own aspirations for the months ahead. It’s the time of reflection and hope, decisions and, often, concessions.

For whatever aspiration you have for 2009, I wish you that you have enough resources, determination and support to carry it through. I wish you good health, much happiness and every success you deserve.

Since the economic news from around the world is far from fantastic, I hope all organizations worldwide world will remember why they exist, will stick to their core values and always act responsibly towards clients, shareholders and employees. Since this is a project management blog, I also wish them good project management. It is critical today more than ever, because a tough economy has an unmistakable trait of being able to separate success from failure and amplify the consequences of both by a factor of thousands.

I must explain what I mean by good project management. I hold the discipline of project management to be a core competency of every senior professional, whether manager or executive. I have been and will remain critical of the current state of the project management designation which is so incredibly easy to obtain that the professional value of a good project manager has become diluted by meek, under-qualified individuals who could barely manage my cat’s breakfast, let alone a project. I have met with whole organizations besieged by hordes of such people, for they were very cheap to acquire. They have turned into expensive glorified clerks, making sure that timesheets are submitted on time and status reports furnished before the set hour, notwithstanding the poor content within them.

There is little place for such project management anywhere when the times are tough, and these people will probably among the first to go. It is high time for good project management, where project managers are:

  • Knowledgeable. Understanding the problem domain and having the general business knowledge is critical. I have now lost count of my conversations with individuals who could not tell me the business impact of their project, could not read a basic P&L statement and had no people management skills.
  • Resolute. Have you seen projects that are paralyzed because every minute operational decision is brought in front of the steering committee? It’s a sorry sight! I recently spoke to a senior PM with years of experiences, who confided to me that his project sponsor had made, as he believed, a suboptimal project decision. I asked him if he shared his concerns with the sponsor. No, as it turned out, on the account of the sponsor being “a very senior guy.” Within her scope of control, a project manager must be the ultimate decision maker, and granted, some of the calls will be tough. For all other project decisions, the ability to simply express one’s opinion as a person closest to the project is incredibly important.
  • Committed to learning. My observations suggest that there is a wide gap between the knowledge that project managers require, and that they are getting. Too often, an individual submits deludes herself or himself that she or he knows everything there is to know about the subject, while in fact knowing very little. By way of an example, one of the critical skills for a project manager is decision making, the ability to assemble a business case, weighing in financial, strategic and other variables. Really successful project managers recognize that there can never be the “end of learning” in this subject. I see them in my courses on Business Cases and Cost-Benefit Analysis, the nearest taking place on February 2, 2009. They ask provocative questions, yes, and I am happy to know that there are project managers like them out there.

In every profession, there are those who are good at it and those who are not. Difficult times are very effective in separating diamonds from the sand, and I have no doubt they will. In the difficult time we’re going through now. The good news is that the future of every project manager is largely in his or her own hands.

Here’s to good project management. Happy New Year!

 

Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company located in Toronto, Canada. Ilya can be reached at [email protected] or (905) 278 4753.