With the Goal feature, I am attempting to track Productivity for my team. Something like, “Track Projects by People Workload (Capacity) over a given Period with a goal of maintaining 80% Workload daily”. Ideally, I would see which of our People are below, at, or over 80% capacity Quarterly.
Our team works on projects and primarily do Design work. Good for us, the work is endless, so its about managing Workload capacity in a traditional sense but, also ensuring people are productive based on the projects they are supporting.
What would be the best way to approach Goal setting in this way leveraging the Workload feature using Hour Estimates on Projects for each of my team members?
First let me respond to your question. From what I understand there is no functionality that connects workload and goals.
What you can do is:
add the projects to a portfolio
utilise the workload feature and select estimated time where it says task count. This should add estimated time and actual time for all projects
It will also ask to add the capacity for all portfolio members, which you’d then set to 80% of their working hours
Then, to get a complete picture estimate the time for the tasks in the projects and add start/due dates
Set the resolution to Months (large) and you will be able to see their capacity at about the scale you want (depending on your desktop resolution/scaling)
Note that everyone needs to have set their working days correctly, and multi-day tasks will be spread out equally over the scale you are looking at. Here is the same task looked at in different scales:
To my knowledge it is not currently possible to view a percentage.
Measuring what matters
Having said that, I’m a process improvement professional and I haven’t seen just measuring/aiming for a utilisation target lead to desired results.
I’m guessing in the end you don’t care about utilisation as much as you care about improving the flow of value to the customer.
This might go a bit off topic for the Asana forum, so let me know if you’d like my perspective on this. Then I’ll reach out in DM to set up a virtual coffee.
First off, thanks @Jan-Rienk for a well thought out response. Currently, what you have detailed out is how I am running my teams today which is great at estimating Workload. Eg. Using the tool as designed for Capacity management.
I agree, if setting a single target for +80% Capacity was the only goal criteria for my team, it would likely result in team members padding Hour Estimates for the work they are doing leading to lower productivity. This is just one of the dimensions I want to tackle in addition to the other metrics I use today. It tells only part of the story for my 3 teams I manage.
I guess I should have been clearer, my teams support as an Enterprise Training function but, they support design in a number of capacities including multimedia, graphic, illustration, instruction, performance improvement, all of ADDIE, project management, and more. They are a busy group. So busy, that the need for Asana and Time Management is critical for us to continually delivery value. Seemingly small things can erode people’s capacity and alternatively, seemingly large things have huge gaps in them due to dependencies and wait times.
The goal with this metric is to smooth out the peaks and valleys as much as possible by understanding capacity per Quarter. Teams can have equally (perceived) number of projects but wildly different demands on their time based on complexity of work, the client, the depth and breadth of the solution design. All play a factor in our demanding environment. So, that’s the back story.
To create flow you need slack in the system. Focusing on maxing utilisation is like focusing on maximising the amount of cars on the road, and then wondering why no-one makes it to work on time.
The higher the variance in task size and arrival between tasks, the further you want to stay away from 100% utilisation as per Kingman’s Formula.
To be honest I don’t think Asana and traditional time management is going to solve this for you. I’d advise to focus on Theory of Constraints first, and perhaps use Asana to support this effort. Not the other way around.
Absolutely. Lots covered but, as a PMP(c), Agile certified, also Greenbelt, the PMBoK and Scaled Agile Framework (SAFe) have great models for dealing with iterative value delivery models. Also, the Critical Path method in traditional Project Management helps us deal with the key deliverables that our clients need.
To use your analogy, dealing with and managing all those cars on the road takes a lot of rules and coordination. Lanes designators, driving standards, speed limits; all of which help drivers navigate the path to work every day with so many cars on the road. Sometimes we cannot manage how many cars are on the road but, how to best manage the traffic and flow (or WIP) through management the use of stop lights, one-ways, or right-of-way signs. Great dialog. These challenges need talented minds to coordinate, like yours Jan. Much appreciate your contribution.
You may be right about Asana. Though rolling out Agile transformation across the organization might improve overall, it’s not the current state of our environment. Therefore, Asana is a great solution to gain visibility of work from what I was using. Though in previous roles I had access to Rally, JIRA, and Confluence to help. As far as a plug-and-play all-in tool, it does get us to a much better place of transparency, responsibility, and organization.
Sure. And there is a lot of Theory of Constraints applied in those.
Please note the critical path function in Asana doesn’t display the critical path correctly a.t.m.
See the Improve critical path topic. (FYI I’ve just today reached out to Asana through support to see if we can get this fixed)
