Resource Calendar? I Will Just Use My Crystal Ball….

From the ever-so-popular Wikipedia: 

A resource is a source or supply from which benefit is produced. Typically resources are materials, money, services, staff, or other assets that are transformed to produce benefit and in the process may be consumed or made unavailable.

Yesterday when I posted regarding estimation and how project estimation and planning should occur within an organization; I briefly touched on resource calendars.  I feel this is a topic that should be expanded on and perhaps demonstrated to impress upon people the importance of properly developing, maintaining, and utilizing a resource calendar.  Consider an IT example:

A client has come to your business asking you to remote host their organization’s IT needs.  They are currently self-hosted and have a large IT team that, after careful analysis, has a larger fixed overhead cost than outsourcing their needs.  You are able to properly develop the stakeholder list and analysis, build out the requirement needs, and have developed scope and broken the scope down into the WBS. You have effectively scheduled the activities in the logical order considering dependencies, developed the critical path and are now ready to assign resources.  

For this project and for the sake of this blog and length of this post I will keep it extremely basic, the resource needs are as follows:

·          

• Enterprise Architect
• Software Architect
• Software Engineers
• DBA’s
• Project Manager
• Integration Architect
• Solution Designers
• Testers
• Citrix Servers
• Oracle DB’s
• Workstations (we will assume the current stations need to be updated

For even this basic transition from self-hosted to a remote-hosted model, you can see there are numerous resource considerations.  This, as many types of projects, is one that will require output/ work from resources at different times throughout the life cycle of the project and will not necessarily need continuous input from each role.  This effort, for this example, could also be something that lasts 18+ months to implement.  

Hopefully, if you had a chance to read my post from yesterday, you are starting to see that failure to properly estimate and plan projects in the beginning can have a domino effect of future projects.  Consider the basic schedule shown below for each resource listed above for the next 26 weeks:

This model assumes that your business doesn’t operate in a specific team approach, and that the labor resources are sourced as needed for specific items.  As mentioned earlier, roles are needed at specific times throughout a project life-cycle.  For instance, there is no need for a DBA during the beginning portions of the project and there are many items that can be completed before the DBA tasks become critical path items.  Utilizing this model, if done properly, can allow you to utilize your resources at the highest level of efficiency and output, removing possible idle time.  Do know that if utilizing this model, there is need to allow time to be acclimated back into a project if there is going to be a long period of time and a high level of change after a resource falls off.  

So, considering the resource calendar above, imagine the problems you would have faced had you estimated each activity starting immediately after its predecessor, and being able to be completed from start to finish with no interruptions.  If you study it carefully, if there are numerous activities in which the resources must collaborate, it may take significantly longer to complete certain pieces of work and the project overall.  Imagine if you had promised a client not only duration but also a scheduled completion date and then when it came time to actually start the project, the needed resources weren’t available.  Also notice this calendar doesn’t take into account the completion time to build certain resources.  Although it does show the availability of the DBA’s, you then need to extrapolate out the true completion date based upon the size of the DB build-out and the available time the DBA’s have to dedicate to this effort.  

Many businesses do rely on project management software to work through all of the possible considerations, but I would argue that for the first run through, it may be wise to construct the timeline manually.  Remember, software is only as accurate as the information we provide it.  Doing this process manually at first, allows you to intimately touch each portion of the project, asking yourself the challenging questions and looking for each issue or contradiction.  Once you have a schedule you feel accounts for all of the nuances, utilizing scheduling software can then help implement holidays, allow you to then manipulate resource allocation to keep resources under 80% allocation (This is huge and was discussed in yesterday’s post), while also factoring in vacation times, capital expenditure models and forecasting, and many others.  

One main question or concern I have encountered over the years around this theory is: 

If the estimation occurs months or even years in advance of the contract being awarded, how can you accurately estimate resources if a business has a low award level (contract success) of around 25% or less?   

a.       I have seen both sides of this possibility.  One side is the Owner/ Client gives specific dates for completion and also a start date.  This issue begins to push the topic away from proper estimation by utilizing a resource calendar as to not over allocate resources, and starts to move into organizational ability to scale depending on resource needs.  Having access to a labor pool to increase based upon seasonal or cyclical demand becomes a requirement if you are in a market such as the example I just mentioned.  This model of estimation also then lends itself to being able to apply resources in the most efficient and productive way allowing for the most optimal solution.

The other possibility is that you have worked with the client and developed a design build project where you are able to set a precedent during and upon estimation creation and delivery.  It is important in this model to inform the client that your estimation is based upon starting “X” date and current resourcing models.  If you pick up several other contracts while working with a specific client it is very possible the estimation model could change drastically and this would need to be communicated to the client as quickly as the change is realized.  Even once the decision to move forward is made, it should be the practice of your business to re-verify the estimate completion duration and possible start date, making sure to inform the client of any possible changes or impacts and the reasons behind them. 

What questions or concerns does this evoke in your mind?

Chris Thompson PMP, SSYB