A book called Case in Point is the go-to resource for management consulting interview prep. As an MBA student, I diligently studied its contents: numerous frameworks, commandments, steps, scenarios, buzzwords and tips (yes, all of these words appear in chapter titles) for solving all manner of cases. Collectively, as its introduction promises, this “system” is intended to simplify previous approaches.
Soon after, I attended an interview prep session led by a partner from a big firm. His first piece of advice? “Stop memorizing those frameworks! The only question you actually need for any business problem is: ‘What are the three most important things?’” These words still resonate over 12 years later – not only because it took immense weight off my shoulders, but because it made me think critically about when and how to use frameworks (and when not to use them).
ParsonsTKO has always adopted agile methodologies in its work, but agile was mostly new to me when I joined the company last year. So I studied up, with my skeptical self nagging at the back of my mind: Is this really helping?
One year later, I’ve seen the answer is a clear “yes.” Still, we regularly run into two major barriers in applying agile:
- Most of our clients don’t operate using agile methods. They expect work to have clear timelines, transparent dependencies, and other “waterfall”-style project planning characteristics.
- Agile was built for software development, so applying it strictly is tougher with non-technical projects. Even our most technical work includes highly consultative approaches – a critical part of how we deliver holistic Engagement Architecture.
So how do we overcome these hurdles, and apply the best of agile?
As many others have said, “Applying just a little bit of agile can help.” One of the ways we “pick and choose” components of agile to leverage in our consulting work is to translate agile concepts to common sense project management meanings. If we can answer this “Why do it?” question for each concept, we’re pretty sure it will still help even when processes and boundaries aren’t as tidy, linear or discrete as in software development. We continue to iterate on our approach (so agile!) but here’s a few that have worked for us thus far.
Daily Standups = Frequent Communication
When teams work together in the same room, frequent communication happens organically. For years I asked my strategy consulting teams “How’s it going? What do you need from me?” at the beginning and end of each day. We never called this a daily stand-up, but it served the same purpose. However, especially in a business where most colleagues work remotely, I’ve found the more formal structure of stand-ups is extremely valuable to keep teams moving and get ahead of risk.
In the traditional agile world, teams meet every day for 15 minutes to check on progress. For consulting work, our teams often require a bit more time to make progress on individual tasks, so we meet less often – typically 2-3 times/week. Similarly, we find that the challenges that arise often benefit from full-team discussion, instead of being kicked to a separate smaller group call like a typical scrum meeting would call for, so we often schedule standups for 30 minutes. We still aim to stick to time-boxing the calls, and deputize our Project Managers to cut off conversation that should be handled with a follow up.
Lastly, our teams at PTKO are typically working on many projects at once, making daily meetings a challenge – we’d all spend our whole mornings in a long series of stand-ups! This revised cadence helps us get the most out of our time together, but also leaves our calendars a bit more free for thinking/doing time.
Definition of Done = Aligned Expectations
Consulting projects often have a final report of recommendations or findings. In my career, I’ve produced “reports” as diverse as:
- a 90 page, prose-based, footnoted report in Word (It was a Congressional funding request, and I’m sure they read every last word!)
- decks with anywhere from 3 to 100+ slides full of graphics, charts, and bullet points
- detailed Excel files with many tabs of highly quantitative analyses
If you promise a client a “report,” what are they really getting? And, more importantly, what are they expecting to get?
With agile, teams always agree on clear criteria for determining whether or not a task is considered “done.” It’s an equally useful concept when the output is a report and not an executable piece of code. We’ve all had the experience of pouring our heart and soul into a piece of work, sharing it proudly with a boss or client, and getting back a resounding “That’s not what I was expecting!” I might argue that keeping expectations aligned is the #1 priority in consulting work – perhaps that’s another blog post. So whether it’s in the contract, in a kickoff deck, in a ticketing system, or some other documentation, it’s important that the client, team lead, and folks doing the work are 100% aligned on what success looks like.
We try to get as concrete as possible, and at a minimum define:
- File formats (e.g. written documents, slides, dynamic reports)
- Scope and/or length (e.g. what’s in and what’s out, how many pages)
- Intended audience (e.g. your direct client, executive leadership, public)
- Delivery method (e.g. emailed report, presentation)
This can work internally within teams, as well, to define the expectations for interim tasks as a team builds towards a final deliverable or recommendation. If you’re tasked with conducting stakeholder interviews, for example, knowing how many, what you should ask, and how the findings should be documented is an important set of expectations to define up front.
Ticketing + Kanban = Project Visibility
We use Kanban boards as a visual project management tool for agile projects. These provide a quick, real-time view of status for the work items in each sprint. For our technical development projects, a typical workflow looks something like this:
Individual tickets (or user stories) are usually narrowly defined for technical work, but in consulting projects it can be hard to disaggregate big deliverables into discrete tasks. The content of a report may evolve over time, multiple people contribute to it, and the tasks can bleed into each other. The easiest way to adapt Agile methodologies here is to modify your Kanban columns.
When we aren’t working in sprints, there is less emphasis on estimating and approvals before a ticket appears on the board. We also find that there are many more iterations of review – initial scope, outline, multiple drafts, and a final client-ready document. One structure we’ve used successfully is below. You may want to adapt this to the workflow you have with your team and clients, but the important things are to account for initial planning, and iterative reviews.
We’ve also done many rounds of Goldilocks-style trial and error: assigning each deliverable a ticket (scope is too big!), giving each draft their own ticket (too much overlap!), assigning each research and writing task their own ticket (scope is too narrow!).
What we’ve come to are a set of guidelines for assigning a ticket to:
- Smaller deliverables that can be completed fairly quickly (e.g. develop a project plan, complete a status report)
- Research or input tasks that will be inputs to larger deliverables (e.g. Interview executive stakeholders, document existing tools and systems)
- Sections of larger deliverables that require a particular individual’s expertise (e.g. Recommendations for Google Analytics configurations, Technical architecture roadmap)
A good gut check is whether the ticket can be completed within several weeks, and primarily owned and completed by one individual. If not, you may have too broad a scope to truly have a clear definition of done for that work.
In Conclusion
Despite my initial skepticism, we’ve found ways to take the best of agile and apply it to all the work we do at ParsonsTKO. There’s lots more to explore on this topic: What’s the best tool for Agile on non-techincal projects? Is estimation of individual tasks possible or helpful for consulting work? Are sprints a useful project planning tool outside of software development? Stay tuned for more on this topic – or perhaps we’ll get the team together for a healthy debate about Agile in our Let’s Discuss series!
