My first consulting project (and why I shouldn't have done it).



04.11.18





So, I’m a consultant - now what? After almost 20 years as an IT guy supporting creative operations, I walk away from a good job. During those years I was fortunate to have a series of great roles; surrounded by creative professionals, working closely with fantastic and brutally demanding clients, leading and learning from some of the best IT professionals around. Much of the experience prepared me for consulting, but there is always more to learn. Looking back at my first independent project offers several good lessons.

The client. The founder and CEO of a Chicago-based studio for cost effective 360° & 3D product imagery wanted to scale creative operations. Business growth was strong and the studio processes that supported product samples, data, and images were fairly efficient and mature. Unfortunately the systems supporting the studio were less mature and poorly integrated, leading to inefficiencies for the studio and more importantly it’s clients. I had (and still have) a lot of experience helping creative operations align process and technology to drive scale and efficiency. Sounds perfect right?

The project. When I began to define the project scope with studio leadership (a smart and experienced, but newly organized team) the first red flags went up. As you would expect, the CEO knew what was needed – new and better technology. The operations leader also knew what was needed – project management tools and discipline. And finally, the person closest to the actual work product (which means their title was vague, no surprise) also knew what was needed – incremental improvements and integration of the existing studio toolset.

The good news is that I worked alongside both leadership and operational team members to clearly identify where the inefficiencies and obstacles to scale and velocity were hiding in their workflow. Next I developed detailed functional requirements that we mapped against the workflow in order to prioritize the studio needs. I then used these requirements to vet a small group of system vendors, and finally provided the studio with a vendor recommendation and integration plan towards achieving efficiency and scale. The client was satisfied with the results, but the plan was not executed.

Why I should have done it differently. In hindsight, it is obvious that the leadership team had different reasons and expectations for the project. What may not be as obvious is the most significant mistake I made at the start of the project. Rather than jumping directly into the functional details, I should have aligned the studio leadership to a set of well defined business requirements. A leader in this market whom I admire, Eric Fulmer, perhaps expressed this in the simplest terms – a business requirement is the what and why – while a functional requirement is the how. As technical professionals, getting to the how is the easy part, but getting the business to articulate what problem it needs to solve and why that problem equates to business value is not easy.

Had I taken the time to align the leadership team on the what (e.g. our clients need to quickly approve product imagery) and the why (e.g. lack of timely approval halts the operation and wastes resources) – I would have delivered a roadmap focused on achieving operational value – rather than a vendor recommendation to meet a series of functional requirements.

Takeaways. First, always start with the business requirements – the what (e.g. a business user needs to do something) and the why (e.g. how that something impacts costs, time, experience, or revenue), even if the client hands you a set of functional requirements that you know how to solve. Second, try and forget what you know when you begin a project – as your experience and assumptions may prevent you from identifying the clients actual needs.