Reblog: Adapting Agile Project Management to Your Accounting Firm
One of the most difficult problems to solve in client services is how to scope and estimate work properly so that everyone wins. I have to be realistic with our capacity, my team’s skillset, and their time – three things that are difficult to balance. Our client needs to feel like they are part of the process and we need to deliver value frequently, in a way that makes sense to them.
In the past we haven’t done a great job of conveying value right off the bat and completing projects in a timely fashion has been difficult. We shifted focus frequently, picked files up only to put them down and in the end, annoyed our clients when we weren’t done by their arbitrary deadline.
As a firm owner, I felt like we could be doing better work. It started to become more important to tackle this issue as we started to get busier because the more projects we took on, the harder my life was becoming. I was the main contact on the file, not my super radical accountants, and I felt like I was constantly letting everyone down. Really, it was a product of my own failure, not my team. So, I turned to my super nerdy programmer friends and asked them what they were doing; it seemed like a solved problem and I was too dense to connect the dots.
From Ambiguous to Agile Project Management
I was introduced to Agile Project Management, which completely changed the way that I work with our clients. In the past my style could maybe be defined as Ambiguous Project Management, where things just sort of happened in tandem with no immediate measureable result. Of course people were feeling let down, I threw projects at the wall and hoped that they stuck. I am embarrassed that as much as I am enamored by process development and measuring results, after six years in business this is how my project management style ended up.
I dialed in our projects by realizing that the project begins before the client says yes. We start our relationship by having a detailed discussion about what the client needs. Sometimes you will find that what the client thinks they need versus what they actually need are at odds. I ask a ton of questions, listen and take notes. At the end of the conversation I tell the client what I think we heard and distill their needs by setting short and long term goals. If we agree that we understand what the project scope will be, I develop a proposal that hashes out exactly what we will do and for what price. Our pricing is transparent -- we will do X for Y. If anything we do is outside of that scope, they know what the cost is and we let them know when we plan to go out of scope. I hate when people try to bait and switch me, and we do our very best to stick to the original plan, but know that shit happens and sometimes that shit needs to be addressed.
It’s all about having the right tools (and team)
Next we build a project in Accelo, our project management tool, and provide as much detail as possible so that anyone picking this project up can feel informed. This step in the process has always been kind of messy for me and I realized that the reason it was messy was because my notes from the initial client consultation kind of sucked. I created a template in Formstack and let the client know on the call that even though it seems like my questions are robotic or formulaic, it is for a reason. I want to be sure that nothing is missed and no surprises happen down the line. They appreciate the detail, and if they aren’t willing to spend one hour helping me understand their situation, then they are probably not an ideal client for us. It’s ok, we won’t be a match for everyone who hollers at us.
After developing the project in Accelo, I meet with staff and provide details on what the project entails. We go through the ins and outs of the projects and address any of their concerns. We also set a time for the staff member to meet with the client, so that I am no longer the bottleneck. The client gets to see our staff and learns a bit more about who is on their team. I emphasize the word team, because we see what we are doing as a team sport. It is isn’t me, my staff, or my client who is successful in this venture– we all are.
Finally, we give clients access to our company portal where they can see the project scope, when we expect to be done, and how far along we are in the process. In the past, this level of transparency would have made me feel uncomfortable, but Agile forces you a bit out of your comfort zone. You realize when you or your team isn’t performing and you end up dealing with it sooner, which isn’t always fun. I realize that software companies using Agile are delivering a different result -- working software. However, we both ship value which can be flexible and can adapt to your industry.
In the past, the project might have consisted of a mile-long task list that didn’t identify goals or milestones living in my brain. In Agile, we break down a complex project into short sprints (also called iterations) where we define what needs to be accomplished and what the result will look like. There are main roles in Agile -- Product Owner, Scrum Master, and Team Members. The client acts as the Product Owner, helping to set goals and adapt the project as needs change. We have adapted the role of Scrum Master to fit our Operations Manager who guides the team, helps to prioritize the tasks and remove speed bumps so we can quickly create value. Team Members are equivalent to our staff who manage checking tasks off the list, report progress to the client, and verify that the work produced is of the highest quality.
Agile Project Management is useful and this “Agile Lite” version can easily be adapted to your practice. Once you feel confident in delivering value, spend some time reading and learning about other parts of Agile Management including measuring team velocity, creating a master story list, analysis, testing, team collaboration, and all of the other fun stuff that is further down the rabbit hole. Start small, grow your knowledge, impress clients, and then take over the world. It’s pretty simple.
Tags: going concern