How to Get the Least Out of Your Consultant
This week we’ll flip the coin and talk about how to get the least out of your consultant. It’s the companion post to last week’s. Knowing what not to do is often even more important than knowing what to do.
What not to do may may seem pretty obvious. You might be surprised. Surprised at the lack of a clear direction, a general unwillingness to change, rampant micromanagement, and an addiction to aimless meetings all readily found in Corporate IT. Or more likely, this will all sound familiar.
No Clear Direction
Few things crush a consultant’s soul worse than having no clear direction at a client. This is a problem that should really be solved for on the front end. In reality however, it’s still common to run into these situations.
Situations where people are lining up to get a piece of your time and client management has no answer on how to prioritize them. The more common scenario is having a crystal clear direction on paper. Yet being constantly diverted to look at other “small things” that in aggregate form many large unruly things.
It’s just scope creep in disguise. As consultants we know the scope is going to creep organically and it’s not a big deal. It’s just the nature of our business that we’re going to uncover new requirements and invalidate others as we go along.
However, the inorganic scope creep is what creates the real problems. It’s always difficult to walk the fine line between wanting to help and avoiding getting derailed by orthogonal issues.
Unwilling to Change
A strong unwillingness to change usually stems from budget concerns. We can certainly empathize with this as budgets are of course finite. It’s not easy to sell fixing tech debt to non-technical management as adding value to the business. It feels like a net loss and a voluntary one even if the reality is much more nuanced.
However, if we’ve been brought in the client has shown a willingness to change something. The amount of change is usually the sticking point.
Whereas the client may want you to just duct tape on new features to their unmanageable old application, it’s usually better in the long run to pursue a different approach. For example, isolating new development in modern tech outside of the old hairball as a strategy to move away from it over time.
This approach usually results in significant push back. Surprisingly this sometimes comes from the client’s technical leadership who view it as simply adding to their workload by having to manage another environment. It’s an extremely tough sell when client management and technical leadership are resistant to modernizing.
Micromanagement
As a manager there’s a fine line between being engaged and being a little too engaged in a project. You want to make sure all the necessary details are handled, but how do you do it without undermining your people? I’d contend it’s all about minding the levels of abstraction where everyone should be operating.
The most fine-grained abstraction is the technical detail level. This is where your developers and often consultants will be working. While the full anatomy of a project’s levels of abstraction is a post for another day, we can safely say that a manager shouldn’t be interjecting herself at the technical detail level.
When your developers and consultants have to spend time justifying implementation details to management it’s a sure sign the project is in peril. Either the timeline will be crocked or the project itself. Unfortunately this is quite common in the enterprise IT world.
Overmanaging Consultants’ Time
The final piece to the how to get the least out of your consultant puzzle is time management. Consultants generally have to be chameleons. We have to fit into a client’s organization as best we can while avoiding unproductive norms that may be common there.
Striking the right balance is challenging in and of itself. Doing so while client management fills your schedule makes it almost impossible.
This usually manifests itself as a never-ending cavalcade of meetings. While meetings themselves are certainly capable of being productive, it’s probably the exception and not the rule at most places.
Also, when a client needs to bring in consultants it’s generally because they’re not able to handle a project with their in-house team. This could be for any number of reasons. Maybe they’re too busy with other projects or have tried the project and been unsuccessful previously.
It makes little sense to force your consultants into a structure that’s proven unsuccessful in the past. The client’s problem may not be that their development team was incapable, rather that they were put in an intractable situation.
This is a good reason to give your consultants some leeway. Just on the chance that a previous unsuccessful project attempt was the result of environmental deficiencies.
Corporate “Standup”
And finally we have the corporate “Standup.” It’s in quotes because it bears little resemblance to what the Agile Daily Standup is supposed to be.
Consultants are often compelled to join the corporate “Standup” meetings at clients. It’s usually just a big time sink to be quite honest. If I’m billing 40 hours a week at a client, I can usually count on about 2-3 hours wasted in this venue.
A much better approach is to allow the consultants and requisite project stakeholders to form their own Standup. I’ve seen better success when a consultant acts as Scrum Master as they tend to stay focused and avoid some of the common pitfalls of the Corporate “Standup.”
Summary
As a manager you probably don’t explicitly think about how to get the least out your consultant. But it’s just as important to know what to avoid as what to do.
Clients are well advised to give clear priorities and then protect your consultant from being pulled off onto other things.
An unwillingness to change is another surefire way to hold your organization back and waste a consultant engagement in the process.
Micromanagement is not only soul-sucking, but also horribly conducive to producing slow, substandard outcomes.
Finally, the practice of over managing consultants’ time should be avoided. There’s little better way to torpedo your project than to bog down your highly paid consultants in a raft of endless meetings.