November & December theme:
“Choose One Thing”
Posted in :  Brain Waves

This post is reprinted from the original version on Tumblr.

When it comes to incremental improvement, organizations have a myriad of proven methodologies and tools to work with. However, when it comes to creation and innovation there tends to be a lack of viable options, specifically around managing projects in the creative and innovative process.

There has been a lot of buzz lately about Agile Developmental Methodology and how it could be leveraged outside of the software development industry. For starters it is a much more collaborative framework than traditional project management because it invites rapid adaptations, innovations and iterations of ideas, concepts and applications. Agile doesn’t wait for a project to be at its final stages to be tested. The process follows a series of iterative “versions,” each building on the next until the project can be called satisfactory.

This methodology favors . . .

Individuals and interactions over processes and tools
Working solutions over comprehensive concepts
Customer collaboration over contract negotiation
Responding to change over following a plan
(Read the complete Agile Manifesto)

All of this sounds great, but when it comes to actually applying agile or other innovation focused methodology, it’s not so much about which you choose, it’s much more about how you and your organization understand and relate to it. Fathom has developed, tested and proven it’s own iteration of Agile called Recursion Cadence Approach (RCA) that is specifically designed to manage complex creative and innovation projects. In this multi-part series I will share our experiences with RCA and dive into the key concepts essential to the successful integration of an innovation methodology into your organization.

Project management methodologies were borne from our need to have predictability, reliability and certainty in our work. Traditional project management documents, in high-resolution, all of the incremental dependencies, steps, deliverables and resources before the project begins. This works fine if what you build is exactly, or close to being exact, the same each time. But when you are in the business of creating what’s never been done, such as innovation work, predicting what is going to happen throughout the project is as reliable as looking into the proverbial crystal ball.

However what if we look at certainty as a collapsed distinction that if unpacked could provide a useful framework for how we manage projects? In this particular case, consider the distinction of certainty based on reality vs. certainty based on experience.

Typically, when we plan a project, we base our plan on experience. Whatever it took the last time to complete a similar project becomes the basis for which we manage the next. And as such we lay out all of the things we did for the last one, what it took to do them and put it into a plan. We then stick to the plan, and surprise surprise, something doesn’t go as anticpated, most of the time, within a few meetings of the project inception. We then end up managing the plan, not the project, constantly updating, trying to predict, constantly chasing what’s changed. This approach doesn’t leave us much opportunity to be very open to new opportunities that crop up along the way.

Certainty based on reality on the other hand deals with what you can see is so. It offers us a true sense of what is happening without surprises. Surprise comes from something not going how we expected. Reality doesn’t deal with how we thought it would go, it only sees how it is going. It allows us to be present with what’s best to take the project forward, not getting the project back on its plan.

Figure A

Certainty-reality is not better than certainty-experience. They are both necessary if you want to be able to take on Agile type methodologies. Let’s look at figure A. This graph represents your view point at the inception of a project. The orange line represents certainty as it moves between reality and experience over the lifespan of a project. Certainty-experience is critical for us to estimate the overall effort required to complete a project, it can even establish key dependencies and milestones so we can understand how the project will proceed in general terms. Certainty-experience sees far, just not very clear. So the blue bars become a low-fidelity project framework in which we can go to work inside of.

Certainty-reality on the other hand, sees very clearly, just not very far. The green bar represents how far reality sees in this project. So for that time span we can have a very high-fidelity view of exactly what’s happening in the project. So now we have the ability to create a framework for the project based on certainty-experience and no-surprises detailed project current state based on certainty/reality.

Figure B

Figure B shows how, as you proceed through the work, certainty-reality moves along the certainty-experience framework. Work completed now becomes experience and work at hand becomes reality.

As you can imagine, before a project is underway, you would leverage certainty-experience to create the framework in which to estimate work effort. However, once the project is in motion, the decisions about what gets done, who’s accountable and allocations of resources happens within each instance of certainty-reality. Each instance of certainty-reality then builds on the last until the project is fully realized. We call these individual instances, “Recursions.” which I will discuss in the next post.

Comment with Facebook

Posted by: Brent Robertson
Email the author: brentr@fathom.net