Please login or join to subscribe to this thread
I would prioritize ease of updates. When trying to develop resource calendars for people in a matrix organization, it's difficult to try and manage more than a week or two in the future due to conflicting priorities that impact availability, and plan changes that impact your need dates.
At the detail level, the planned work may be constantly shifting so if your near-term resource calendar is time consuming to revise, it can end up more of an administrative headache than a planning benefit.
I'd suggest managing the work by product and value stream rather than by project. Identify the products and product owners who can set the team's priorities across all the requests, fixes and other work without the distraction of any project scope. That way your resource allocation is 100% and all the business priorities can be satisfied. You could also consider splitting the team into two, but split by product, not by project.
You can produce a Gantt directly in Jira (the "roadmap" feature) but Gantt charts aren't very helpful if your team is working on a backlog in fixed iterations. A prioritised backlog and a burn chart could prove more useful.
Hi Ed, I use a similar model for my teams - spreadsheet and Jira. Jira used more so to track requests that come in, any changes/ cancellations that come in for projects.
The spreadsheet is more to track the team’s utilization at project level/ task level/ skill set based and at resource level. Every allocation need to be treated like a ‘Project’. For example, bug fixes will be considered in itself as a project bucket. I use pivots to track utilization at skill set / team levels.
The other implementation method could be using Kanban board in Jira using the workflow that will work for your needs. Each task created as a separate story and assigned to individuals and the stories progress through the workflow. Using portfolio view you will be able to get the team’s allocations.
Hope this helps.
I do not know if you are talking about a plugin or about the method each one use for it. In my case, I use something close to Eliyahu Goldratt "Critical Chain" way of work which by the way is not something new because you can find the basement in the operative investigation theory.
I do agree with Keith. Sergio made a good point, too.
It'd be good to understand what you are trying to plan as it sounds like the people allocation has already been estimated and given their allocation to operational/expedite type work will be impossible to accurately forecast?
If you are referring to planning for when a given release will be ready, that is unfortunately not going to be easy with varying staff commitments.
Is there no way to work with functional managers to assign a portion of their team to handle operational work and the remainder to focus on project work?
Having resources allocated to various endeavours simultaneously is not optimum, specially if they combine project work with operational work like solving bugs. In these cases, bug solving tends to be in Covey's first quadrant (high urgency, high importance), with a direct and usually detrimental impact on project progress. Some organizations opt to have a "firefighter squat" fully segragated from projects. Ask yourself if it'd be better to have 6 fully dedicated developers than 12 half/half; plus, a smaller team is more maneagable, following Denning's laws of Agile (law of the small team).
Please login or join to reply