Let’s delve into the concept of ‘spin.’ Is your project caught in an endless loop of planning? Are you experiencing a lengthy build cycle with unexpected defects and rework? Are pivots the norm? It could be work is getting done, metrics look good, but you aren’t getting the benefit you expected. This could all be caused by spin.
For the purposes of this article, let’s say spin is the act of working hard and not getting anywhere, like that hamster on the wheel. The unfortunate thing is that once spin sets in, it can be hard to recognize and harder to get out of - software is hard after all. But there are things you can do.
If I had to categorize all the reasons I’ve seen a project spin, and pick the number one issue, I’d have to pick communication.
As an example, I’ll talk about some recent observations. Not long ago, I encountered a case of spin. The company I was working with had taken on a very large project with hundreds of points captured as project outcomes. A lot of work had been done to divide up the total project scope into smaller areas for development. Teams had been allocated to those areas and there was an expectation that after a brief period of planning, they would get to work.
The development team did their best to do what they thought was expected of them. They diligently worked with subject matter experts to understand the core components and processes. They worked with designers to mock up designs. They even embarked on a major modelling effort detailing they system. As a result, they had come to the realization that the majority of the software component they were responsible for couldn’t be easily broken apart. As a result they planned to deliver a large body of work all at one time.
Months later, leadership hadn’t received the plan from the team, yet work had been underway for quite some time. After asking the usual questions, “Do you have any kind of ETA on this project?”, “Can you share your delivery plan?”, it became apparent that the team had a much grander and drawn out project timeline than leadership expected. The communication gap brought them to this point and now spin had now begun to set in.
Next up was the classic re-plan. The project sponsors wanted some clarity on when things would be delivered and they wanted some way of measuring progress. The development team put their heads together and came up with a delivery plan that included smaller milestones. The smallest, easiest to deliver milestones were at the front, with the bigger longer projects at the back. The general idea was not to pivot, or re-dev any work done so far.
Upon review, those smaller quick-win projects that were disconnected from the core body of work and easy to implement just felt unimportant to the overall objectives.
Spin.
The next iteration involved focusing on “important” pieces that could be delivered soon. The team took that away. They worked with the business to identify areas where automation could be added, reducing manual processes. A number of small projects were carved out and reviewed again.
This new lens on the work had identified valuable work and smaller projects that provided benefit, but they were disconnected from the original project goals. With this just being one group of many working towards the overall project success, a tangent like this wouldn’t be a good use of project resources.
Spin.
Spin.
Spin.
There were a number of communication gaps that led to this scenario.
Lack of clear goals and objectives. To be fair there were a lot of detailed objectives, too many. By not distilling a few important goals, leadership, business, and the team were not able to see that they were focusing on differing objectives. They weren’t aligned, but they thought they were.
Poor feedback loop. Nobody realized that there were any issues at all until a lot of time had passed. By the time realization had set in that a correction was needed, a lot of work had been done.
Getting tactical instead of strategic. Instead of communicating the vision and goals to enable the team to make decisions that would result in the desired outcomes, leadership focused on being a part of the planning. This undermined the development teams autonomy, created bottlenecks and resulted in more spin.
Here’s a few things that the company could have tried.
Craft a few good goals and objectives. There should be few enough that they can be remembered and repeated accurately. There should be enough that the direction of the project is clear.
Try Storytelling. Storytelling is a great way to communicate goals and objectives, and a good test to see if you’ve got the right ones. If you can’t craft a narrative around them, others will be unlikely to pickup the plot you want them to.
Ask for a half-page brief. Once the team has picked a direction for the project, it’s a great time for a review. If things don’t appear to align to your project goals, ask why? There may be some good reasons, or it may just be a sign that your objectives need refinement. Waiting until months have gone by isn’t helpful. By that time, most of the initial reasoning has been forgotten, your are confronted with sunken cost fallacy, you may be over budget and behind schedule. It’s hard to think strategically if you get to this point.
Our mission at Open Path Partners is to simplify the complexities of technology, making software development less daunting and more accessible. We work with our partners throughout the complete software lifecycle. Our expertise in building business cases, defining project strategy, and understanding your opportunity ensure your software project is headed in the right direction.
Let’s talk