I currently manage a few teams of developers. Let’s say Team A, Team B, Team C.
Each Team has X many resources, and tasked to deliver a set of software projects. So as an example Team A has 3 resources, tasked to deliver 3 software projects. There are 2 project managers tracking these 3 projects, each on a separate schedule.
As a software manager, my team is agile. So in Team A, resource 2 picks up tasks on resource 1's schedule etc. So resources within teams share workload to drive the overall target forward.
My question is, how does a Project Manger effectively allocate and track tasks? I want the Project Manager to assign all resources in a team to all 3 projects, so that if they pick up tasks they can easily book time to timesheets without requesting the PM to allocate them to tasks.
So am looking for a solution here, or suggestions from those that have had a similar issue. I’ve been reading on Effort Driven vs Fixed duration but I’m not convinced that this is the way to resolve the issue.
Saving Changes...
Sort By:
Mark KromerTechnical Product Manager| Oracle CorpOviedo, Fl, United States
In Agile teams, wouldn't you rather have the teams self-organizing as opposed to having your resources managed by a PM who assigns tasks to resources? Or are you assuming the PM is a Scrum Master? Saving Changes...
Reg CoppicusManager IT Infrastructure| City of BrandonBrandon, Manitoba, Canada
Do you require tracking by person/resource? If not simply track tasks by team, per project. This way Team A with 3 resources can work on 3 projects. You might not have the1st person working on the 3rd project, so you have to ask if you care? Your Team has three person days worth of work available per 1 day of time. So on any one day you can have 5 tasks to be done over two different projects with three people. You can just Gantt that as 5 concurrent tasks for the day and figure out dependencies, assign to Team A instead of individuals. Not sure if that helped. You can also predict shortages of resources this way, as one week if someone is on vacation, then Team A has only 2 Person days of work per day available for that week, assign tasks accordingly. This way the team members can pick up tasks and report what the "Team" worked on and self-assign. Saving Changes...
Linda HillProgram Manager| MicrosoftRenton, Wa, United States
Mark has a good point that is consistent with Agile practices. Also I wonder if you really want to add all this complexity? Saving Changes...
Mark: My teams are self organised. I manage my team and allocate tasks to them as i feel necessary. The PM manages the schedule, and this is where we experience issues, because as a team we utilize the man days to achieve tasks. We focus our energies where needed.
Reg: I don’t care which team member works on which project. But the PM cares as he puts together the schedule where he assigns resource 1 to project 1. Now when i get resource 1& 2 to finish up tasks on project 1, the issues start to arise as resources cannot allocate time to tasks as they are not assigned to the task (hope that makes sense :-) ), so the project plan shows the project is in red, but we are actually on track.
Linda: I really don’t want to add complexity. My teams need to focus on getting the work done, and that what we want to do. Just seems like the team gets bogged down by Admin on a project plan.
Update on the way Forward: I sat with the PM's, they proposed something that i feel will work. Let's say Team A has 3 projects. Each project has 1 resource. However i may move 2 resources to a specific project for a period of time. So the proposal on the table is to create fixed duration tasks, which the developer provides estimates. All resources in Team A will be assigned to all projects Team A works on. As resources complete work, it is allocated to the task. The PM is then happy he can track progress. Resources have happy that they are not tied down to project admin. We also reduce meeting time as task updates will be submitted daily and progress can be gauged every morning, without us having meetings to feedback on developer progress.
Saving Changes...
Andrew MakarProgram Manager| AMAKAR LLCOakland Township, Mi, United States
You've actually raised several issues in your opening question.
If I can paraphrase:
1. What do I work and and what do I bill?
2. How do I track who is working on what task and when happens when I add a new resource?
1. With this first question, I would separate the detail of what the resource works on from what they bill in a timekeeping system. At the end of the week, the resource can review his work product and bin the time appropriately. If you try to track everything, you'll get lost in the administration...and to be honest, more PM overheard isn't beneficial to working software.
2. Regarding the 2nd question, you used the word Agile, but are they really applying the iteration/release mindset that comes with Agile? If the team was using Agile, your iteration plan would indicate who is working of what for your 2-4 week sprint, but the billing would be done on a weekly basis. This further enables collaboration over documentation.
In MS-Project, I would first start by assigning 1 resource to a Fixed Work task. This implies you've estimated a task to be fixed, no matter how many resources (units) or how long it takes to complete.
If a task takes 40 hours and resource A works on 20 of those hours, you can always assign another resource in MS Project to work on the remaining 20 hours. Even if the task exceeds the original baseline hours, this approach will allow you to assign work to each resource.
But if I was truly Agile, I'd set the timeline for the iteration, let the teams develop the software and the incomplete work can get cascaded to the next iteration. Then by measuring the number of user stories (requirements/use cases), you can determine the teams velocity for future planning.
Do you see how this approach focuses on the delivery of the software rather than the billing and administrative tracking?
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Mahendra, great post..!
I quite agree with Andy, Mark, and the others. I would only add the following advice. Once you decide the approach to take, do three things.
First, give it a name. Why not Mahendra's Agile Practice or just MAP.
Second, explain your approach. Don't choke the horse with details. Just describe your approach so that you and others are actually adhering to it as opposed to engaging in ad hoc best efforts.
And third, improve and refine your approach. There is no better way to find out the best way to approach a task than to put an approach in place and based upon execution experiences and team feedback, incorporate ways to get better at it.
Again, don't choke the horse. Keep it relevant, agile, and driven by business need - all of which are subject to and need to accomodate ongoing change. Saving Changes...
