This is part one of a four-part innovation series by Allegion’s Director of Global Software Services Matt O’Dell. In this part, Matt outlines how his team uses “the compass, then the map” philosophy at Allegion to deliver an innovative solution to customers. In part two, he’ll share more details about a project steered by this philosophy.

Joi Ito’s 2014 Ted talk Want to innovate? Become a “now-ist” is a fascinating presentation about how the internet changed the paradigm for innovation.  I recommend you watch it, but that’s not why I’m mentioning it here.  In his talk, part of Ito’s innovation process is “compass over maps:”

“So this one, the idea is that the cost of writing a plan or mapping something is getting so expensive and it’s not very accurate or useful.”

This analogy, while possibly skewed by my interpretation, has inspired how we do many of our projects on Allegion’s Emerging Technologies Team.  For me, the relationship between a compass and a map is an important one, especially given the parts they both play in a successful journey.  So, instead of compass over map, I believe they play equal roles in getting you where you’re going.  The key, in my opinion, is timing: It’s the compass, then the map.

The Compass

During the “compass phase” of a software or technology project, the business problem is defined and refined, but the direction of the team is not rigidly scoped.  Much like Ito’s observation, the cost of “over-mapping” up front is expensive and likely not very useful because no one knows exactly where they are going.  In other words, in the process of discovery, it’s nearly impossible to determine the end state at the beginning.

Sure, some projects are as simple as going from Point A to Point B, and these are not a good fit for “the compass, then the map” philosophy.  But, in my experiences, this type of software or technology project is less prevalent than you think.

The reason for the compass phase is to give your team the flexibility to be creative and innovative.  That’s why you’ve hired them, after all.  The business has a problem and the solution evolves from the expertise of the project team.  But the compass is still important.  The project team needs to regroup with business subject matter experts on a regular basis to get feedback, ask questions and refine the approach.  With a talented project team, you are guaranteed to find more innovative results than trying to define the solution upfront.

The Map

At some point in the project journey, you are accountable for the delivery of the project.  This brings you to the “map phase.”  The compass has led the team to the general vicinity of a solution, and it’s time to focus in on the tasks that get them to a release.

The start of the map phase is a good time to build a roadmap.  You’ll likely have enough of a backlog for multiple releases.  Leave the future scope vague but get specific on the functionality you need to get to a minimum viable product.  As long as the team’s allocation can stay constant, the project team should be expected to commit to an end date at this time.

Why both?  Well, creativity and exploration are awesome, but the urgency of a deadline helps.  If a project is run entirely on the compass mentality, it has a tendency to drag on and on (and on).  On the other hand, map projects are always fighting to get to the end date.  They may take less time, but they lack the agility to pivot as project needs inevitably change.  “The compass, then the map” philosophy strikes just the right balance.

 

You can learn more about Allegion and their operations in their featured story profile.