9.7
Handling
Prospective
Shortfalls
If, upon a
rigorous
examination, you uncover a significant prospective shortfall, you must escalate this by taking the following steps:
-
Document the potential shortfall, providing detail as appropriate.
-
Describe the impact on your project if funding is not adjusted.
-
Back up your assertions using industry standards, previous experience, or a detailed analysis. This should be clear,
concise
, and as brief as possible.
-
Deliver it with a business-like tone that focuses on the facts. Avoid criticizing the original estimate because you may not know whose political blessing gave this budget its life. In other words, be respectful so as to avoid currying disfavor in unseen or unforeseen places. I like to use phrases such as:
-
"Based on a detailed analysis of costs after finalizing the design
…
"
-
"After estimates were originally prepared, new information became available that indicates the original estimate of $X will have to be increased by Y percent because ..."
-
Have the team lead associated with the budget area under question participate in this escalation process because, in essence, you are going to bat for him or her.
If your project is quite large,
chances
are that you will find fluff from which you can divert funding for your shortfall, but I would leave that money untouched until you
absolutely
have to use it. The alleged
tasks
associated with that $2 million boondoggle I mentioned earlier were ultimately dropped from the project. Around 75 percent of the funds were given back to the corporation, but the project retained and spent that last half million on overtime, and justifiably so. The point is, we did not return the money prematurely and then have to go back to the well for it later when we needed it. No one ever questioned why the other funds were not spent, except, of course, those who had designs on it.
The best case in requesting additional funding is, naturally, that your request is cheerfully granted. The worst-case scenario is that your request is
denied
. Do not despair if that happens. You have put yourself on record as needing the money. If, or when, it turns out that you were right, management is less likely to hold it against you when reminded that the money you needed 6 months ago now blocks your critical
path
. This is how the game is
played
.
9.8
Service Delivery and Cost Recovery
I have alluded to the potential of beneficiaries to be cranky if not disruptive, and I
devote
Chapter 13 to that interesting battleground. A word about them here is useful in terms of the budget. In most major corporations and governmental agencies, users (i.e., beneficiaries) pay for services received through various
user
-based taxes. In my experience, this
generally
includes desktop and laptop PCs, use of LAN and mainframe file and print services, e-mail, dial tone, voice mail, and so forth. Many, if not all, of your project deliverables cost the corporation an initial outlay for new equipment and licenses, services, salaries, and consulting fees. That is your budget. In the normal course of business, however, the end user receiving these new products or services as a result of your project will be charged, normally on a recurring charge basis per server, per site, or per user. So, as project manager, I may give the vendor $X million for laptops, but the
beneficiary
I install them for will pay the corporation back at a rate of a few hundred dollars per month, per laptop, over a 3-year period.
[4]
What this boils down to is that beneficiaries see
themselves
as customers, and why not? With that title comes its privileges, which include fussing with you over such technology choices as vendor used, specifications, and whether or not they want to pay for the "cool stuff" too. Presumably, your technology team made such decisions based on merit or need, but that does not guarantee that the beneficiary community agrees on how you and your team propose to
spend
their money. In fact, in such a scenario, we had to ask the beneficiaries to provide additional money for certain features for which we were not
funded
but they demanded. Once that was hammered out, we had to
enlist
the beneficiaries' assistance with the "standards police," who took exception to the uplifted
specs
pushed
on the project team by the user community.
[4]
Or whatever the current depreciation schedule is.