6 Practical Concepts for Resource Control

The Project Manager must be adept at managing and controlling the physical resources on his projectIn my previous article, I wrote about how Project Managers often take the monitoring and controlling of physical project resources for granted. It is almost as though laptops will mysteriously appear when developers arrive, development environments will configure themselves on time, and classrooms for training will be available when needed.

Reference that article here: “Why Resource Control Can Never Be an Afterthought.”

Of course, I am exaggerating. Many projects plan, monitor, and control their physical resources with as much care as they do other aspects of the project delivery.

But many do not.

In my experience, every project I had been associated with had performed a detailed estimation of physical resource needs at the outset. This was a standard requirement of every Request for Proposal that we bid on. For those that were firm fixed-price bids, the stakes were even higher. If we estimated resources too liberally, we risked losing the bid. If we estimated insufficient resources, we risked “eating” the shortfall.

Unfortunately, this same care and concern was not sustained during project execution. The monitoring of the resources often received less attention, resulting in mad scrambles to ensure resource availability at the right time. Controlling resources, likewise haphazard, would result in excess or shortage, which further resulted in premium payments, missed release dates, project delays, and unhappy customers.

I have implemented several ideas on projects which I managed. These simple concepts helped me to ensure that resources were available when needed, utilized as planned, and their cost managed effectively.

I’ve shared several of the following concepts with colleagues amid eye rolls and “duhs”. My standard response is always, “Well, if these are so obvious, why aren’t you doing them?”

  1. Survey the horizon constantly. If the project has been planned well, the resource plan will be in synch with the project schedule. Lead times will be indicated for acquisition of all physical resources based on contractual agreements with the suppliers. For example, if the project will need 200 developer workstations in eight months, the schedule will include a task on when the order must be submitted. If classroom availability for end-user training is scarce, classrooms must be reserved well in advance of when they will be required.

    Even after resources are secured in this way, the Project Manager must continue to look ahead. If the project begins to slip, or gets ahead of schedule, the suppliers of the physical resources must be kept in the loop. Using the previous examples, the workstation vendor or facility manager may waive penalties if given enough notice of the schedule change. If not, then the Project Manager has given herself enough time to negotiate a solution.

    Treating suppliers as partners and not as commodities will almost always garner favorable treatment from them should such changes be required.

  2. Build in a cushion when estimating physical resources. If the initial resource estimate assumes enough software and hardware for 200 developers, a contingency should be added (say 10%, or whatever is comfortable within the bounds of the project budget or bid price). One never knows if change requests for additional work will be approved, or if project slippage will need to be mitigated with additional resources.

    Take a simple example from my recent DIY home project of building a compost bin. I drew up the plans, estimated the materials, and ordered them through a local big box store. Imagine my disappointment when I discovered I was short seven outdoor-use wood screws. For an extra $10 I would have had a slight surplus, but I would not have had to pause the project for an extra trip to buy more screws.

    This may be a trivial example, but I have seen situations like it happen on multi-million dollar projects. Unfortunately, when it happens on a project, it cannot be fixed by an extra trip to the store.

  3. Remind yourself that responsibility and control are inseparable. I often worked on proposals where the client organization requested a turnkey project but wished to maintain responsibility for the computer hardware. My boss would negotiate with the client to assume responsibility for the hardware as well – not because he wanted the additional work of procuring, installing, configuring, and eventually re-licensing the equipment to the client – but because he knew that if left to the client there was greater potential for it not being ready in time.

    I once asked him why he preferred to take on this added responsibility, especially when the client would be held responsible for any delays. His standard response was, “Because we have the most to lose?”

    What he meant was that in the throes of project execution, no amount of finger pointing could bring the project back on track if something as critical as the environment was not set up in time. To be successful it was imperative that we were in control of our own destiny.

  4. Use trade-offs judiciously. Some of the most frustrating aspects of my experience in managing projects was the penny-wise/pound-foolish mindset of the corporate organizations I worked for or contracted with.

    What do I mean by trade-offs? Sometimes it is more prudent to spend the extra funds to control availability of project resources for a more streamlined task execution. Sometimes, as in the previous bullet, it is better to assume additional responsibilities to ensure success. Sometimes it is better to descope lower priority functionality in exchange for change requests than to delay the entire project to add the new functionality.

    I’ve known consultants to fly through connecting cities rather than direct to save on travel expenses – at the cost of several billable hours. I’ve witnessed corporate Accounting require just-in-time delivery of equipment rather than having a pre-configured inventory of laptops – at the cost of several days’ downtime of new staff coming onboard. I’ve seen a project put off booking community-based training classrooms to protect near term cash flow – at the cost of having to book more expensive hotel facilities later because the classrooms were no longer available.

    I once conducted an experiment with a firm I worked for. As an executive, I was required to submit receipts with my expense reports. On one occasion my entire expense report was returned to me for correction because one of the receipts showed a beer with dinner. Alcohol was not reimbursable.

    So, there I was; an expense report of several thousand dollars was being held up for a $5.60 beer (plus tax and tip).

    I was incensed, not because the accounting clerk questioned the beer, but because he had held up the entire reimbursement for such a miniscule amount.

    Here is where the experiment came in. I sent the expense report back to accounting with a note attached explaining that the beer was non-alcoholic (which was true). I further informed them that had I ordered a soda, they would have paid the entire amount.

    It was two more weeks before I received my reimbursement. The clerk had taken it to his supervisor who had asked his director for a ruling. When I received the check (yes, a physical check in those days), I calculated the opportunity cost of the time involved from initial rejection to resubmission to management review and eventual approval. It was ridiculously high compared to the cost of the near-beer.

    Had the clerk just subtracted the cost of the allegedly unallowable beverage and reimbursed me for the remainder, I would have accepted it with no question. However, holding up my payment in this way gave me great incentive (and malicious glee) to show just how penny-wise/pound-foolish our corporate bureaucracy had gotten. The trade-off could not be supported.

  5. Monitor resource maintenance contracts diligently. I have been involved in at least a half dozen projects where, for one reason or another, major software items were allowed to lapse into unsupported status. It is not a happy situation when the project is potentially delayed to bring the software up to the latest releases.

    On one contract that I inherited, the client’s IT shop had let the equipment refresh process languish over the years. By the time our team arrived, IT had been cannibalizing non-functioning warehoused equipment for working parts that could be used to keep still functioning equipment working. It was a constant battle of band aids and bailing wire to keep the end-users working. Had they just kept up with their equipment maintenance and regular hardware refresh, the hefty cost to bring the organization back to efficiency with regard to its systems would have been avoided.

  6. Quality matters. How many times have you seen projects fail because a decision was made to save money by substituting a lower priced product for one known to work well (another version of the penny-wise/pound-foolish mindset described earlier)?

    I was once requested to conduct a project assessment for a troubled project. One of the failure points (which was not part of my assignment) was the end-user equipment that had been selected for implementation. The project had saved hundreds of thousands of dollars by selecting a startup manufacturer’s product line. However, as I later learned, the equipment failed at such a high rate that the client opted to upgrade to a major supplier’s offering rather than repair the existing equipment.

    In another situation, my boss decided that the only way to win a major procurement was on price. And the only way to do that was by so lowering the estimated cost of the solution infrastructure that none of our competitors could come close to matching our bid price.

    Our technical engineers team devised an elaborate architecture based on emerging technology (think client server when the whole world was comfortable with big iron). Our bid was two-thirds the cost of our next competitor. Unfortunately, the client was risk adverse and refused to gamble on an unproven solution. While the quality of our solution was never tested, it was suspect. Some of the components were still in beta, as was the system software.

These are but a few practical examples of monitoring and controlling physical project resources. Given their importance to the smooth functioning of the project, the extra rigor and diligence in their ongoing management is paramount.


Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.