Using the Project Plan for scheduling

If you are making a cost quote, all you really need are the total hours required to implement the solution. The project software program you use should be able to compile a total number of hours for you. But the schedule basically comes for free, or at least takes a minimum of effort. Moreover, including the schedule can have an impact on costs.

But the primary reason for developing a schedule is that the customer will inevitably ask for at least a ballpark quote of how soon the solution can be delivered when he is given the cost estimate. The scheduling part of the project plan will provide that.

It is often difficult to provide a specific schedule commitment when providing a cost estimate (saying, for example, that the solution will be delivered 24 weeks after receipt of the order). The fundamental problem is that it does not make sense to begin work before an order is received. If you don’t know exactly when the order will be received, you don’t know if it will compete with other orders. (While having many orders come in for custom software development is actually a good thing, it does create at least the potential for competition for key resources.) Once the order comes in, you should be able to commit to a specific schedule.

Certainly one factor is the size of the order. If the order is large, consisting of multiple person-years of work, it should be possible to plan for an amount of time to get the necessary resources together and then provide the customer with a schedule commitment at the time that a cost estimate is created.

On smaller project, it is my experience that multiple orders will come in simultaneously (or nearly simultaneously). I’m sure a part of that is due purely to Murphy’s Law, but another part of it involves the way that businesses purchase things like custom software projects. The process that they use is to get an estimate, work to justify it, add it to the company’s budget and then actually order it when the fiscal year begins. I received more orders for new custom software projects during the first month of the calendar year, and certainly during the first month of each quarter, than during the other parts of the year. This is because business fiscal years tend to align with calendar years, and they nearly all align with the beginning of calendar quarters.

Occasionally – especially when responding to an RFP – the customer will tell you when the order will be given to you (if they accept your bid). In that case it is reasonable to provide a commitment for a specific delivery date. Otherwise, I consider such commitments to be very dangerous.

In order to use the project plan for scheduling, you need to put in proper dependencies (e.g. task 2 depends on the completion of task 1). You should also make the schedule dependent on a single initial task (such as receiving the purchase order) which, if changed, will correctly change the entire schedule. It is easier to test “what if” sorts of scenarios when you do that..