Forward Momentum: Delivering Results

By Craig Covello, PMP

In part one of this two-part series, we looked at cross footing to find spreadsheet errors. This month, we look at a possible early warning sign of overspending.

Run Rate Exhaustion

Every project has two primary appetites.  One involves purchases of equipment.  The other consumes money in the form of labor.  If this labor is defined as “time and materials” without any capitation, the project is vulnerable to budget overruns.  One way to mitigate the problem is to make a prediction using something I like to call “run rate exhaustion”.  The technique is simple.  Team members provide the project manager with an estimate of hours required, before the project starts, as part of the budget process.  Once the project is underway, the actual hours expended by each team member are recorded, averaged and used to extrapolate hours for the remainder of the project.

Note – Click on graphic for better resolution.

Run Rate Example

If the extrapolated figure exceeds the original staff estimate, then there is a chance of exhausting your labor budget before the project completes.  Of course, this extrapolation technique is more art than science because it assumes that the hourly burn rate is somewhat linear.  You might need to incorporate some refinement by adjusting a specific team member’s end date relative to the project completion date.  But even with its limitations, extrapolating run rates can be a very effective tool.  It allows you to identify potential labor cost overruns and take corrective action, hopefully before the situation becomes a threat to your project budget.

Drop me a line if you decide to use either of these techniques and later discover that they saved you from falling off the budgetary cliff.  Then share your story with the United States Congress, since it appears that they struggle with some of these budget-oversight concepts. The Senate may have miscalculated by about $13.7 trillion.  It was probably a spreadsheet error.  ;-)  http://www.usdebtclock.org/

By Craig Covello, PMP

This is part one of a two-part article.

At first glance, the title of this article might lead you to believe that the subject has something to do with the Boston Marathon or Churchill Downs.  Although I’m sure some metaphors could be made regarding the competitiveness found in both racing and business environments, today’s topic is actually about some tricks and techniques that project managers might find useful when overseeing budgets.  Let’s examine each one.

Cross Footing

This is a technique familiar to most accountants and heavy spreadsheet users.  It’s designed to find errors in spreadsheet formulas, such as summations and averages, by calculating redundant totals associated with both rows and columns.  Here’s a relatively simple spreadsheet that illustrates the concept:

Cross Footing example

In example 1, contract subtotals are added vertically in column F.  In example 2, contract subtotals are added horizontally in row 15 and the results appear separately in column G.  It might seem intuitive that these totals must always agree, and in fact, they normally would.  There are, however, exceptions to that assumption.   These numbers may disagree due to errors in cell formulas.   This is illustrated in example 3, where the contract subtotal of $70,981 is incorrect because the formula is missing taxes on equipment.

This begs the question; how are these types of formula errors introduced?  Well, typically it is the result of adding columns or rows in order to adapt the spreadsheet to ever-changing project conditions AFTER data has already been entered.  It’s a common scenario, which I’m sure we’ve all done at one time or another. Admittedly, the example given here is rather straightforward, but you can imagine the difficulty in finding this type of subtotal error in a spreadsheet containing 10 or 20 columns with hundreds of row entries.

Some spreadsheets, such as Microsoft Excel^®, attempt to flag these errors with a callout graphic resembling something akin to a traffic sign.  Unfortunately, that flag might escape your attention since the cell must be selected in order to see the warning.  Errors caught by cross footing are a little more obvious and can save you some time, sanity and embarrassment before your spreadsheet is published.

Next month we will look at run rate exhaustion to provide an early warning sign that our project may be in jeopardy of overrunning our project budget or constraints.

By Craig Covello, PMP

During the course of my long career as an IT project manager, there have been a few times when circumstance and opportunity translated into a strange role that could be accurately described as “Shadow Project Management”.  It’s something like the Twilight Zone.  This Shadow Project Manager has all the responsibility normally assigned to the official project manager, but without the title.  Instead, this position in the Twilight Zone is usually described as some type of special “consultant”.   If Rod Serling was alive today, he might offer this description:

“Submitted for your approval is the tale of a project in trouble which requires a “special consultant”.  One who ends up filling the void of effective vision, leadership and delegation.  It’s a void between shadow and light that transcends space and time.  Its limits are only those of the mind itself.  Ladies and Gentlemen, you’re entering the wondrous dimension of Shadow Project Management… next stop, The Twilight Zone.”

Perhaps that’s a little dramatic, but you get the point.  So why would I accept a position like that?  Because it’s for the greater good, as described in the following scenario -

• An enterprise wide, high-profile project is either in trouble or has a very aggressive timeline dictated by upper management.

• Due to corporate politics or possibly lack of good managerial judgment, the project manager picked for the position does not have the experience and/or skills required to successfully complete the mission.

• Project sponsors in the organization believe someone else may have the capability to successfully lead the project team to completion, and therefore, would make a good “insurance policy” if installed as a special “consultant” to the effort. This avoids the pain or political embarrassment of replacing the official project manager.

So when these opportunities come along, I usually accept them without much hardship.  The truth is that planning and execution under the Shadow Project Management framework is actually no more difficult than stepping into the role as the official project manager.  The Shadow Project Manager usually garners the same level of respect and responsiveness from the team, since there is a natural human tendency to follow individuals with the vision, confidence, experience and skills to get the job done.  Titles are secondary.   Everyone on the team wants a leader who will create a favorable climate that facilitates task execution and efficiency, while producing a successful project outcome.  In my experience, even the official project manager takes direction from the Shadow Project Manager.   So there’s a silent acknowledgment established among stakeholders and team members, which implicitly authorizes the “consultant” to stealthily act as the PM.

Admittedly, it is flattering when asked to quietly step in and manage a critical or troubled project and I enjoy the process of successfully completing the mission.  But it’s also understandably a little less satisfying to have someone else take the credit at the end of the day.  I tend to value the recognition for a job well done as much as the salary that comes with it.  Perhaps you do as well.

Then again, it is for the greater good.  And occasionally that means denying yourself recognition and entering The Twilight Zone of Shadow Project Management.

By Craig Covello, PMP

I think it’s fair to say that most project participants are interested in doing a good job. Money is certainly a motivational factor, but many of us also value the concepts of personal integrity, commitment and reputation. We want to do the right things and we want the project to be successful. Recognition for a job well done is also its own reward.

So sometimes project participants adopt an unrealistic and overly optimistic view of reality when circumstances suggest otherwise. The term “whatever it takes” comes to mind. It’s a cliché that continues to be embraced by some in the corporate culture despite the fact that this attitude has the power to sink projects, damage reputations and waste money. And you don’t have to accept it.

Here’s a case in point: I have the privilege of managing several health care innovation projects for my employer. Most are pilot efforts with budgets under $100,000 and project time lines between six and nine months. As such, they’re not terribly complicated, but admittedly they do have a tremendous amount of visibility across the organization. Some might interpret that visibility as a reason to do “whatever it takes”. NASA’s retired Apollo flight director Gene Kranz reinforced that philosophy with his famous statement “failure is not an option”. While that is certainly true when bringing astronauts back from the moon, it doesn’t necessarily apply to pilot projects. The point of a pilot is to spend a minimal amount of money in order to validate a concept or idea.

Not everyone may agree with this thinking. Recently I was working with a “pilot innovator” who developed an original idea. He was given funding in exchange for defining implementation details, general time lines and success criteria. Unfortunately, his vision did not reflect reality. All the warning signs were there.

• Unrealistic time lines.
• Scope that went above and beyond the definitions used to fund this project.
• No alternate plan to mitigate problems that manifest themselves in virtually every project.

As project manager, I had the responsibility of addressing all these issues during the planning phase. We came up with reasonable compromises before moving forward. But again, more warning signs began to appear during project execution.

• The innovator continued to work on activities which reflected the original and unrealistic scope.
• He avoided reporting problems encountered, preferring instead to work extended hours without asking myself or the other 8 members for assistance.
• He begin missing scheduled team meetings, which further impeded the project’s progress and assessments.

So it was time for some “tough love”. I had a one-on-one meeting with this individual and presented my concerns rather candidly in order to realign expectations. And it worked. Several additional issues were uncovered and I was able to offer solutions which took a tremendous amount of stress off his shoulders. As a result, he was very appreciative of my direct approach. The project sponsors also expressed their gratitude.

Here’s the point. There is a natural tendency for us to avoid conflict, but as a project manager, conflict should be addressed and resolved as early as possible. These are some guidelines I’ve adopted:

• Preface all concerns or criticisms with the understanding that they are related to the project, not the individual. Don’t make it personal.
• Be honest with your assessments. This should not be difficult if expressed in the context of the project, not the person.
• Always offer a solution to mitigate your criticism or concern. There is always a plan B.
• As Ronald Reagan once said, “trust but verify”. Don’t be passive when collecting status information. Ask questions and get details in order to understand the true situation.
• Try to meet with the entire team face-to-face once or twice during the project. Virtual “WebEx” meetings are sometimes more efficient, but meeting face-to-face may help to establish comfort, trust and honesty between project participants. This was one of the lessons learned in Bruce Beer’s article dated May 31 titled Virtual Teams and PMOs – The European Experience.
• Recommend terminating the project as early as possible if it appears that there is little chance of success due to circumstances beyond your control. If plan B, or even plan C cannot be executed, this is no point in wasting additional money and resources hoping things will get better.

The bottom line? Failure is sometimes an option, unless of course, you’re bringing astronauts back from the moon.