How to make Soduko boring - Follow the Process

I spend a lot of time travelling to and from client sites, and when I travel I often pass the time by playing Soduko on my iPhone (I use a very good version from Mighty Good Games).  Once apon a time I relied on the paper versions in the airline's magazines - but the iPhone app is now my norm.

One incentive for playing Soduko was to keep my little grey cells from getting lazy - but it also a fun way to pass the time, so I was rather surprised last year when my friend Roberta told me that she had given up the game after just a few months of playing. According to Roberta - who is a math teacher - the game wasn't challenging any more.  She'd figured it out, and the puzzles were no longer puzzling.

My first reaction to Roberta's statement was typical for me - I just assumed that the Soduko puzzles she had access to weren't "hard enough".  Many, many times I would finish a flight with an unfinished puzzle from the American Way Magazine staring me in the face.  I certainly hadn't "figured out" Soduko.

Then in March I saw an article in USA Today about J. F. Crook and a Soduko "solution".  Crook is a mathematician, but his "solution" isn't a mathematical proof - it's a series of steps.  I'm a process guy - so when you say "series of steps" I say "process".  Crook had published a process definition for solving any Soduko puzzle.

I read Crook's process definition, and it wasn't that far from recommendations that I has seen earlier.  Soduko puzzles are grids of 81 squares, nine across and nine down. Some boxes have a number filled in; the rest are blank. Players must fill in the blank squares with numbers between 1 and 9 without repeating any numbers in a row, column or the nine interior 3-by-3 boxes of the puzzle.

Crook's Sudoku Solving Process can be summed up as follows:  Mark all the squares in the puzzle that could be a "1" - Based on "what could be a 1" apply some simple rules to "solve" a few squares.  Repeat this process for numbers 2 thru 9.  Crook admits that you still may find some sqaures that might be one of two numbers, but you just "guess"  a number for that square and proceed until your guess is either confirmed or invalidated.

The problem with Crook's Process is that it's really tedious. While solving a Sudoku puzzle you'll often have insights or spot patterns that lead you to solutions for a whole bunch of squares at one time.  Consequently, when I read Crook's Process I said to myself "That's nice" and went on solving my puzzles the same way I always had.

My method for Soduko was to "solve" the obvious squares first, then scan the whole puzzle looking for the less-obvious relationships between the squares.  Using that rather random process I could solve many "Moderate" puzzles in ten to fifteen minutes, but I was also frequently left with puzzles that I just couldn't crack.

When I switched from paper Soduko to iPhone Soduko I initially followed my old-but-not-reliable process... but the iPhone apps features opened my eyes to "the better way".

With paper and pencil it's really messy to follow Crook's Process.  There's a lot of erasing that goes on, and it's really easy to make mistakes.  With the software version I can mark/unmark squares to my heart's content without reducing the legibility of the puzzle.  The software version also immediately flags my mistakes, so I don't multiply those mistakes by contiuing on with bad data driving my subsequent decisions.

A little bit of software can make it a lot easier to follow a process - Who would have imagined that? :-)

Even with my new found ability to make notes on the puzzle - I still stuck to my old process for the most part.  I's use my process to solve as much as I could, and then resort to Crook's process... and sure enough I would still get stuck with puzzles that I just couldn't solve.  This didn't happen often, but it happened.

I should mention that up until this time I was limiting myself to the "Moderate" puzzles on my iPhone. It's very unsatisfying to have an unsolved puzzle when my plane lands, so I stuck to the relatively easy ones for the most part.

On a recent flight I decided to tackle an "Expert" Soduko puzzle - and it was a bear.  I was so intimidated that I followed Crook's Process.  I diligently marked all the "1's", then the "2's", etc. and sure enough in 30 minutes I had solved the puzzle.  I tried again with a new puzzle, and sure enough, in 30 minutes I had solved that one too.

Since that time I have improved a bit, I'd say my average is about 25 minutes, but sure enough I can solve any puzzle as long as I keep to the process.  Just like Roberta, the puzzles aren't really puzzling anymore.  Give me 30 minutes and I will solve the puzzle.

The trade-off here is that I won't be able to solve any puzzle in less time.  The process is tedious and it's not easy to speed it up.  I sacrifice "brilliant flashes of insight" for dependable, predictable, and plodding.  The process makes Soduko boring.

As always I have to turn this experience into an analogy for the domain of Managed Business Processes:  I could have followed Crook's Soduko Solving Process all along - but a little bit of software really made the process easier to follow. Software made each step of the process easier, but it didn't force me to stick to the process - If the software had managed the process (forced me to stick to the process) I would have achieved the goal of consistently solving Soduko puzzles sooner.

You might be saying - "Yeah, but it also made it boring".

That's certainly something to consider when introducing a Managed Business Process into your organization... We don't want to turn our process participants into mindless drones.  We don't want to lessen the importance of creativity and insight - but we do need to make things more predictable and insure success.  Finding the balance between predictable process and bored employees in your organization is a puzzle that won't ever get boring.

Tips for the Business Process Developer - Process Data Perspectives

Those of us who build Managed Business Process solutions for a living have to spend a lot of time thinking about data. Our BPM suites (like Teamworks) make it a snap to define Process Flow and Routing, but we still have to make sure that each Participant in the process has access to all the data that they need to accomplish their tasks.

I always insist that folks implement their process flow first. Build a place-holder for each Activity in the process, connect them up with flow lines and any necessary Decision Gateways, and add in just enough process data and build just enough user interface to make sure that you can play back each step through every path in the process with your business folks.

Building this much of your process first has huge paybacks - There's nothing like stepping through a process to validate whether or not the business folks agree that you've got the process right. Validate the process requirements first - worry about everything else later.

Once you have this first playback of the process done you've got to turn your attention to defining the rest of the process data... and suddenly it's not as clear how to proceed. Where do you start?

The data aspects of a Process encompasses many things that you might not consider when developing other types of applications. There are several common process data patterns to consider - processes gather, transport and transform data across activities that are performed by multiple participants. Data models often dynamically evolve and transform as the process proceeds.

I've had several recent discussions with Fahad Osmani and some of my other Lombardi colleagues about how to effectively develop process data models. We've all implemented a number of managed business processes - We've all thoroughly mastered the craft of implementing processes - But we haven't really formalized our approach for designing process data models. Knowing in your gut what to do is great, but formalizing that into something that you can share with others is better.

Here's what we've come up with so far:

In every business process you've got a variety of actors with a variety of perspectives that you have to deal with - we've abstracted this into the following list:

1. Process Owners
2. Process Analysts
3. Process Participants
4. Process Builders


We've found it best to design a process data model from each perspective in this order, and then consolidate those models into a consistent unified model.

The Owner's Perspective of Process Data:

Start with the owner's perspective of process data - the folks with overarching concerns to make sure that the outcome of a process is achieved. If you're working with a Bank on a Loan Application process, these are the managers of the Loan Department who are held accountable for efficient and effective handling of the loan applications.

Owners have a business perspective on the process data. They've got the big picture business view of the process payload - What are the basic business objects that the process deals with? What data is being gathered? How is the data transformed during the process? What happens to the data when the process ends?

Owners often see process payload data as starting points and outcomes. Their major concern is with the state of the business data "now". They care about the state of the business objects when the process starts, the state of the business objects at key milestones, and the state of the business objects when the process finishes. The owner's data model provides that information.

Beyond the payload data, owners also perceive data in terms of process rules - What data determines which activities to perform? What data determines when a task is due? What data determines who should perform a task? The owner's data model answers these questions.

The Analyst's Perspective of Process Data:

Process Analysts are the folks who look at historical process metrics to figure out if the process can be tweaked to work better. In some cases the Owner may also be the Analyst - but the Analyst perspective really is different. In a Loan Application process, the analysts are the folks who evaluate the effectiveness of the process itself in the hopes it can be improved in the future.

Analysts deal with understanding the past to improve the future.

Analysts view the process data as snapshots in an album. Their view of data is intricately linked to the process diagram - The snapshots are meaningless to them unless they know where the snapshots were taken.

Analysts care about how long things take and why some things take longer than other things. Analyst care about "rework" (tasks that have to be redone). They don't really care much about what's happening now - they care about what happened over some time period. To meet the analyst's needs, process context data (and time stamps) are stored at specific points in the process. Making sure that the right snapshot is taken at the right time is their major concern. The analyst's data model works in conjunction with "snapshot events" in the process flow to capture the information the analyst needs.

The Participant's Perspective of Process Data:

Participants in the process are the folks who are tasked to perform specific tasks. Sticking with a Loan Application process, these would include the Loan Officers who review and make approval decisions about loan applications.

Participants care about now. Their perspective of process data is immediate. What forms do they need to fill out? What fields are on each form? What are the acceptable values for each field on a form? Participants view data from a task level - What information do they need to consult and what information do they need to gather and modify to accomplish their task.

Some information is passed to the participant when they are assigned a task, and some information they look up - but it's all information that is necessary to accomplish a task. Making sure that they can access data and modify the data that they need is their major concern.

One special caveat when considering the Participant's view of data is to ask whether or not any of the data that the Participant changes must be "immediately" seen by others. Data visibility requirements like this are critically important to the Process Builders.

The Builder's Perspective of Process Data:

Finally we get down to the Process Builder's view of the process data - that's us. We really can't do our work until we understand what the Owners, Analysts and Participants need.

Builders care about the actual structure of the data. What data are we going to pass around and how are we going to pass the data around? What data needs to be stored an retrieved and how are we going to store and retrieve the data? How are we going to meet the data visibility requirements?

The Owner's perspective helps the Builder define the major business objects that the process will deal with. The owner's data model also identifies the data that is used to determine which paths are taken, how long each task should take, and who should perform each task.

The Analyst's perspective helps the Builder define the data structures for the snapshots that are taken throughout the process - and informs the Builder where in the process the snapshot needs to be taken.

The Participant's perspective helps the Builder define the process payload (the data that is passed to and from tasks) and it helps them define the data system architecture that is required to retrieve and modify data within activities.

The Payoff:

The end result of this multi-perspective approach is a model for process data that just plain works.

It takes a bit more up-front effort, but you are less likely to get blind-sided by unanticipated data requirements popping up late in your development cycle. The data requirements may change, and any requirement change may still require substantial rework - but odds are the rework will be much easier for you to accomplish.

Clearly understanding requirements from the perspectives of your the process actors always pays off - and this axiom is doubly true when data is involved.

Open Source + User Builders = Great Products

I read this story over at npr.org this morning:

"Before Jonathan Kuniholm had a tour of duty in Iraq, he worked for Tackle Design, an industrial design, research and development firm. After that tour, he was missing part of his right arm — which he lost when his Marine patrol was ambushed near Haditha.

When Kuniholm returned to his design shop, he brought along three prosthetic arms given to him at Walter Reed Medical Center — the same body-operated hook many veterans have used since World War I, a shorter utility prosthetic, and a new, state-of-the-art myoelectric arm. Each one had its drawbacks — and when Kuniholm and his Tackle Design colleagues disassembled them, they quickly concluded that they could improve on the designs. They founded the Open Prosthetics Project, an open-source collaboration that makes its innovations available to anyone. And Kuniholm signed on with Revolutionizing Prosthetics, an initiative of the Defense Advanced Research Projects Agency, or DARPA."

There's an important lesson here for every company that builds products:

1. Users are a better judge of what your product should do than your developers.
   
2. Users who have the skills to build your product themselves will improve your product if given the chance.
   
3. If you don't let your User/Builders improve your product, your product won't be as good as it should be.