Do you apply mathematical formula to calculate numbers of staff
I know it depends on project size but initial set up calculation and what percentage minus plus on final staff numbers Saving Changes...
Sort By:
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Some rules of thumb:
1. PM = 15% of the Budget/Effort
2. BA = 20%
3. Build = 40%
4. Test/Validate = 20%
5. Deployment = 5%
Using the average daily rate (i.e.$1000/day) you can get the days/FTE.
I recommend to do use this model after you have a draft/HL WBS.
Of course it depends of the type of the project. Saving Changes...
If you are following a flow-based delivery approach, you could calculate team size using Little's Law.
For example, let’s say that we have a project with an estimated 400 stories left with an average lead time so far of 0.75 weeks/story. Let’s also assume that we want to complete this project in 10 weeks.
Average WIP = 400/10*0.75=30 work items
We then need to ensure that we have sufficient team members to handle 30 work items in progress.
Kiron
...
1 reply by Riyadh Salih
Dec 09, 2018 10:55 PM
Riyadh Salih
...
Kiron, good i like little's law I applied in lean manufacturing as lambda is average arrival time and to figure waiting time with theory of probability I wasn't aware that you can use it to calculate project staff including those who take care of building maintenance.
I've done it several different ways and it depends not only on the size, but on the cost structure. For example a capital intensive development project is going to have a very different percentage of labor than something in a service industry. Similar projects should have similar percentages though unless there was something unusual about it. In some industries you can actually estimate the total cost by product weight, and know labor is x% of that cost if you have the historical data.
The total number is one thing, but it is also important to translate the total amount of labor required from what we call "equivalent heads" based on the total number of hours, to physical "belly buttons" or actual people employed on the job. For that, I basically spread the hours over time and figure out how to adjust them based on how the real world works compared to raw percentages.
...
1 reply by Riyadh Salih
Dec 09, 2018 10:59 PM
Riyadh Salih
...
Keith, nice feedback taking in consideration the detailed SOW and backlog of all related work to be done is a good realistic to calculate the size of team required.
If you are following a flow-based delivery approach, you could calculate team size using Little's Law.
For example, let’s say that we have a project with an estimated 400 stories left with an average lead time so far of 0.75 weeks/story. Let’s also assume that we want to complete this project in 10 weeks.
Average WIP = 400/10*0.75=30 work items
We then need to ensure that we have sufficient team members to handle 30 work items in progress.
Kiron
Kiron, good i like little's law I applied in lean manufacturing as lambda is average arrival time and to figure waiting time with theory of probability I wasn't aware that you can use it to calculate project staff including those who take care of building maintenance. Saving Changes...
I've done it several different ways and it depends not only on the size, but on the cost structure. For example a capital intensive development project is going to have a very different percentage of labor than something in a service industry. Similar projects should have similar percentages though unless there was something unusual about it. In some industries you can actually estimate the total cost by product weight, and know labor is x% of that cost if you have the historical data.
The total number is one thing, but it is also important to translate the total amount of labor required from what we call "equivalent heads" based on the total number of hours, to physical "belly buttons" or actual people employed on the job. For that, I basically spread the hours over time and figure out how to adjust them based on how the real world works compared to raw percentages.
Keith, nice feedback taking in consideration the detailed SOW and backlog of all related work to be done is a good realistic to calculate the size of team required. Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Riyadh, there is an entire discipline on project estimation (sizing) based on function points. have a look at ISBSG's website. After spending some time leaning project benchmarking I have big concerns about the simplistic approach of using story points and team velocity:
velocity:
1) it is too subjective and very inconsistent. For a 10 Sprints release with a 10% variation you you can miss an entire Sprint. 10% variation between sprints is very optimistic.
2) it doesn't factor any other costs than the development team. From my experience in a software development project the cost with the developers can be as low as 20% from the total cost (licenses, project management, Business SMEs, change management).
3) law's law won't work on most of the projects. Even software development is no longer coding. Most of projects these days are platform configuration and integrations rather than customisations. A project delivering a custom developed application is very rare outside software companies. Saving Changes...
Kiron, (Item in system) L = lambda (Arrival rate) x W (wait time in system) This is Little's law so can you elaborate how you use it to size the project staff. Saving Changes...
