Crafting a better collaborative project management workflow with external suppliers using Asana.
In my position as project manager for native apps at NZZ I am often challenged to manage many external suppliers. We are using state of the art tools like Jira and Confluence but I was looking for a fast an simple workflow. This is what I came up with after one year of working at the NZZ and it changed the way we collaborate with our partners. First I want to explain why I decided to use Asana.
Asana is a web and mobile application designed to enable teamwork without email. Founded in 2008 by Facebook with the goal to improve the productivity of its employees.
Reading this I assume that you have an understanding how Asana works. This will be important to get this workflow in place. You will find good resources how to work with Asana and I am certain that you could start using this workflow within a few days. Furthermore you also could use this workflow on many other collaborative tasks management tools. I tested it on Trello and on Wunderlist. Still Asana remains my preference.
Asana is by far not my favorite tool for managing tasks but it does an amazing job for this kind of collaborative project management. Also the learning curve for new users is not that steep. I had everybody working on it after an one hour schooling. For small teams you can also use to tool for no extra costs which made it an obvious choice.
For each supplier I opened a dedicated workspace. This way I make sure each supplier only sees his projects. Each workspace contains at least two projects. One called Admin and the other one is the project master template. Let’s first have a look at the admin project.
The admin section
The admin-section is self explanatory. You can copy and paste the complete section from here:
12_Status Updates - Reviews:
As the name implies all tasks which are not necessary project relevant show up here. Admin is a steering project for all the other projects. If the complexity of your projects are getting bigger you can also make one admin section per project.
The structure supplied by me is just a template and you might want to adjust it to your business needs. There are 4 sections here which I explain in detail.
Any kind of task that does not fit in any of the other sections.
Tasks which are currently worked on.
The task is complete but won’t be closed until a other criteria are met. e.g. You are waiting on feedback before you can close the task.
Finished tasks stay in this section. They have no more assigned people and no due date. The project manager closes the tasks aver the weekly stand-up call. More to that later later.
How to work with tasks
Working with tasks stays close to the by Asana intended process. Every task you add needs to be assigned to someone. This person will be responsible for the task. The assigned person can change while people are working on it. The only important rule is:
The assigned person handles the task.
Whenever there is an update you leave a note in the comment section and assign it to the right person. This helps that you have a full history what happened in the past. Using «@» you can mention people or other tasks in the comment section.
How and why we use tags?
It is important that you use only as many tags as necessary. It is easy to use hundreds of tags. But this will not help you to structure your projects better. I decided there is two fixed sets of tags any tasks needs.
Every task will get on status tag and one priority tag. Priorities should be clear. 1 is the most important and needs to be done first and 4 is the least important and can be done at a later point. The status tags are important so you keep an overview what is going on. Each status also comes with a set of rules.
Everything is working fine. You will meet the deadline and your budget is under control.
Something is going wrong. Anyone can set the status «attention needed». Doing so he also has to mention in the comment section why that is. This status also implies that the project coordinators have to get in touch the same day and agree what the next steps are.
The one status you don’t want to see. Your project is in danger. As for the «attention needed» status you will leave an explanation in the comment section. But critical also means to you have to escalate this immediately to the upper management on both sides.
The project section
Here is where things get interesting. The project section is a mix between SCRUM and some kind of KANBAN. As with the admin section you can copy and paste the complete structure here:
Waiting for client review:
Cleared for planning:
Ready to implement:
In Review Test:
Accepted QA NZZ Test:
In Review Production:
Accepted QA NZZ Production:
Ready for deployment:
Selected for deployment:
Deployed and/or Done:
You have to understand, that this workflow reflects my exact needs at NZZ. You might want to do your own modification. Also you need to know that a task does not have to go trough each stage of this workflow. A new task could jump from «selected stories» to «stopped». This flexibility makes it easy to work with this kind of workflow.
So let me explain the different stages in details.
These are tasks and stories you don’t want to forget about. They wont have any assigned person nor a due date.
This is the next step in the workflow. The moment a task shows up in this section it is ready for your supplier. Now it will be his turn to move it to the next step.
Once your supplier has moved the task into this section you know that he is looking into it. If you have given the task a due date it can help your supplier to prioritize the tasks. Together with the «priority tag» which I have explained earlier he has will know exactly what to do next.
Shorter tasks or stories can go directly from assessment to any other section. But now and then your supplier will need to estimate the task. It might need more work than expected or he has to verify it with its specialists.
Waiting for client review
After estimation the tasks will wait here for you. You can check if everything is how you expect it and then have different options. If all is OK you can clear the task for planning. If you want to delay it you can move it to «On Hold» or if you decide not to pursue it you can move it to «Stopped».
Cleared for planning
Once cleared for planning you signal your supplier that you would like to pursue this task. It is now his turn to find a slot when to to the job.
Your task is planned and you know when you can expect its execution. As long the task remains in this section you still have the option to change priorities.
Before the next sprint your supplier will move the tasks he wants to do into this section. Once they are in the selected backlog you cannot ask for any more changes. This makes sure your supplier can do proper planning.
Ready to implement
This section represents all the tasks and stories which are in the sprint backlog. Even though they were in the selected backlog it can still mean that your supplier was unable to get all the tasks into the current sprint. This step is an extra checkpoint how your supplier is able to mange the workload.
Your supplier is currently working on these tasks. As before it can be that 15 stories were in the «selected backlog», 12 were moved to «ready to implement» but only 8 ever made it into the progress section.
In Review Test
The task or story is currently in testing on the stage environment.
Accepted QA Test
The task was accepted and passed the quality control on the stage environment.
In Review Production
Now you will the the same review on the production environment.
Accepted QA Production
Again the task was accepted by the quality control. This time on the live environment.
Ready for deployment
Since I am using this process for app development my deployment process looks a bit different. It can be that I have 10 new features but for some reason I don’t want them all in the next app update. All the done stuff which have to be released with a new app stay in this section.
Selected for deployment
Once I decided I want some of the features from the section above I move them here. The supplier know now, that he has to add those changes into the next app release candidate he is building.
Deployed and/or Done
The task is done, the new feature was deployed with the new app release or with some other software update. The task has no more due date and isn’t assigned to anyone. In the next stand-up call the task will be closed.
Task is on hold. It will be pursued or stopped at another time.
Task has been stopped. It won’t be pursued any longer.
As in the admin section every task will get a priority and a status and any changes need to be mentioned in the comment section.
As long as the tasks and stories keep the status «On Track» there is no need for any phone calls or e-mails. Updates can be found directly in the comment section of the Asana task. I recommend to have a weekly stand-up call. In this call I go with my supplier over every single task and quick verify following points:
- Is the task at the right point in the workflow?
- Are there any open questions regarding the task?
- Is any additional help needed to complete the task on time?
Decisions and meeting notes are directly written in the comment section. This helps again to maintain history of what happened when.
Why does it work?
This new workflow changed the way I work with our suppliers. We reduced the amount of E-Mails and avoided questions about the current status of tasks. Furthermore it makes reporting to my superiors a breeze.
The suppliers liked that the Asana workflow is only a high level management overview. They did not need to change their workflows. Most of them convert the different tasks and stories in their own Jira tickets.
All suppliers so far accepted the workflow and liked to manage the projects with this new process. Even tough it fits my management style you mind want to do some changes to it.
Please — give me feedback. Let me know if you used it. Talk to me about what is not clear or what could be better. Any kind of feedback helps. I am sharing things like this to improve the way I work and I hope I can help others to get better in what they do and love.
Niklaus Gerber is the Product Manager Apps @NZZ, problem solver & digital architect seeking to make the complex clear & beautiful.