Mission Over Task

Project management principles are well defined, and analytics initiatives tend to lend themselves well to these given the amount of development required. However, one of the pitfalls is that people can confuse structure with solution. In other words, believing that completing tasks according to a framework will guarantee success, even when potential conflicts or challenges arise. This can be demotivating at best, or introduce significant delivery risk at worst.

A few years ago, I was on a hike in the mountains with friends. After we had passed the summit, we set back down along the route we had picked, fighting our way through torrential rain. However, on the way down we realised that a riverbed we had planned to cross had transformed into a fast moving river. Although we decided to descend another way, I still had a persistent urge to foolishly try and swim across. After all, this was the route we had planned!

It can be difficult to let go of a task, no matter how trivial, once defined. However, it is worth reminding oneself that the task is not the mission. In our case the mission was to climb the mountain and get back safely. Deviating from the original task was the best way of accomplishing that. Simon Sinek made an excellent case for why teams should have a purpose, yet it is just as important to have a clear idea about the mission you are trying to accomplish.

Data transformation projects are often complex, given the broad range of stakeholders, objectives, and technologies involved. Execution rarely adheres to a linear process, as blocker arise and development work take longer than expected to complete. Whereas in hiking you might encounter heavy fog, wild rivers, or eroded paths, in analytics these might be missing documentation, messy data, or broken APIs. Workarounds are essential to achieving success.

Realising that tasks will change, even as the mission might not, is a powerful way of staying motivated and maintaining delivery cadence. This mindset is not a million miles removed from principle #2 of the Agile Manifesto: “Welcome changing requirements, even late in development.” Structure should exist to empower, not to justify inaction. Data and analytics is such a dynamic domain that change must be taken in stride. An ally, not an obstacle.

— Ryan