How we understand project management at diesdas
An excursion into project management terminology.
Oh project management. You’ve all heard the term somewhere and you all have different views and opinions about it. I want to take you on a journey of how we do project management at diesdas, how we explain project management to our clients, how project management brings value to every project that we do (or better every team that works on a project) and why we’re still struggling giving this discipline an appropriate name.
How we understand project management
A project manager does a couple of things at diesdas and even more than you would expect from a project manager. First of all the most important thing a project manager does is keeping the team sane and making sure every member of a project can do their job properly without still missing some assets, explanations and the like. Other than that a project manager at diesdas prepares proposals together with the project team, sends out invoices, communicates timelines to the client, keeps our backlogs up to date and manages the project board. (We use Notion to organize our workflows, more about that later.)
What a project manager does in a nutshell:
- project planning (with roadmaps, backlogs, tasks, …)
- project finances (invoices, proposals, making sure the project is still on track, …)
- organizing everything around the project (preparing meetings and workshops, preparing retrospectives, planning meetings, …)
- checking on our teams capacities (team planning, rescheduling, …)
- setting up retainers and maintenance retainers
- keeping the client informed at all times and thus keeping the client happy
So far so good. If you work in a bigger company or an agency you probably have a similar understanding of what a project manager does. But, what I mentioned above is not all our project managers do. Let me explain.
The slow transition into agile
Agile, Scrum, you heard these terms before. These terms are very much overused these days, also because everyone has a different understanding of what it means to work agile. At diesdas we realized that you cannot do every kind of client work in a pure agile manner, you have to look closely at the project and at the clients needs to decide how you want to move forward. So while all of the things I mentioned above sound very much like a waterfall-ish project setup, we try to work as „agile“ as we can. Whatever that means. Let me try to break it down.
Follow the waterfall
We have all worked in Scrum before. Scrum has a lot of benefits as a process to work on projects compared to waterfall processes. But maybe you haven’t heard what a waterfall process is. In a waterfall process you basically try to work in phases. A strategy or concept phase, a design phase and a development phase. So your strategists or concept developers start to work and map out a plan for the project and what you want to achieve. They hand over their results to the designers who then design everything that is needed, often times based on the requirements of your concept or strategy team. When they’re done they hand over their work to the developers who then code everything. At the end you have the big reveal in front of the client and the client realizes it is totally wrong and you have to start again. And there you have the downside of this process. Often times you have fewer check ins with the client and the first time the client sees the result of your work is basically at the end of the project. Of course you can have check-ins with the client after each working phases but the finished project and how it will look like and work is still fuzzy until the design is really finished. That’s why it’s better most of the time to work in an agile ways.
Agile, Scrum, Kanban, whatever …
Probably the most known process when it comes to agile working methods or processes is Scrum. Scrum is inspired by software development and tries to assemble self-organized teams, consisting of all disciplines needed for a project who then work in short working intervals also known as sprints. So you basically try to break up your work in smaller chunks what fill two to three weeks and then start working. The outcome might not be 100 percent clear yet because the idea of this way of working is also that you find out what’s best for the project while working on it. Before every sprint you have a planning session, the team has a stand up every day (of about 10 to 15 minutes) where they organize their work (what did they do yesterday, what will they do today, …). All the work is organized in what we call a backlog. It’s basically a container with tasks. How to write these tasks is a different story that I might shine a light on in a later post. To always make sure your tasks are correct and are relevant enough to achieve your goal at the end of the sprint and/or project you have more check-ins with the client. Specifically with a product owner (agile language for someone who is charge of the project’s outcome and can make strategic decisions). This meeting is called backlog refinement (backlog grooming is also a term it was known for). Your agile coach (for us project manager but more about that soon) is talking to the product owner, refining the backlog, organizing the tasks and makes sure that the team knows what to do in the upcoming sprint and that the client’s needs are met.
Our project managers also need to implement agile processes and then turn into agile coaches.
The agile project manager
So but what does that have to do with how we do project management at diesdas? Well, we are not working in Scrum by the book. We are not working and specifically Kanban processes nor do we work in waterfall processes all the time. We design our working processes and methods to exactly fit the clients needs. That’s why we often end up with a mixture where we take specific elements from working methods and combine them to something that we see fit for the project. And that’s also why our project managers are more than just project managers like I explained above. Our project managers also need to implement agile processes and then turn into agile coaches. They are more involved in content than in a normal waterfall process because they have to write tasks for the backlog, they have to own it and they have to understand what’s specifically going on in a project. So all of a sudden they have a lot more to thing about on their plate than a normal project manager.
To sum up
- our project managers are more than just project managers
- our project managers turn more and more into agile coaches
- we don’t do agile processes by the book, we rather invent our own
- we believe a project manager should always be involved in content of a project to better facilitate the work to be done and to more effectively communicate with the team
This is the first post of a series “Project management at diesdas”. In the next post you can read more about How we do project management at diesdas and the week after How we organize our project management work at diesdas to complete the picture. Stay tuned.
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! 🛰