Are You Planning to Fail?

When a client comes to you asking to have a project completed, what is your process for deciding whether or not to take on the engagement?  I understand that in today’s economy the thought of turning away work or passing up a potential contract may seem unfathomable, but what is more damaging, not completing the project on time and losing future business or managing your project workload allowing you to meet client expectations?  I have experienced many companies that fall into the trap of underestimating (or not estimating at all) the project’s scope, which led them to inadequately resourcing the project, causing the project to extend pass the delivery date, thus moving into the resource needs of projects slated to start at its conclusion, and a laundry list of other problems.  

How does this happen?  First I would ask, does your business operate on a queue system or a projection system?  In a queuing system projects are put in the pipeline and once a project ends, then the next one in the queue takes its place.  In a projection system, a business comes together at either a monthly, quarterly, biannually, or possibly yearly to slate projects for projected start dates.  Which is better?  That answer depends on whether or not you are planning to fail.

Consider that in order to complete a project successfully, it needs to be done on-time, at or below budget, and most importantly fulfill the requirements of the client.  That seems like a relatively easy scenario and just good common sense, but this is where I see and hear about companies falling apart in the overall planning process.  Rather than spend time dissecting what businesses may do wrong when planning for future projects, I want to go through the process I believe to work the best.  Hopefully this can provide a framework to how you may incorporate these ideas into your business if you are having a tough time with managing your project load.  

Within the realm of accepting or declining a project, the ability to accept that there will be some overhead costs associated with the process is important.  When a client comes to you asking that you either help them with a design build project, or estimate an RFI to hopefully win the award of a contract build project, you must handle the interaction moving forward in a sequential process.  For this article, let’s consider the client comes to you with a design build opportunity.  The client is going to have three main things they are trying to achieve, 1) fulfilling their need with a product that meets their requirements, 2) a project completed at or below a particular budget, 3) a completion time that falls in line with their needs (whether that around a budgeting constraint or expansion need, etc). 

In order to begin the process you need to follow the entire project management process.  This is a time when many businesses will go directly into discovery or requirements gathering thinking this will flush out the entire scope of the project.  This can be a terrible mistake.  Consider that although gathering the requirements will help you develop the scope of work needed to complete the product, but it doesn’t allow you to consider possible requirements relating to stakeholder communication or reporting.  This is why starting from the beginning is important.  Begin by working with the client to develop a complete list of stakeholders for the project.  This is paramount so that you can capture some of the future components developed in planning that will be mentioned later. 

Once you have the list of stakeholders, and this can be both internal and external, and include people or organizations that instead of being directly touched are indirectly affected, do an analysis of their needs.  Find out what is important to each stakeholder.  Doing so will help with development of the communication plan, scope, and possibly will give insight into the risk analysis and administrative needs that will be required of project staff.  

Now that you have a stakeholder list and analysis, you are ready to develop the requirements needed to produce the end product.  Once these are captured, and it may take several discovery iterations, you can develop scope.  Since scope is the work required of the PROJECT that will also deliver the PRODUCT, this is where the stakeholder needs will be addressed.  This is an important concept many fail to comprehend.  A project and product are two separate items.  The project is going to be inclusive of stakeholder needs, ancillary tasks and items that are a result of project engagement, and requirements of the product that then produce the end result.  

Once you have developed a work breakdown structure, or WBS (which is simply the act of breaking down each piece of scope, or work, which will need to be completed to satisfy the requirements) you are then able to estimate the resources needed to complete the work.  In order to do this accurately the WBS will need to be detailed enough for the size of the project to closely estimate the amount of labor and or materials that will be required to complete that portion of work.   Once you have estimated the resourcing needs, it is then possible to schedule the activities.  This is another area that can throw people off.

Scheduling and assigning resources are two separate items.  Consider that scheduling is nothing more than putting the work items in an order that allows for the most logical sequencing that accounts for dependent tasks while considering completion times and available lags for starting or completing an item.  Once you have sequenced the work that is to be done, you can then assign available resources, labor or materials, to a work piece relying on your resource calendar.  Make sure before you apply resources that you are referencing the time-frame the client is aiming for.  This is very important.  Why?

If a particular piece of work is to take 1000 man hours (or whichever units you utilize in your estimation process) then the amount of resources you have that can be dedicated to this effort will affect how long (relating to calendar days) it takes to complete this item while also considering the concept of diminishing returns of production regardless of the amount of people you throw at an item.  Even though the task may be 1000 man hours, it isn’t possible to put 1000 workers on the task to complete it in an hour.  This is also a topic covered in the “Mythical Man Month” by Fred Brooks (a book that explores why throwing labor at a project, unless properly planned, extends the projects length because of decreased efficiency and rework).  So this means you also need to have a well-developed resource calendar in place.

A resource calendar is something that shows the availability of resources at any given time based upon the commitments they are already assigned to.  A key item to keep in mind when resourcing (and probably needs expansion but won’t be covered in this post)is you should only resource at roughly 80% of capacity.  Although you are taking the time to estimate and plan ahead of time, things come up.  It may happen that a project will push for uncontrollable reasons and this may cause projects to overlap that weren’t originally sequenced in that way.  Keeping your resourcing at 80% which will help with this possibility and can also allow you to take on change order additions to your contract and handle those last minute emergency needs of your clients.  

So, now we have a WBS that lists the scope of work to be completed, and have now scheduled each item and have applied your available resources accounting for the client’s timetable, it is now possible to estimate the duration of the effort.  How does this fall into the queuing system of scheduling future projects I mentioned earlier?  If you are estimating as described in this post, you have already put the project in the queue when you estimated the project.  You did this after you scheduled the activities and before you assigned resources.  Remember that in order to assign resources you must first know when the client wants to take on the project and compare that against your resourcing calendar so you can apply resources.  If the client accepts your proposal then it is slated to fall where you estimated the projects start time.  

If you aren’t estimating before you tell your client when it can start, or before you tell them how long it will take you are most certainly planning to fail.  Yes, this process does carry with it the wasted time and effort made towards projects that are never completed.  I would offer however, that if you are properly estimating projects and keeping your queue full then the added overhead should pay for itself by completing a majority of the planning upfront and expediting the time it takes to begin an engagement.  

Chris Thompson PMP, SSYB