Jayson ReadProject ManagerEden Prairie, Mn, United States
I'm trying to determine how best to measure my team's ability to deliver projects on the dates that we've promised to the business and how off we are from meeting those dates.
One method I've seen is to try to calculate the percentage between the number of days a project has been late and the duration of the actual project. For example: We work on a project with 8 person weeks of effort and we end up deploying the project a week later than promised. That would be approximately 12% over what was promised using that methodology.
I have to think there's a better methodology out there to calculate delivery metrics on projects and how we (as a team and me as a PM) are doing with regards to meeting those promised dates.
Thanks in advance to all who can assist! Saving Changes...
Sort By:
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Jayson
Interesting question. If we had the right metrics project management would be no longer an art but a science. Please find below my approach to this challenge
At the start of the project I set the milestones based on top down planning. Milestones are all approximately 4-6 weeks separated. The duration is defined by dividing the effort by the project team, taking into account the team dynamics, and to assume each FTE is only available 4 days a week
The 1-day off is to compensate for holidays, illness, study and unexpected leave. In Europe where people tend to have three-week holidays I also add 2 weeks to the duration of the project to cater for summer holidays and/or X-mas holidays.
In most cases this plan can be met under normal circumstances.
Now the proof is in eating the pudding. The above is a model with no respect to the individuals on your project. The next step is to ask each of the project resources to provide a planning of the activities for the coming 4 weeks. This gives you a clear indication if the first milestone on the critical path is achievable. At the end of the week you sit with each of the resources and determine if the planning is met. Adjustments to be made for the next week and also a new week 4 to be planned (the rolling forecast). After the second week you have a pretty good understanding with respect to:
- Planning capabilities of each of your resources
- The deviation of your overall top down activity planning versus the actual time spending on the activities
With this information you can start to forecast what will happen to the milestones ahead and the end date of the project. A couple of guidelines I tend to use for myself are:
- Catch up of lost time is not possible
If it happens ones in a while it will add nicely to my contingency buffer
- Work needs to be completed in the phase it was scheduled. Otherwise the milestone is always met and only the end date of the project shifts after the last milestone has been achieved
Hopes this helps
Kind regards Hans
Saving Changes...
Andrew BallSenior/Head of PMO| a3g LtdAshford, United Kingdom
From a PMO perspective I am only interested on the number late, not the amount of overrun, other than a cost basis. It is far more important to understand why delivery is late and the cause. This can be gleaned from PIR and investigation which leads to Lessons Learned and feedback circle. This will identify whether it was weak estimation during the planning stage, which can be down to over enthusiasm or a lack of experience. It can identify ever changing Customer requirements and a weak Change Control Process, or scope creep and the PM not saying NO when needed.
I feel a percentage can not reflect the reason for the delayed delivery which can be addressed just provides a meaningless number that quantifies nothing.
My interest would rather be in the percentage of Projects late not the percentage late.
Hope this is constructive and does not come across overly negative. I generally limit my reporting against the 3 project constraints, add in finances if available, EVA & Burn rate. resources can be included if captured but to create stats to fill report lines is an approach I avoid. Keeping it simple works without generating suspiscion. Saving Changes...
You can measure number of requirements that were met as per the schedule. You can also measure the number of defects in the deliverable. No. of change requests handled during the project. Time spent on re-work. Delays caused due to availability of resource. Number of lines of code developed.
> days a project has been late and the duration of the actual project. > For example: We work on a project with 8 person weeks of effort
> and we end up deploying the project a week later than promised.
> That would be approximately 12% over what was promised using > that methodology.
When you find a deviation, it is always a good idea to find the real reason - incorrect estimation (time), incorrect estimation (lack of team member skill), etc... there may be so many reasons. These can go into the lessons learned.
Hi,
I am working on building different metrics around the SOFTWARE DEVELOPMENT Projects.
Now I have been asked to present a Power point presentation on different metrics that we can measure on any general software development projects.
The department I work for has got different projects on JAVA development, SAP, DATABASE etc…..
Now I am clue less to know what are the metrics that can be presented.
PLEASE HELP ME ……
Saving Changes...
vishwa gopiQuality facilitator-Test Lead| TechnosoftChennai, Tamil Nadu, India
Interesting! Hans...... Saving Changes...
Jayson ReadProject ManagerEden Prairie, Mn, United States
That is all very helpful. Thank you for your insight and advice. Saving Changes...
I am looking for sources of information pertaining to quantifying % Complete on software development projects.
I'm familiar with MS Project's various measures (i.e., %-Complete; %-Work-Complete; Physical-%-Complete, etc.) and the differences between these...
What I'm REALLY after are clear guidelines for quantifying the work to be done so that Earned Value Measures of performance in my software development projects are more meaningful.
Any suggestions or references to materials on these issues will be sincerely appreciated!
