How Might We Identify the Key Drivers for an Initiative

I often read SOA strategy & planning discussed in terms of developing of a plan to build services that align to core competencies of the organization. When I unpack that statement, it reflects the same needs as the following: "The plan for individual initiatives should emerge in alignment with the key drivers of an initiative." So, I started wondering, what sort of guidance, tips or rules of thumb might be useful to identify key drivers for an initiative?

What triggered this train of thought:
Todd Biske's posts on Gartner AADI:

How does this relate to my work?
Regarding a session on Best Practices in Managing Change, the following statement resonated with me: "“The speed of technology deployment will not be gated by IT innovation, but rather by the ability to manage the people side of technology changes.”

That main me think; what should I ensure is explicitly addressed in the IT strategy & plan for a project - as a way to create synergies between the people side and technology side of changes that a project creates? I've pulled some of the recommendations out of the session notes and re-framed them as "How Might We" statements from the Creative Problem Solving Framework. This allows me to know apply the creative problem solving process skills to work through each of these dimensions. Therefore, the questions provides a checklist of areas to explore - and Creative Problem Solving provides the skills to systematically explore and address each of these areas.

What are the actionable guidelines/principles that I can apply in my work?

1. Remember and repeat its purpose (How might we communicate why are we changing)?


2. Explain the particulars (How might we describe what we are changing)?


3. Identify people that will need to change how they work (How might we outline who will be changing)?.

So, why should I care?
Well, frequently...our co-workers have a only a vague idea of why a project is important, and must trust that their activities are necessary and valuable. If the earliest planning activities made such goals clear and explicit, the execution will be smoother. When we veer off course or encounter an obstacle, these principles guide the decision making process with facts and accepted implications.

Putting together a Puzzle is Like Building a Capability Roadmap

Last night, I had a bit of epiphany while I was putting together a puzzle with my husband. I became conscious of how I would approach the challenge of combining the different pieces of a puzzle into the picture of the Strip. (Note: We discovered that the written description on the bottom of the puzzle was different on the puzzle from what was displayed on the box front. Oops! Production error) Here's the rough order of steps that I observed myself making as I put together the puzzle:

(1) Scan the pile of pieces and identify two or three "theme"s by which some set of pieces can be separated out.

(2) Put all of the pieces that match a particular theme into a pile

(3) Select some way to organize the pieces in one pile (e.g. if you're working with the edge of a puzzle; put all of the straight-edged sides facing down)

(4) Pick some characteristic of the pieces by which to start matching pieces with their neighbors. For example; the Lines on the side of the Wynn became a charateristic that I could start to match up.

(5) If you hit a wall; find some other charactertistic and put a few more pieces together.

(6) If all else fails; pick a piece and then try to find its neighbor. Try all rotations of a piece to see if it fits as the neighbor.

(7) Repeat until puzzle is done.

It dawned on me that there is something to be learned about how to put together a capability roadmap. Its easy to state a methodology for building a roadmap. it is much more difficult to break that methodology down into a methodical set of best practices to implement the methodology. For example; most SOA methodologies specifies the need to "Identify all of your core capabilities." The questions that comes to mind are:
(1) What are some criteria to use to determine if something is core?
(2) How might we differentiate between a capability and an application/process?
(3) How might we identify which capabilities are needed but missing?
(4) If we discover multiple missing capabilities; in what order should we build them out?
(5) How might we determine different alternative execution plans to deliver capabilities at the right time?
(6) How might we determine when a capability should be replaced?

By finding the parallels in the challenge between building a capability roadmap and putting together a puzzle, I realized that I could find a way to apply the methods I used in the puzzle to making a plan to build a capability roadmap. For example, I can line up the questions I want to have answered and solve for each like I would putting together a group of like puzzle pieces. Then I can take those larger groups of pieces and put them together. This tactic worked EVEN IF I DIDN'T HAVE A PERFECT UNDERSTANDING OF THE FINAL PICTURE. Instead, I needed to identify some pattern in the pieces that would help me put them together.