Project Execution Flywheel

 Last year, I listened to an episode of The Tim Ferriss Show where he interviewed Jim Collins, and Jim mentioned a concept that I've been semi-obsessed with ever since - the flywheel. Basically, a flywheel is a set of systems where, once initiated, a large amount of the momentum for moving forward is self-sustaining, because one step inherently leads to the next.

If you've never heard of Jim Collins - he is one of the most influential business minds out there, and his group has done decades of research into what differentiates 'good' companies from 'great' ones (thus, the title of one of his books: Good to Great).

BUT - this is not a post about Jim Collins. Ever since I heard that episode (and read his monograph: Turning The Flywheel), I've been thinking about ways the flywheel concept can be applied to both business and personal life. One of the ways I started mulling the idea over was in regards to how a project is executed, and I started realizing that, when I looked back over my career and examined successful projects and compared them to ones that were not so successful, some patterns started coming into focus.

Before I dive in, I'll point out that I am speaking of project execution from my perspective as a Data Center consultant/engineer, where I am part of a team responsible for implementing a new technology solution within a customer environment. Projects take many forms - this is just my reflection on the kinds of projects I happen to work on.

When I think of the projects I work on, there are four primary roles - sales, design, implementation, and management. Usually, in my industry, the titles for people filling those roles are something like Relationship Manager, Solution Architect, Professional Services, and Project Manager. Note that in some cases, a single person may be fulfilling multiple roles.

While each role has the obvious end-goal of making the customer happy, I realized that each role also had their own set of internal motivations. Furthermore, I realized that at each step of the process, each person has the ability to make things easier for the next person. In my mind, this realization is the fundamental thread that makes the flywheel possible, and differentiates it from the typical sales cycle graphics I'd seen before.

Here is the flywheel I came up with, with the various roles and individual motivations included:

So, lets walk through this, step by step.

Relationship Manager (RM)

The primary individual motivations for the RM are to make a sale, and generate repeat business. There is a (resource) cost associated with acquiring a new customer, and acquiring a net-new customer is more expensive than an existing customer - so the repeat business prospect is very important.

So, once an RM has a potential customer, how can they best assist in contributing to the flywheel? By doing a good job of identifying and qualifying any opportunities. How this is done is up to the person and the end-customer - after all, their title is Relationship Manager for a reason. But the point is that by finding well qualified opportunities, time is saved further down the line because the SA is not burning cycles on a bunch of opportunities that do not convert to actual projects.

Solution Architect (SA)

Once an opportunity is identified, it is typically handed off to an SA. This person scopes out the project, and comes up with a cost estimate. Their primary individual motivation is to come up with something that the customer is willing to bite on. This is a delicate balancing act between detail, timing, and expense - sometimes customers need something on a budget, and sometimes they need an estimate yesterday.

Yet, the best way an SA can assist down the line is to have a very focused SOW that contains a clear execution plan. It does no one any good for professional services to show up onsite with a vaguely worded SOW and no information about the customer environment.

Professional Services (PS)

Once an engagement has started, the PS person wants to get the work done as quickly and cleanly as possible. This is best done by knowing what needs to be accomplished, and how to systematically move through the tasks to complete the project. Preparation here is key - information about the environment in general, information about the primary motivating factors for the chosen technology, specific technical information that will be needed for a deployment, uncovering environmental constraints and obstacles that will need to be addressed - all are critical parts of executing through an engagement in an efficient manner.

Which leads into the best way that PS can assist with keeping the flywheel turning - doing everything possible to wrap up an engagement with as few loose ends or zombies as possible. Anything that is not tied up in a nice bow requires re-engagement down the line, which depletes cognitive cycles. This can be a vicious cycle, because that downstream re-spooling can often come at the cost of something being worked on at that time - so it's actually a double tax.

Project Manager (PM)

The PM is often in the unenviable position of being tasked with keeping a project running smoothly and finishing within a timeframe that they did not have a lot of input on. With larger projects, there are a lot of people involved, and this role can become quite complex, very quickly. Yet, at the end of the day, they always have to have an eye on how much time has been spent on a project and trying to keep things moving in an efficient manner.

While one may think that the PM is at the end of the line for a project pipeline, since tasks such as closeout and billing are handled by the PM - the reality is that they are also just another piece of the flywheel. If the PM is able to herd all the cats in the implementation bag and keep a project moving in a way that instills confidence and trust in the customer, that is a HUGE factor in the customer coming back to the RM with a potential future engagement. And thus, the cycle begins again.

One final thought:

I did not include a specific how-to for each step because everything is situationally dependent, not the least of which is the people involved in each step! Everyone has their own way of working with other people - the specifics of how each role executes their portion of the flywheel is less important than the people involved coming to an agreed upon method of working together that works for each person and also keeps the flywheel moving. Otherwise, it's not a flywheel - it's just a big grinding stone.