Problem-solving tool: work backwards from the goal
In IT we have our share of problems, both technical and non-technical. Sometimes it’s difficult to figure out how to address our issues.
One technique I learned from my grandfather is to solve problems “backwards”–start with the end and move back to the present. I often use this technique when I get stuck, say in thinking about how to create an IT governance group or in creating a service catalog. The two basic steps are:
- Define success
- Work backwards from that success state
Define success
See my other write-up, “Define your vision of wild success.” You want a very specific vision and a narrative. For example:
It’s July 2016. The IT governance group is meeting for the first time. All the members are at roughly the same rank. They include representation from the groups that tend to be upset at IT, plus groups that tend to be satisfied with IT. I am the chair of this group. There is a charter for the group to explain its composition and why it exists. All these people understand why they are here.
We discuss all the IT work that people want done and what IT is already doing for them. For example we talk about the projects that we must do, e.g. projects to replace network infrastructure, and projects that we have been told we should do, e.g. projects to automate identified business processes. They see this group could be a way to reallocate IT resources but that they will need to own the impact of this reallocation.
They see this meeting as a valuable use of their time. The meeting ends on time or even a bit early. The meeting made my life easier.
The above is probably not specific enough to be useful, but it’s a reasonable first pass. I particularly like to think about how should people be feeling because that can help you clarify your assumptions about what success looks like.
If you cannot write down a clear vision, that’s your first issue. You may need to talk with someone who has more experience in what the goal state could be. You see this all the time in ITSM processes: people want “change management” for example but they do not know what the vision state is.
Work backwards from that success state
Now that you have that definition of success, you can identify things that need to be in place. Following from the above definition of success:
- Need to send a meeting invitation in order to have a meeting, probably at least a month ahead of time
- Need to know who to invite to the meeting
- Need to talk with potential IT governance group members one-on-one about IT governance, to see what they think and where they’re coming from
- Need a room that is seen as being in a neutral location
- Need to anticipate any “burning questions” attendees may have and have them addressed prior to the meeting to keep us on track
- Need some way to present existing IT commitments
- Need a small set of realistic choices to provide them (e.g. they probably can’t say no to the network, but they could agree whether support for the capital campaign takes precedence over automating procurement processes)
- Need to set expectations about what that meeting can be used for
- Need IT staff to know why this group is being created
- Need people to feel like the effort is worth the time
If in defining success you thought about how people should feel, that can help you think through more whether to have food or handouts.
A great side-effect of starting with your success state is that it validates all your actions are actually helping you move towards your goal state: all of your actions are helping you move towards defined success.