1

I'm trying to figure out the best method to address this issue. We have a pool of resources that work on projects, BAU, and production support. PMs utilize these resources in an agile methodology and report time in JIRA on their tickets for product features. The problem is that I need to report these resources' time up to Corporate using MS Project Server.

Project schedules are difficult to maintain because resources change in and out of tickets throughout the project, or a resource may contact a PM to say they worked on their project but didn't see a line item to report their time. The PMs go in, create the task, request hours needed at a t-shirt size (which could change).

How can I create a standard process and/or procedures and some type of project schedule to address reporting work, resources, and budget on an ever-changing project, with a process that allows me to adjust resources on the fly whether daily, weekly, or hourly?

  • Are you using an agile framework like Scrum or Kanban? Something else maybe? Do you have teams? – Barnaby Golden Apr 1 '16 at 18:54
  • We're using Scrum....they don't have dedicated teams....it's just a resource pool. – Cicely Mason Apr 1 '16 at 19:25
1

OK, a few suggestions:

Scrum is designed to work with dedicated teams with a known velocity. This makes it easier to predict the capacity of the team in each sprint and hence makes it easier to plan.

Ideally a Scrum team will work on one thing at a time, but in your situation it may be necessary to have them work on a mixture of project/BAU/support. Some Scrum teams will dedicate a percentage of their capacity to BAU/support. For example, they may say 20% of the capacity of the team will be available for BAU/support and the rest will be spent on project work. If you do this it becomes easier to plan the projects. Say you have a team with 5 members. In each sprint you can have one team member dedicated to BAU/support, leaving the remaining 4 members to do project work.

To successfully use Scrum you do need some requirements stability. A Scrum team has stability during a sprint and then accepts change (i.e. new work, changes to priorities, etc) at the sprint boundaries. If in your organisation things change very rapidly then you could consider a short sprint duration, say of 1 week.

If it is not possible to get requirements stability even for a week then you might want to consider using Kanban instead. This is a continual flow of work that is tracked on a task board rather than working in fixed-length sprints.

One other thing worth considering is allowing team members to create their own tasks in JIRA. That way they do not have to continually ask the Project Managers to do this for them. It is possible to configure JIRA so that all new tasks/issues generate an alert email to a given role. You could configure it so that the Project Managers are notified using this approach when new tasks/issues are added.

  • Thanks Barnaby, they create their own tasks in JIRA, PM has to add in MSPS. How do I create a process or manage (for lack of word) continuous resource changes in MSPS? One idea we came up with was to just have the following structure but I don't think this is the best solution: .. .. <<Project Name>>Planning - Developers ..<<Project Name>>Planning - Architects and etc – Cicely Mason Apr 1 '16 at 20:20
  • The simplest solution is to reduce the frequency of resource changes. But I'm guessing that may not be possible in your organisation. You could consider using a plugin like Tempo in JIRA. This would allow you to get a detailed report of who has been booking time on each project. You could them export this data and import it into MSPS. Not an ideal solution though. You may even find that your corporate people would be happy with the Tempo reports and not even need MSPS. – Barnaby Golden Apr 1 '16 at 20:25
  • Ok thank you. I'll try that but I agree. I'm thinking we are going to have to get those resources under control and people are not going to be happy with me – Cicely Mason Apr 3 '16 at 12:17
1

TL;DR

You are struggling because your JIRA ticketing is not aligned with your real-world process. In addition, you are trying to make your ticketing system your source of truth for time reporting into a separate system, which introduces a (possibly unnecessary) layer of indirection.

Long-term, you should fix your process so that the tools you're using are aligned with your real-world workflows. Shorter term, you should use the available features of your tools to capture time data directly.

(Ab)using JIRA Epics

Use the "Log Work" function of JIRA to track hours spent on tickets. If your process is highly chaotic, and the goal is to track time spent rather than use JIRA to track the progress or completion of deliverables, then just create some high-level tickets (e.g. Epics) which can be used as per-project bucket for resources to allocate their time to. This is clearly not The Right Thing to Do®, but may be useful in a pragmatic sense.

JIRA Plugins

JIRA has some limited built-in time reporting, but you may also want to look at the variety of plugins available for this type of functionality. Whether any of them is suitable for your use case is highly subjective.

MS Project Server

Also, consider that you are not locked into time reporting within JIRA. You might choose to use JIRA for ticketing, and use MS Project Server with some per-project buckets to track time. Since you have to report the aggregates in MS Project anyway, making it your "source of truth" for time reporting just makes sense.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.