Successful projects require accurate estimates of the effort required to deliver on the project requirements.
So where do Project Budgets actually come from?
Budgets for a project are set in various ways.
My times the actual estimate is the last consideration in setting the budget as budgets are often planned in advance and when the project team comes up with its plan then put it to management they are told they came up with the wrong answer and to replan.
One good thing about setting a target budget and delivery date is that it focuses the mind. At first it should focus the mind of the leader and then through them the entire delivery team. This can facilitated partly be setting well thought out incentives.
To ensure your greatest chance of success you need to identify and manage risks.
Some risks might be:
What you want to do is schedule these risks in a way that they reduce as your project progresses.
The Production Possibility Frontier is an economics term relating to the choice between producing 2 different products. Consider a farm community that produces both wine and cotton. Given they have limited inputs and time then producing more wine will mean producing more cotton.
At point A they produce more wine and less cotton. At point B they produce about the same of each. At point C more cotton. At point X they produce about the same of each but not the maximum amount possible. Point Y sits outside what is currently possible.
If the farmer’s technology improves by for instance hiring more staff, introducing irrigation or getting a tractor then what’s possible expands.
So now that frontier has moved outward it becomes possible to produce at point Y.
In software projects we talk about the concept of velocity. We can invest our resources in either 2 products:
In a future article I go into more detail on how to apply this speeding up your schedule. For now we are going to estimate a single sprint.
For this exercise we are going to develop and estimate for a a new invoicing solution we are calling Super Invoicing.
The first step is determine what components this solution will have. We need to determine the requirements. There are generally 2 types of requirements:
Functional requirements are about a specific feature of the solution.
Non-functional requirements apply across the solution.
Let me give you an example. Consider the following requirements:
In this case the first two requirements are considered non-functional as they apply across all features and the last 3 are specific functions.
Now we need to break down the requirements into more detail. I prefer to use a mind mapping tool such as Simple Mind.
Not all tasks are created equal. To deal with this we attribute relative complexity to each task. In an Agile methodology we tend to use Fibonacci numbers.
1 – Simple task
2 – Fairly simple task
3 – Easy task
5 – Getting more complex
8 – Medium complexity
13 – Complex task
The number assigned to each task is called the story point value.
We need to map story points to actual time. This is a factor of the developer availability and capability. For this exercise we estimate the average developer on the team can complete 2 story points per day. This equates to the “Velocity” of the team. We also estimate from experience developers work 6 hours per day on the project. You should be able to slowly increase a team’s velocity over time but hours per day will be fairly static.
The planning worksheet is designed to give a snapshot of a project. Both an initial estimate and actual progress over time.
To use the worksheet enter in the project details in the highlighted yellow cells. Also enter the actual completion dates as each task is completed.
As tasks are completed the actual completion date is entered into the worksheet. On the worksheet tabe called: Earned Value you can check the project performance.
What you want is for the dashed green line (the “Forecast”) to track dashed blue line (the “Target”). In the example below the forecast is slightly above the target so the project is slightly ahead of schedule.
Succeeding at custom development projects requires attention to detail in planning and diligently tracking progress, taking corrective action when required.