Tuesday, February 23, 2010

Change is a Value Precursor

You cannot add value without changing something. That's a fact. Think about it. I'll wait.

OK? Ready?

From gold made into jewelry to a consultant putting words on a page, the act of creative construction or destruction requires change. Therefore, change is by definition a value precursor. If you do not change something, you cannot add value.

This statement is not true in the reverse. Change does not imply value. Not all change is good.

"So what?" you say.

So, as an architect our job is to be a change agent. By definition we change things in order to create value. The value we create is by creating new objects, processes or artifacts. These changes can result in value to the business if we do our job very well. They can also become shelfware and provide zero value. This is the choice we make as architects.

As you view your architectural domain, think about the broad array of changes you COULD make. Then construct a system that allows you to make good choices by evaluating the impacts of those changes to the business. In most cases, the choices are not simple. Otherwise, the positive change would have already been made long ago. There are usually pros and cons for each choice. The cons are usually painful and sometime involve sacred cows within the organization that everyone is afraid of touching.

In a recent strategy review meeting, a broad array of choices were presented to the team. The problem space was very large so there were many things we could invest in and it was fairly unclear how to proceed. Many of the choices were interelated and it was unclear where we should start. I really needed to create some sort of structure to the problem because all the unknowns were making it impossible to make any sort of decision.

Step 1: Put things into buckets.

In this case, I needed to gather things up into smaller buckets so I could look at the buckets individually. Most large problem spaces can be bucketed up. Don't allow the team to wallow in deciding what the buckets should be. You can adjust later. This is just a framework for making the problem simpler. Sample buckets that I've used before:

  • Operations, Sales, Marketing (For a consulting company)
  • People, Business, Process, Technology (for an IT shop)

You get the idea.

Step 2: Sort into the buckets

Take all the random junk that you're talking about and put them into the buckets. If things are really out of control, I make people put their ideas down on sticky notes and group them on a wall or whiteboard. Then we argue about the groupings. Sounds dorky, but it gets people to think and DO SOMETHING instead of navel gazing.

Step 3: Sort within the buckets

Inside each bucket, you'll probably wind up with similar things. Group them by affinity then stack rank them. The things with the most positive benefit on the top. Again, as we have discussed you may not ascribe value to something that cannot be measured. Budget, headcount, morale scores are all valid criteria. "That's a cool feature" isn't.

Step 4: Assign priority

This is the hard one. If you have fifteen buckets, you can't go do them all. If you have four, you may be able to assign one to each team member. This is really a judgement call. I cannot tell you how to do this (sorry). I can say it gets easier with time. If you get stuck and the team cannot decide, fall back and punt. You can ether do an affinity matching exercise (where the team simply votes) or you can use metrics to decide (revenue breakdown, budget, etc.). Either way, making a decision is important and this step can't be rushed.

Step 5: Assign Owners

This is the point where the meeting usually ends. Everyone congratulates themselves on having a good meeting and NOTHING AT ALL HAPPENS. I've seen this hundreds of times. Unless you have specific action items with assigned owners nothing good will happen as a result of your hard work. Don't let your architectural heavy lifting come to naught. If you don't have the pull in the organization to get things done, be sure your sponsor is on board with the process and get them to make assignments and follow up.

My friends in the UK call this exercise the "bun fight" because of all the back and forth arguments that happen. I call it "making the sausage" because it ain't pretty but the result tastes pretty good if you know what you're doing.

Good luck!!

ITA

No comments: