It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.
from “Citizenship In A Republic”, speech delivered by Theodore Roosevelt at the Sorbonne, in Paris, France on 23 April, 1910
What Next for IT Projects?
Faced with the (well-documented) challenges that large IT transformation projects have, it is reasonable for those business executives that are asked to fund these projects to seek assurance that their money will be well-spent.
So, in the last blog post I spent a little time on these challenges and started to outline some of the trends that are starting to shape the “way ahead”. Trends like Agile, Extreme Programming, DevOps, UX, Lean and so on. However not all these trends are at the same stage of maturity and trying to tie them together into a meaningful methodology seems like a challenging task.
Back to the Future: Thinking about Methodology
Allow me to digress for a few minutes.
Early on in my career I started to get involved in software development methods – from the early work of Ed Yourdon and Tom DeMarco that gave the world structured analysis – I was hooked on terms like IE, SSADM, Object-Oriented Analysis and Design, and so on. I was an advocate of CASE tools and practised RAD. At the same time I became concerned that the approach we took in those projects (in the 1980’s and 1990’s) was inflexible and struggled to deliver the business outcome promised.
In recent years I have become more interested in how we hang different concepts into flexible frameworks. I grew up with logical and physical data models so I am reluctant to discard them, I also appreciate the rigour that a structured analysis-design-programming approach provides but, at the same time, I have seen the level of engagement go up on Agile projects. Therefore, I wonder if there is a logical evolution of structured methods into the rapidly changing world that we now occupy?
So the question that comes to my mind (with respect to transformation projects) is “how do we ensure that we apply a rigour of thinking and a discipline of doing whilst at the same time being extremely responsive to the changing way that people interpret and process information to do their business jobs, as well as anticipating future (undefined) future client needs”?
Sounds hard, which brings me to managing compromise …
Why “The Opposable Project”?
F. Scott Fitzgerald once wrote that one sign of a first-rate intelligence is the ability “to hold two opposing ideas in mind at the same time and still retain the ability to function.”
In Roger Martin’s book, “The Opposable Mind”, he describes the way that the best business execs can consider 2 seemingly contradictory approaches and find ways to not make poor choices or compromises between the different approaches, but combine them to deliver the best possible outcome. He says:
They have the predisposition and the capacity to hold two diametrically opposing ideas in their heads. And then, without panicking or simply settling for one alternative or the other, they’re able to produce a synthesis that is superior to either opposing idea.
He calls this Integrative Thinking. And then he goes on to explain how the techniques to do this can be learnt.
In the same way that this approach is working for some business execs and can be used to advance business decisions, I feel that this approach can form the basis of a way forward for software development and transformation projects.
In the model that Roger Martin proposes (called Salience-Causality-Sequencing-Resolution), one of the key features is an iterative or feedback loop. I see that as being a key part of the model, as will become evident later. Moreover, in what I have termed “The Opposable Transformation Project”, there is a key role for an enlightened project sponsor to ensure that compromises do not become the de-facto way of resolving issues on their project. I would say that a sponsor needs to take an active role in designing innovative resolutions to project issues.
Customer Development vs Project Development
Often large transformation projects feel like they are “set in stone” from the beginning. Whatever was in the contract is what we are tasked to translate into business requirements with an assumption that the over-arching customer needs known up-front. But, what if we needed to “discover” the customer first?
In any organisation there are early adopters, early majority and late majority users. Just like Geoffrey Moore’s “Crossing the Chasm” applies to technology marketing (see below) I think it also applies to transformation projects.
If we assume that all projects are designed to deliver products (one of the foundations of PMI) and we also think of a large transformation as a risky venture designed to build a new technology that requires customer adoption, then it could be logical to conclude that a large transformation is actually a project that is searching for customers. Hence the concept of customer discovery (the first step in the Customer Development Method, as described by Steve Blank) might be an appropriate model to use.
BTW: I think there could be a complete blog post in using Customer Development Method for transformation projects. I will not go into details here.
Get Out of the (Transformation) Office!
Often projects begin by reviewing the contract documentation and what has been committed in the RFP response. Whilst this may seem logical when the project goal is to deliver what was committed in the RFP response it does not feel in line with the Customer Development thinking we just developed in the previous section.
One large project I worked on (I recall we had a staff of around 150 in the office) spent 6 months in scrupulous documentation of the contractual requirements and avoided any contact with the customer as it was “irrelevant” what the customer wanted, the only objective was satisfying the contractual requirements word for word. Not surprisingly I wanted to get out of that project as quickly as I could!
In line with the Lean Thinking principle of Genchi Gembutsu the first thing to do is “get out of the office” and start talking to real customers who will use your “product”. However the question is “which customers” and here we can use the Technology Adoption Life Cycle idea to help.
If we are to be successful in our transformation project the first “customers” we need to win over are the early adopters. Hence we need to prioritise requirements that suit their needs. This can get us to our “Minimum Viable Product” (borrowing a term from Eric Ries, The Lean Startup). However there will always be the challenge of how to bring across the late majority and laggards to support your project.
In the final blog post I am hoping to bring these thoughts to conclusion.