We are trying to breakdown our time spent project managing into time codes for PM related tasks. Does anyone have any idea on the best way to structure this ?
Perhaps its by process phase (i.e. initiation, planning etc) or maybe by task (ie client meetings, project plan development, status reporting) Saving Changes...
In our company we track time ( via a timesheet) by task). Each task has an "owner", and that owner can approve that particular line on a time sheet that is specific to the task. The task owner cannot approve his own though.
on the timesheet we can also distinguish between types of time. For example, travel time, time spent in meetings, etc. It is all automated and team members have not complained (yet) Saving Changes...
In our company, the PM time is added into the project cost. So the PM puts the timesheet in the project. So all of us have atleast one project in which we can log our timesheet. Saving Changes...
at our company as well: PM time is also accounted for. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
I see three scenarios:
1) set project management as a specific task possibly with sub-tasks for each project management element and/or project phase. No pm charges to the technical tasks.This forces people to recognise that pm in itself has merit and requires effort.
2) apply pm effort as a percentage to each technical task recognising that each task has an element of management.
3) charge the actual pm effort (hours) as applied to specific tasks - useful on small-ish projects where the Project Manager actually is responsible for contributing to (or actually completing) each/some technical task. Also responds to clients that believe management is not a chargeable service.
To what end? Understanding it in total might be helpful if it was budgeted or sold to the customer as a line item, but what is the benefit of a more granular breakdown?
...
1 reply by Wendy Amy
Sep 21, 2021 4:15 PM
Wendy Amy
...
I think it would help our PMs who often also act as SMEs, not to combine tech hours with PM tasks. Thoughts?
I'm not sure who the "we" are and if you are referring to the time of the PM themselves, the other team members interfacing with the PM, or both.
For planning purposes, I break my own time down in the WBS based on the major milestones, and what activities are required to close them. In a large project, that will be a rolling wave because we don't know what the big hurdles will be up front.
Large activities will be discretely broken out and generally map to project phases (work statement development, major design reviews, integration milestones, etc.), but for general coordination, status, and other ongoing processes, I will just assume some baseline level of effort rather than trying to count meetings. For teams supporting PM activities, there will also be an "integration" portion of the WBS where they do the same.
As for tracking, we don't break them down to individual tasks. It's a lot of work and very error prone, so we just track the project level. For major events like a PDR or CDR, the associated hours can roll up into earned value, but the ongoing coordination doesn't break out that nicely. That's where the PM understanding what is really going on is required to interpret the data. Saving Changes...
I see three scenarios:
1) set project management as a specific task possibly with sub-tasks for each project management element and/or project phase. No pm charges to the technical tasks.This forces people to recognise that pm in itself has merit and requires effort.
2) apply pm effort as a percentage to each technical task recognising that each task has an element of management.
3) charge the actual pm effort (hours) as applied to specific tasks - useful on small-ish projects where the Project Manager actually is responsible for contributing to (or actually completing) each/some technical task. Also responds to clients that believe management is not a chargeable service.
Hi Peter - what sub tasks do you use?
...
1 reply by Peter Rapin
Sep 21, 2021 6:11 PM
Peter Rapin
...
I would first consider project phases as management tasks are specific to these stages. (take a look at PMBOC)
1) Concept/feasibility: - Business Case, Project Charter, Stakeholder consultation
2) Planning: - Project Plan including Cost, Time, Quality; Risk; Procurement; HR; Communications; Scope management
3) Implementation - control and documentation, compliance and performance review, staff management, trouble shooting.
4) close-out/turnover
I tend to track meetings as an on-going task possibly keeping regular project meetings and ad-hoc (issues) meetings separate.
Note, as with technical tasks one has to keep task size manageable in terms of effort and time. The complexity of the project and the level of control preferred should dictate the number and size of tasks.
To what end? Understanding it in total might be helpful if it was budgeted or sold to the customer as a line item, but what is the benefit of a more granular breakdown?
I think it would help our PMs who often also act as SMEs, not to combine tech hours with PM tasks. Thoughts?
...
1 reply by Kiron Bondale
Sep 21, 2021 5:44 PM
Kiron Bondale
...
I'd still suggest that keeping PM time as an overall bucket would address that objective without going down the slippery slope of detailed time tracking which a) smacks of micro-management and b) gets progressively less accurate the more detailed you go...
I agree with Kiron: why do you bother if it is not budgeted. Or maybe you want to get the granular if you want to start budgeting in the future. I know companies where the PM, as employee, is seen as overhead, and does not even fill in any timesheet. On the other hand I know companies where the PM is a part time function, and it separates and defines time out of necessity. Again, all dependent what you will use the information for. Saving Changes...
I think it would help our PMs who often also act as SMEs, not to combine tech hours with PM tasks. Thoughts?
I'd still suggest that keeping PM time as an overall bucket would address that objective without going down the slippery slope of detailed time tracking which a) smacks of micro-management and b) gets progressively less accurate the more detailed you go...
