You may remember me mentioning an SOA/ESB project we have underway at the moment … as the “customer” for the outsourced development, it has been my weekly task to approve timesheets for the people involved (as a precursor to the bill!). Most weeks I make some snarky remark about it, and refer the project manager to a blog entry somewhere that derides the use of timesheets.
Occasionally, he is moved to react. and always defends their use as necessary to tell the story of how the project is progressing. He challenged me to come up with a better mechanism to track task completion …
He has completely missed my point (which is MY problem, of course, not his) – the timesheets aren’t the issue. They are merely a symptom of a (to me) wrong-headed mindset that time spent on a task in any way resembles completion of the task.
While I appreciate the necessity in a business environment to have an end date in sight, the whole success rating of the project has to take into account whether or not you achieved the business goal(s) originally conceived. For instance, with the ESB project, we have been quite comfortable with the number of hours worked, the dollars charged – we’ve even been able to add in some functionality without blowing the effort or cost budgets. Trouble is, it’s intention was to assist in grape intake planning, and we’ve nearly finished the harvest, so its usefulness this vintage will be minimal (there ARE mitigating circumstances). So is this project a success?
The flipside is the ERP implementation also happening … this is over budgeted cost, solves no business problem, doesn’t reduce any limitation and is functionally poorer than what it replaces (please don’t ask the obvious question…) – but it will go live on the promised date. Is THIS project a success?
My point? Providing the business with parcels of functionality (and there is plenty to discuss about the relative size of those parcels) that provide value is the basis for meaningful milestones, not an arbitrary date on the calendar, nor the number of hours consumed.
If you want a more coherent discussion of this sort of project measurement, you need to check out Glen Alleman’s (aptly-named) blog Herding Cats, as well as Scott Berkun and Frank Patrick.
Technorati Tags: projectmanagement, project, measurement, value
“Nirvana” it certainly is, and I will continue to pursue it! You are probably right about the lack of experience – but we have to start somewhere … and that’s the reason for a small project. The point of the project IS to provide functionality; the choice of an ESB architecture is (at least partly) to gain the experience.
PS – that sounds suspiciously like a sales pitch, NIck 🙂
I think this Nirvana of being able to focus Milestones on delivery of end user functionally, requires an Enterprise Architecture and an IT Architecture with the ability to be able to quickly assemble capability through Portal technology. An ESB is an abstract piece of infrastructure, that helps facilitate the delivery of functionality, but itself delivers no end user functionality. So the Milestones for this type of project will be different. In essence Milestones should deliver something of benefit to the project that is of a quality that enables further capability that is of benefit to the project or program as a whole. Missing Business time frames is normally a sign of a lack of experience within the project team with the intended Enterprise and IT Architecture. Additionally I would say that the existing burn rates would be on implementing Foundation components in the nuances of a foreign environment.