The Resilient Project
November 5, 2009
I think I’ve found the new “Paradigm Shift” for the next decade: Resilience.
Many thinkers are coming to the conclusion that we simply can’t prevent bad things from happening, so let’s focus on making sure that when (not if) they happen, our work can go on. I’ve had a number of conversations with people in a variety of fields that suggest this is an ascendant concept. You heard it here first, folks!
Here are some of the disciplines that seem to be embracing resilience as a value:
- Urban planning: communities can examine how they will continue to prosper under different circumstances. Communities built around single industries (e.g., steel or manufacturing) or transportation choices (e.g., cars) may have a more difficult time adjusting to change.
- Mental health: resilience is a trait in individuals that allows them to maintain a positive attitude even during times of stress and change. Resilience is about looking at the “glass half full” and looking forward rather than backward.
- Responses to terrorism: if we can’t keep people from blowing themselves up (not that we should try), let’s make sure when (not if) it happens, the walls don’t crumble around us
For software project and IT governance, resilience is about responding to the inevitable changes that occur in projects. As clear as our vision might be when we start an initiative, we inevitable learn something during the project that causes us to change direction. A resilient project will have the characteristics to embrace change and stay on course to core goals. I’ve already written a couple of posts about how projects can be more resilient with concepts like the management reserve and Predictability as a promise (Part I) and Part II that give some bounds around setting expectations for change.
Don’t get me wrong: let’s not stop trying to “get it right the first time.” Resilience isn’t about promoting change! Change is always expensive. So the key becomes something like helping the business make the right decisions at the right time. Decisions made too early or too late risk loss of productivity. Good decisions made whey are needed keep us moving forward.
How do we make sure good decisions are made at the right time? We have a few tools like Agile methodologies that at least spread out the decisions, but, like any tool, Agile is not an answer in and of itself. Agile just tells us we don’t have to make all of our decisions up front and expect them to be fixed. Instead, iterative processes just force us to recognize that we can’t get everything right the first time, so we might as well change in small increments instead of big ones. I have a few more thoughts coming on “how to decide when to decide,” but you’ll have to wait.
What’s your definition of a “resilient” project?
November 6, 2009 at 9:25 am
Interesting post. I had the mental picture of a vehicle going through a crash test: ideally, the vehicle will never be in a collision, but if it IS then we want it to crumple in specific ways to minimize the damage to the vehicle or its passengers. Similarly, we should engineer our projects such that we “keep the passengers alive” even if we come under stress.
From a technical perspective, a “resilient” project would likely have these characteristics:
* The parts of the application most likely to change are decoupled, as much as possible, from those that aren’t. If change DOES happen, it’s always better that it happens in isolated areas instead of sending ripple effects through the entire system.
* The vendor and the customer have a shared understanding of the impact of change, plus shared understanding of the techniques used to manage it. The project is made resilient if we approach change management with transparency and common goals.
* People matter. I think that if stakeholders and team members are “internally resilient”, e.g. they are the “glass half full” types, then the project will take on some of those characteristics. Projects can’t be resilient if the key players lose hope at the first sign of project stress.
November 6, 2009 at 2:46 pm
Great comments, Seth!
So resilience might be related to:
- architecture
- shared goals
- personality profiles
That definitely mirrors my experience.
November 6, 2009 at 9:41 am
I have never thought of a definition of resilience until I read this. I think I always sort of assumed resilience was synonymous with perseverance, but now I don’t think so. Resilience deals with change, where perseverance deals with monotony. Or to put it another way, resilience is perseverance through change.
I am going through a major server migration at the moment, in a small business environment, so a switching out a couple servers a like upgrading the entire company’s business at once. In March the office moved. There will be a major database overhaul completed in early 2010. There is a lot of change, and major projects, happening this year in my organization. You’re right, change is expensive. Financially, but also otherwise. Resilience is knowing their will be issues, tests a-plenty, and seeing the projects through successfully. Resilience is making it to the greener side without being the chicken crossing it.
Or is that perseverance?
November 6, 2009 at 10:35 am
Hi, Josh,
I love your image of the chicken crossing the road to the greener grass. It brings to mind an image of road-kill. Which is a pretty good image for a lot of projects.
I appreciate you differentiating resilience from perseverance. In most cases, I think we need both. Typically, we give up on projects and relationships when they become too confusing to master. Change is unexpected and uncontrolled, so we lose our ability to make good decisions.
A resilient project will help us monitor change, so that we know a) that change is happening and b) what changes are happening. I like a comment from Steve McConnell in Code Complete, a very influential book on software development. He lists “perseverance” as one of the traits that you think would be essential for a good programmer but isn’t. The notion is that perseverance can put us in a position of banging our heads against a wall when we should actually be giving up on a task and choosing a different path.
I think perseverance coupled with resilience is probably a good combination: let’s walk into a well-thought-out structure, knowing that things will change, and knowing that things will take longer than we expect. Set that expectation, and it might just be easier to persevere when change does happen.
It sounds like you’re 2010 is going to require a lot of both. . .
Thanks for a great comment!
November 7, 2009 at 10:54 am
Great post. I have a friend in IT Security who maintains that the goal is not so much to prevent any and all unauthorized system entry, but to mitigate any possible damage once (not if) someone finally hacks it.
November 9, 2009 at 10:46 pm
When is the next in the series – “The resilient project – complexity as change”?
November 13, 2009 at 2:59 pm
[...] many of you know who follow my thinking, they key to successful projects is resilience: how well a project adapts to change. The implication of this line of reasoning is that success or [...]