In a previous post I talked a bit about how we understand project management at diesdas. I want to continue with how we actually do project management at diesdas. In a third post I will talk about what kind of tools we use to organize our work.
A little bit of history first
Project Management is one of those disciplines that often gets overlooked as something that is a nice-to-have but not really necessary. When we founded diesdas.digital we were no different. Because almost all of us have worked in agile processes before we were certain we would not need a dedicated project manager. We could manage all the projects ourselves! I mean, this bit of client communication and sending an invoice or a proposal here and there? Easy as pie, right?
This kind of works out when you have an experienced team of four to maybe ten people but after that processes get fuzzy, your work is split between disciplines as well as management work. It becomes very hard to focus on the right things and to stay on track with everything that you do. To us it became clear that we were definitely in need of a project manager at some point. One observation about hiring a project manager though. To hire a good project manager is really hard because managing clients and projects is something that heavily influences the culture you are working in. When a project manager is used to work with way bigger clients than the clients in your portfolio differences in handling and communicating with your clients will be visible quite quickly. Even more relevant is how your internal structures are set up. Do you already have a solid system one can follow or do you need to reinvent or still find it out for you?
We went from paying no attention to project management at all over to we should take it more seriously to maybe we let it work out itself to let’s get a system in place everyone can trust and follow. And that last one seems to be the key to success in project management for us.
In the beginning of this year we reflected on the processes we currently have and identified one client that is different from all of our other clients. Meaning, this client structures work differently and has a very strict internal reporting structure. For us that meant to not working truly agile but rather have a waterfall system in place to best respond to their needs. With all of our other clients we had more flexibility in the sense that we could better decide how we want to work with them.
We quickly realized one important aspect: All of our projects kinda followed a different structure. Not only did we use different software, we also had several ways of organizing our work in the respective software boards. More about what kind of software we use and how we use it in the next post … That definitely needed to be streamlined. Although we don’t hire like crazy you could say we are a growing team. With currently 25 people in the company you need to have some guardrails that allow you to stay on track with what you’re doing. The first aspect we looked at was our meetings …
I think every agency is guilty of having had too many meetings at some point in time, ours too. For us as an agency going fully remote because of this Corona-pandemic certainly helped us having more focused meetings with better outcomes and generally having less meetings because a lot of things can be clarified via Slack or — yes — even email.
Our project managers probably have the most meetings as they have to do planning sessions with clients as well as internally. Coming back to our processes, there’s not really a surprise there if you know how agile processes usually work. So, we try to split project work into sprints. Not because it always makes sense but because we can maintain our planning and meeting rituals and keep working processes similar across our company. So each sprint for us has several meetings:
The kick-off and planning
Every new sprint must start with a planning session, together with the whole team and the client to look at and commit to the scope of the upcoming sprint. The planning process should follow these steps:
- going through the backlog and dragging tasks into the upcoming sprint
- going through each task, add additional information if necessary and once again confirm the estimated time
- looking at the overall workload and making sure the team can accomplish that workload
- committing to the sprint
The daily stand-up
Every day the project manager/agile coach schedules a 15 min daily meeting with the project team. The client is optional and must not say anything — this meeting is for the team and to schedule and talk about their work, not to please or give information to the client. Therefore we have different meetings. The process of the daily is:
- sharing with the team what each team member achieved or has done the day before
- communication what will be tackled today
- raising problems or questions to solve by the project manager
The daily is information only, not a meeting for discussing topics at length.
The backlog refinement
The backlog refinement is a meeting that takes place mid-sprint and managed by only the project manager and project lead or product/project owner. The idea of the backlog refinement is to pre-plan the next sprint, to fill out as much information into the upcoming tasks as possible to assure for a smooth and fast planning session in the next planning meeting.
Before moving on to the next sprint, the team should take its time to reflect on the previous sprint. What went well, what did not and so on. The project manager decides on a retro format and preferably holds this meeting on the planning and review day. The client should be invited to every second retrospective so we also get the clients remarks and opinions as well.
The review meeting is there to share the results of the previous sprint with the client. We basically go through the previous sprint and its tasks and demonstrate the result in the staging and/or production environment. This meeting should take place after the retro and before the planning of the next sprint.
And that’s about it. There should be no need for having more meetings other than discussing project features 1on1 with the client. Because our project managers structure these meetings and take care of writing and maintaining the backlog they are closer to the actual project work as they are involved in the content. That’s why we aim for agile project managers that not only manage a process but rather the project meaning also its content and can influence its outcome.
The internal meetings
Adding to that we also have a couple of internal meetings. We have the project management sync (pm sync in short) where we look at our Forecast (Harvest Forecast is another tool we use, sometimes it helps, sometimes it doesn’t–depending on who you ask) to map out a plan for our team. It also helps to talk about new projects coming up and to reschedule teams, when a project is put on hold. We currently figuring out whether we need this meeting or how we can condense it to really just looking at forecast, leaving out the rest (talking about who goes on holiday, what’s happening in the projects, …) for a status update in Slack or Notion. I will give an update on this and where we end up.
The only other meeting left is our project management square table (pm square table in short; and yes it’s called that way because we used to sit at a square table 🤦♂). This meetings purpose is to discuss how we work, to voice opinions on the tools we use and to keep us up to date in the project management world. In the first meetings this year I reflected on a digital project management course I did on the side which was quite nice. Nothing exceptionally new but a good summary about what makes a good project manager–can recommend, would do again!
And that’s it with the meetings. I hope you have a good overview about how we understand and do project management at diesdas now. Please let me know if you have any questions about how we run projects or how we can maybe help you optimize your processes that you have internally!
In the next post, we look at what kind of software we use to round up the project management tour!
This is the second post of our series “How we do project management at diesdas”. You can also read How we understand project management at diesdas and soon “How we organize our project management work at diesdas” to complete the picture.
diesdas.digital is a studio for strategy, design and code in Berlin, featuring a multidisciplinary team of designers, developers and strategists. We create tailor-made digital solutions with an agile mindset and a smile on our faces. Let’s work together!
Curious to learn more? We’re also on Twitter, Facebook, Instagram and we highly recommend our Tumblr. You could also subscribe to this publication to get notified when new posts are published! That’s all. Over & out! 🛰