Breaking Out of Project Paralysis

By

I’ve spent the better part of my career surrounded by talented professionals whose project stakeholders are constantly complaining “we never seem to be able to get anything done.” I couldn’t help but step back and reflect at this common situation realizing the problem is “the team” itself. It’s like complaining that your clothes are all wet after you chose to go swimming while wearing them. We, meaning the team, IT and business individuals alike, were the sole reason nothing was getting done and yet we always seemed to find arbitrary things to point at or blame for the dysfunction.

What I observed more often than not could fall into 3 categories:

  • Conversation Breakdown: too many opinions from too many different parties splitting hairs and failing to settle on a design or feature set with no clear decision makers,
  • Attitude Adjustment: too many attitudes of either “well if we can’t do it all, why do anything” or “if we don’t do it now we’ll never do it,”
  • Failure to Launch: when the focus is solely on a launch date/timeline, requiring the whole solution to be developed before ever physically writing the first line of code to decide whether it was worth the effort

As I sit here I have to grin because I, myself, love a good debate and can get sucked into a back and forth as easy as the next person and for good reason. All stakeholders involved in a project want to be heard and in most organizations want to feel they have contributed to the success of the pending project. There’s no better way to do that then to have your idea(s) make it into the final product. But, at the end of the day, is all this truly needed to reach the goal we set out to achieve? Usually not.

What most of the project(s) in paralysis lack is a business leader with a steadfast plan and a level of participation to shut down scope creep or over analysis. If more projects would have that one person who “owns” the scope and isn’t afraid to ruffle a few feathers by making, or at least settling, split decisions they’d likely be on time and on/under budget more often than not.

Consider the following and ask yourself:

  • Why spend weeks planning? (planning is guessing)
  • Why worry about all the unknowns? (you can change designs on the fly often faster than you can research, debate and document your plan)
  • Why build for tomorrow, now? (I can’t see the future and I’m pretty sure you can’t either. Build what you need today and address the future when it becomes the present)

There are many things that delay projects but more often than not we get in our own way. I challenge any project team to consider their process, challenge their needs and ultimately make room for progress. You’ll thank yourself later and so will your customer.

Throughout my career I’ve been exposed to many different delivery methodologies and team chemistries. Today, as we help our clients meet critical deadlines or deliver innovative capabilities the one thing I ask my team to help with is what we call Positive Disruption. We’re not here to tell you how to run your business but we love to look for the right places and opportunities to help you get out of your own way.

Whether it’s making a simple process recommendation to building out automation, coaching a team on delivery best practices or even bringing a single voice of influence, we disrupt teams through positive change while keeping a focus on their goals and delivering a great product and a great experience.

About The Author

Andrew Duncan is a Director of Software Engineering in Richmond, VA. He is a driven technologist focused on modern technology stacks and best practices. Andrew believes nothing is more rewarding than making software needs a reality with a focus on flexible, scalable and supportable code.