When I co-founded Benelds in 2013 I'd had extremely limited experience as a Project Manager. And when it was just Christie my co-founder and myself, it was easy to stay on top of projects.
In some respects we were the blind leading the blind. We were lucky enough to be very good at what we do, and land some extraordinarily understanding clients who were able to cope with the circuitous route it sometimes took for us to get to delivery.
As we grew and built a team, the ability to just stay on top of things through grace disappeared pretty hard. I tried literally every single Project Management Software on the market. And not a single one of them helped us.
So I googled "how to project manage" and tried to figure it out.
What I found was a huge amount about how to use software - how to use Asana, how to use Trello, and on and on. What I found very little of was how to structure projects, how to divide tasks, how to estimate time requirements, how to communicate progress to clients - you know, theories behind project management that are translatable to your own situation.
Almost all of whats available online is about agile and sprint in software development. What I quickly learned was that that sprint doesn't suit service delivery. Agile doesn't suit service delivery. And I also learned that there's a huge set of project managers out there whose job is simply to make Asana neat and organised, with tags and labels galore, but who aren't actually doing much to help projects progress.
When I advertised roles for Project Managers I would inevitably get resumes listing their tool expertise. And here's the rub... even as a massive software nerd whose hobby is tinkering with software, I didn't give a shit about how well someone knew the pro feature list of Asana. What I wanted to see was evidence of them successfully managing multiple service delivery projects in a knowledge industry.
That evidence never came, and so I had to figure it out for myself.
The Software Doesn't Matter
Most project management tools require a huge amount of knowledge to use. This is insane. A PM tool should be there to support and enable, not require projects of their own. A better way to think about the tool you choose is it's a collaboration tool, not a task manager.
If you're thinking about the software, and not the project, you've made a misstep.
Client Communication is Everything
It never ceases to amaze me how many supposed project managers fail to understand this: the most important thing in service delivery is communicating with your clients.
In my experience it's a very rare client that cares much about timelines blowing out, as long as they're not surprised by it. Clients only get nervous when they don't know what - if anything - is happening. Naturally they always assume the worst, and so the most important thing is to communicate constantly.
Plan Everything Upfront
Timelines blowing out is more of a problem for you than your client. It usually means overtime and a reduction in profit for you, and unnecessary stress for your team. Scoping, Timelines and Pointing are the way we manage this and stay debt free.
"Debt" in a project happens when you either underestimate how much something will take or constantly accept "little changes" that quickly become overwhelming.
Proper scoping, communicating (and agreeing) on timelines and pointing are all techniques we use to reduce scope creep and stay debt free.
Happy Team, Happy Client, Happy Life
A Project Manger's role is more about managing the team than the project. For one, if you have employed technicians who need constant supervision, you need to review your hiring process.
A project manager should facilitate the skill of the delivery team, manage client expectations and communication, and enable everyone to deliver great work.
Their job should NOT be about assigning tasks. It's a recipe for a miserable delivery team and an overworked PM.
How We Manage Service Delivery Projects At Benelds
The following is adapted from one of our onboarding manuals that new hires are expected to read, understand and be tested on before they're let loose.
I've tried to keep it platform agnostic, although there're some features of the tool we use that are truly unique, and the reason we use it.
6 Week Cycles
Firstly, we complete projects in 6 week cycles. Six weeks is long enough to balance the demands of multiple projects, limit risk (from being overly dependent on one large client), enough time to build something impactful, but short enough that everyone can feel the deadline looming.
I quickly learned that a 6 month project very easily becomes 5 months of slacking and 1 month of crisis, and through trial and error figured out that 6 weeks is a nice median point between "get this done by yesterday" type pressure, and enough time to think creatively.
Each cycle is followed by a two week delivery period where internally the project is handed back to the client manager, which then transitions to a downscoped maintenance contract.
Scoping The Work
Secondly, work is scoped before handing over to a project team as part of the sales process. A senior consultant defines the key elements of a solution at the right level of abstraction: concrete enough that project teams know what to do, that the client knows what they’re getting (the scope is signed off by them as part of their contract), yet abstract enough that the project team have enough room to figure out the interesting details themselves.
When scoping we try to balance time estimates with time appetite: this is, balancing how long we could spend on something, vs how long we want to spend on something, and how long the client is willing to pay us to spend on something that achieves the desired outcome.
(While we're talking about the amount of time a client is willing to pay for, the trite advice is to "value sell!", "sell on outcomes!" and not just sell your time. If you can show me a more accurate way to calculate the duration, cost and therefore profit of a project than the time it take to deliver it, please tell me. I'm listening. Go on. I'll wait.)
Making the Project Team Responsible
Thirdly, the project team has full responsibility for delivering the outcomes in the scope. They define the tasks, make any necessary adjustments to the scope, organise the segments and build the solution. We do NOT have managers who assign individual tasks as though the highly skilled project team we've nurtured are simply ticket-takers. Morale is important here - it's the Project Manager's responsibility to make a project enjoyable for the delivery team.
Managing Workload Volatility
Clients are made aware that we work on a timeline basis. At the beginning of each project we spec out the upcoming workload by week, and the client agrees to it. We make it clear that no additional work or modifications to the timeline will be delivered unless we’re given two weeks notice of a desired timeline change.
Continually agreeing upfront to what will be delivered allows us to manage workload volatility when asked to do more or different.
The client has to consider the trade-offs when asking, and we’re in a position where we have the ability to push back or spin up a second project during the delivery period.
In 7 years a client has never been upset when we've said "no" to a request.
If timelines reduce workload volatility across the delivery team, pointing reduces volatility for individual team members.
Tasks and segments have an estimated number of hours attached, and this allows us to ensure that no team member has more than 32-36 hours of scheduled tasks in any given week. If we get this wrong a senior staff member steps in to fill the gap, and timelines are adjusted the following week.
It’s an inescapable truth that with project work, time is money: scope creep and poor estimates directly reduce profitability, and overworking a team member means they start looking for employment elsewhere. It's the Project Manager's responsibility to make sure this doesn't happen.
Documentation and SOPs
We document as we go. Where relevant, each segment includes a task to create an internal and client SOP. Many hard-earned lessons have taught us that doing this in increments rather than attempting it at the end of a project is far more time-efficient.
Eventually this creates a library of reusable documentation for our clients, and SOPs for our teams, making hiring easier and project delivery more profitable in the long term.
Rough and Abstract
A good scope is not so vague that no one knows exactly what is to be delivered, and not so specific as to limit the project teams’ ability to think creatively and enjoy the process.
All the main elements of the solution are there (macro) without spelling out specific tasks (micro) for the project team.
It must be specific enough that the client can sign off on it, and provide guide-rails for the project team, yet vague enough that the task-level decision process is in the hands of the project team and ultimately the person responsible for completing the work.
The scope will limit the delivery team by indicating what not to do as much as what to do. As the fixed time constraints limit the scope and allow the project team leeway in exactly how they achieve the outcomes specified. Remember: fixed time, variable scope, not the other way around.
Scope Creep & Rabbit Holes
Scope creep happens in two ways: additional requests, and rabbit holes.
Clients love to ask for extras. But remember - in project work, time is money, and every request takes time. Time to converse, time to scope, time to deliver. We learned the hard way that allowing clients to dictate project deliverables is a recipe for failure.
Additional requests always come with a fee. Depending on the size of the requests - determined at face value by a senior staff member - it may be rescoped in a subsequent project, or may simply be added to the existing project as a change or an add-on, if workload permits.
Rabbit holes are different. Rabbit holes are problems that have not been adequately identified in the scoping process that drastically affect the timeline - either through significant delay, or worse, having no apparent solution.
The risk of rabbit holes is simple: a well scoped project looks like a thin-tailed probability distribution. It could take 5 weeks, or 7, but the elements of the solution are adequately scoped that it won’t take longer than that.
However if we encounter a rabbit hole - technical unknowns or misunderstood interdependencies - the project could take multiple times the time budget to complete - if at all.
The solution to limiting this risk is consulting technical experts BEFORE the client signs off on the scope - a delay upfront is much less costly than a delay in delivery.
Assign Projects, not Tasks
Instead of having a taskmaster slice up the scope and deliver a list of tasks to deliver, we allow the team to take on the project and work within the boundaries of the scope, and create their own tasks.
Some processes are obviously pre-determined. But where tasks are not obviously pre-determined, we gives the team the freedom to implement an idea the way they think is best. Clients don’t care how a solution is delivered, simply that it is.
In addition to the morale from allowing talented people to use their brains, nobody can predict at the beginning exactly what will need to be done. And the time it takes to create a detailed task list upfront WILL be wasted time - and in project work, time is money.
Done Means Delivered
At the end of a 6 week cycle there’s a two week delivery period where a senior staff member talks the client through their new system. An implementation isn’t done until the client signs off, at the end of this two week period.
As a project starts, the immediate tasks are apparent. If a project involves a new Infusionsoft account, for example, the first steps are obvious - and as is often the case with project work, the same every time. Template todo lists are imported into a project and assigned to a junior team member.
As the team starts doing work, the less obvious tasks begin to form. The project is divided up into segments based on the outcomes.
Each segment is a meaningful slice of the project that can be completed independently and in a short period of time - a few days, or less. Some of these are identified in advance, others during the progress of implementation.
As more and more projects are done, more and more of these can be planned in advance - but you can’t make a map without walking the ground first.
Holes in your Segments
There are almost always items that don’t fit neatly into a segment. They go into their own segment until there’s more than three items. If there’s more than three, there’s a dedicated segment that can be made.
You could look at a to-do list and see 5 of 5 items checked as complete. One could assume that means that the segment is complete - or it could mean that additional tasks haven’t yet been identified and added to the segment.
To quote 37 signals, “work is like a hill: there’s figuring out what the approach is, and what we’re going to do. Then once we can see all the work involved, there’s the downhill phase of execution.”
Basecamp, our PM tool of choice, has hill charts that are manually updated. Uphill is figuring things out (NOT completion progress!). Top of the hill means we know what to do, but nothing has been done. Bottom of the hill is the process of completing task work.
Communicating with Clients
Basecamp has a client communication feature that allows us to add clients to basecamp, but only the areas we want them. For the most part we just use this to collate all client communication, so the whole team can see it. If they're so inclined, clients can also log in and see hill charts. See https://basecamp.com/features/clients
Delivery & Beyond
Handing over to a client creates additional work. Every. Single. Time. This is why we allow a two week handover period at the end of every project, which allows the team to wind down one project as they’re winding up another.
Stay Debt Free
Handing over to clients always involves additional feature requests. Honouring these requests means taking on debt. Each “yes” costs time - and in project work, time is money. Additional requests should be collated, scoped, and quoted on. Every. Single. Time. DO NOT MAKE “MINOR” CHANGES on the fly - they add up.
After a project is delivered, we offer an ongoing reduced-scope contract. This can take the shape of email-only support, software upgrades and packages, monthly ad management or something similar. These are low earning, long term contracts. This creates stable revenue that allows us to slow down and breathe when we need to.
When I look back and reflect on our successes and failures, it always boils down to how well we communicated.
That's why I will shout until I'm blue in the face about how the most important thing in Project Management is client communication.
It can be unnerving at first to give a scope to a delivery team, instead of a task list. It can even be unnerving for the team who isn't used to it! But not one of our past failures can be attributed to "not enough task specificity".
Successful service delivery is about communication, collaboration and planning. What suits software development does NOT translate to service delivery, and the waterfall approach of top down management never succeeds, of that I'm sure.