My Inner Gandalf

Wizard_HeadingI knew from the looks on the other committee member’s faces that I had done it again. I had thrown my idea out on the table – whole cloth – without considering for a moment the effect on my audience. It was a terrible first impression, but the damage was done. Driving home, I turned over in my mind how I could have handled it better. My car nearly left the road when a voice in my head said, “Steve, channel your inner Gandalf.”

The chapter “Queer Lodgings” from The Hobbit had popped into my head. In it, the wizard Gandalf convinces Beorn – a reclusive character – to accept a wizard, a hobbit, and no fewer than thirteen dwarves as unexpected dinner and lodging guests. He does so gradually, by telling Beorn the story of their adventures up to that point, while gradually increasing the number of characters and introducing them in pairs. It has the added effect of making their host more intrigued by their story.

It is a clever literary device and great fun to read. In real life, of course, it requires a “wizardly” presence of mind in order to pull it off. That fact notwithstanding, the concept holds value. At the same time that it introduced the change initially as a rather minor detail, it gradually wrapped the entire request in context so that agreement was all but guaranteed to a reasonable mind. The gambit had both subtlety and framing, and divided the aspects of change into “easy-to-chew” sizes.

I will in no way try to cast myself as a writer of any merit, much less one as gifted as J.R.R. Tolkien. Nevertheless, I thought it would be fun to attempt an illustration of this idea within the context of a real world business problem. What follows is an entirely fictional conversation between a consultant (our wizard), and a CIO (the bear in our story).   The consultant has discovered why the CEO’s daily sales flash reports are routinely late, but he knows that the cost of mitigation is going to cause extreme heartburn on the executive floor.

“Mr. Bruins, thank you for taking the time to meet with me.”

“Ben. Please call me Ben. And tell me your name again?”

“Dan. Dan Galf. I’m a consultant with Bertram, Thomas, and William. Our firm has the contract to develop S.M.A.U.G, the data warehouse feed from your new global costing tool.

“Nice to meet you, Dan. What can I do for you?”

“Well, perhaps it’s what I can do for you. As you know, your global costing system generates tons of data every day and we’re worried about processing time. Consequently, we’ve been looking at some of your existing procedures in order to squeeze out the best performance possible.”

“Sounds reasonable. What have you found?”

“Something curious. It’s a program that runs as part of your daily overnight processing. All it does is attribute some of your store-level general ledger data, but it runs on average for five hours per night.”

“Why is it so slow?”

“That’s the curious part. It updates the records one store and one attribute at a time.”

“I’m not technical, Dan, so I don’t understand why that is bad.”

“Consider this analogy, Ben. Suppose you have a large pile of treasure dumped at one end of a football field and every night you need to move a specific cubic foot of that treasure to the other end of the field. Rather than selecting the cubic foot you need and carrying it to the other end in a bucket, you choose to move the entire pile in order to guarantee that you deliver the part that you need. Moreover, instead of using a bucket you use a teaspoon. That’s thousands of trips across the field, and most of what you’re moving is unnecessary.”

“That does seem extraordinary. What’s the reason for it?”

“None that we can figure out. We’ve even met with some of your business folks and they can think of no earthly reason for it.”

“Have you spent much time on this quest?”

“We’ve logged about thirty hours. Several of us have looked at it because we thought we were missing something at first.”

“Well, don’t waste any more time on it Dan. But thank you for bringing it to my attention.”

“Before you dismiss it, Ben, you may want to be aware that this is the reason your CEO’s daily flash reports are late.”

“It is? Are you sure?”

“Absolutely. That report suite depends on this daily re-attribution process.”

“Oh. I see. That’s different. Madeline has been beating me up about it for weeks and she can be a real dragon. My people have been telling me that it’s a hardware performance problem.”

“We can help you fix the problem, you know.”

“Really?”

“First, we need to understand the existing procedure. There are places where it just doesn’t make any sense and your business people can’t explain the business rules.”

“How long will that take?”

“It could take as few as eight hours if the business can provide answers readily. If not, it could take substantially longer.”

“I see. But once you figure that out you can fix the problem?”

“We will need to do some design work first.”

“Why?”

“The current design forces you to scan all of the records multiple times, even though you only care about 8% of them. And of that 8%, you rarely need to change more than 11% on a given day. A more efficient approach is to partition the data based on relevance. Performance will be significantly better provided that the technical challenges of breaking the data up are addressed, hence the need for good design. That’s probably between twelve and sixteen hours of effort.”

“Okay, design. And then you do the fix?”

“Yes. Writing the new code will only take a couple of days, maybe twenty hours at most. We will need to spend at least as much time testing, though.”

“Why so much?”

“This is a key procedure driving, among other things, your daily flash, right?”

“Yes.”

“And the business makes key decisions based on those reports, right?”

“I get it, Dan. So altogether you’re saying this procedure will require…let’s see…, uh ninety-four hours to fix, including time already spent.”

“Don’t forget about coding and testing the deployment code. Figure another eight hours there.”

“So, one hundred and two hours.”

“And filling out and submitting the change management forms. Another couple of hours there.”

“Anything else?”

“Another two hours to document what we did so that whoever comes after us doesn’t need to spend so much time on discovery. Maybe add another four in case we hit a goblin along the way.”

“Well, it makes sense the way you’ve laid this out, but one hundred ten hours is a lot of time to fix one procedure don’t you think?”

“It’s a complex data set and we don’t want to buy performance at the cost of accuracy. Bear in mind also the cost associated with bandwidth trolls like this.”

“Well, I’ll probably have to green light this although it exceeds my monthly maintenance budget. Let me get approval and I’ll get back to you.”

 

Wouldn’t it be nice if the world were a reasonable and rational place where a conversation such as the one above could possibly take place? It is not, of course, so it must remain a fictional example of how to break an idea out into its constituent elements, laying it out in pieces so that it can be assimilated gradually. Also note that in today’s world the effort would probably have been absorbed into two Agile sprints instead of being cast as a linear “waterfall” effort. Bottom line, though, if Dan had thrown the 110 hours on the table at the beginning, Ben would probably have stopped listening.

Not being wizards, it will work much better for us if we direct the process as a series of questions that lead others toward a proposed solution. Here are the five steps to the process.

  • Step 1: Begin by pointing out a factual condition and then ask one or more clarifying questions. For instance, “I was looking at the third bullet point in the selection criteria. Does anyone feel that it might be worded too broadly?”
  • Step 2: Ask some more specific questions to illuminate the nature of the potential problem. “The wording stipulates that our selections express the memory, values, traditions, customs or aspirations of the community. Does this mean that each of us is to apply our own understanding of what those might be or do we need a more concrete set of examples?”
  • Step 3: Only after the group begins to acknowledge that an improvement might be desired can the next step be taken. Instead of proposing a solution outright, ask instead for characteristics of a solution. For instance, “What might those examples look like?”
  • Step 4: Close the circle. “Where might we find that information?”
  • Step 5: Finally, if your idea has not yet been suggested, make your suggestion in the form of a question. “Do you think a town hall meeting might be an appropriate venue for gathering that information?”

 

I am looking forward to the practical application of this refinement in my personal style. Never again do I wish to see the looks of confusion and fear on the faces of my colleagues and clients. I may even try practicing this at home when I need to introduce a new idea into our routine. Of course, my wife proofreads these musings ahead of publication so she will be on to me right away.

At this point, my readers may be wondering why I am offering advice on something I have never tried, practiced, or been successful with before. I am not offering advice. I am offering a way of thinking about our lives when we find ourselves yanked from our comfortable mental hobbit holes to face unpleasantness in the form of our own weaknesses (I mean, opportunities for improvement). So follow along. The truth and the growth – as well as the adventure – is in the journey, not the destination. Just ask Bilbo.

 

What techniques do you use for creating buy-in for new ideas? Do you think self-awareness is overrated?

Follow the People

Footprint_PB

Life reminded me recently how important it is as BI practitioners to keep the paradigm of program design at the forefront of our thinking and planning. Many of you know it: people before policy before procedure before technology.  The interesting thing is that the reminder came not from my professional life but my personal one.  Those of you who follow this blog already know how the line between those two sides blurs for me, and how one seems to be continually informing the other.

My readers also know how I like to spin a story in order to illustrate a point.  Consider this one.  Our family moved to a small community on the Olympic Peninsula in Western Washington last year and enrolled our daughter in a rather inspired alternative public school.  Late in the school year a small controversy involving a teacher mobilized nearly every parent in the school.  My wife became one of the spokespeople for the parents in our communication with the district leadership. Long story short, clear heads and a little bit of listening resolved the issue quickly.  In the aftermath, though, someone nominated my wife and me as co-presidents of the PTO for next year.  It is a small town; there is no getting out of it.

In preparing for a follow-up meeting with the school district superintendent, a group of us were assembling the agenda.  What should have been a relatively easy task was uncomfortably difficult until I realized that we were jumping right to procedures without having established requisite relationships.  The program paradigm, which I had learned years ago, popped back into my head and helped us bend our thinking back toward establishing the people part of the program – the relationships – first. Time enough for procedures later.

And of course that got me to thinking.  It got me to thinking not only about how best to shape that meeting, but also about the criticality of people in shaping and managing BI programs and governance.  My first challenge was a semantic one, the definition of a program.  The concept is largely unknown in the education world and I needed to be able to articulate it for my colleagues.  It is also not always understood clearly in the business world.  Awhile back I blogged about BI programs, suggesting a definition for the concept.  I went back to the article and was hugely disappointed.  While the definition worked just fine for that one specific business technology discipline, it was too wrapped up in the jargon of business and technology to be useful anywhere else.   That was a big “Aha!” moment.  Our definitions for these important concepts need to be pan-applicable if they are to capture the key nuances that make them work.  So here is my latest draft of a definition for program, crafted for a public school PTO.  Not surprisingly, it works even better for a BI program.

 A program is a set of activities, projects, and initiatives undertaken by multiple stakeholder groups and constituencies to achieve and maintain a shared vision or need.

 This will not be my last revision of that definition, I suspect, but now it captures the starting point for the program paradigm nicely.   And the flow of the paradigm has a rigorous logic to it that can keep us from wandering astray in developing any sort of program.

  • People:  We must always put people first.  People are what work, business, income, school, life, and everything else is all about.  In establishing and maintaining a program of any kind, the stakeholder groups and the constituencies are at the center. What are their visions, desires, needs, and fears?  How do we establish alignment across these groups?  Even within a stakeholder group there is rarely alignment.  My public school situation is a perfect example.  There is not, nor will there ever be agreement across the parent stakeholders.  But by working together to understand the collective visions, desires, needs, and fears of this group we build trust, which is the foundation of relationships.  These relationships will enable us to come together in a shared vision that is three-dimensional, meaning that while we have achieved general alignment and buy-in, there is still broad variation in point of view behind it.  Diversity with alignment is essential to good policy making.
  • Policies:   Policies are the rules used to guide the stakeholders in their journey to establish and maintain these envisioned goals.  Good policies shape behaviors that result in desired outcomes. The body of policies defines the environment in which the identified end state will exist, and how it will be maintained.  Going back to the public school example, a good communication policy would enable the stakeholder groups (i.e., parents, teachers, and administrators) to have the information they require to be effective in their roles and not to be blindsided (resulting in loss of trust) by actions or decisions that affect other groups except in cases where legal or ethical circumstances prohibit.  Policies drive procedures.
  • Procedures:  Procedures are the specific processes we use to implement policies, achieve goals, and perform our work.  Procedures can be formal or informal, but they form the structure of what specifically is to be done, along with when and how.  The procedures driven by the communication policy would articulate the topics to be communicated, the people responsible for communicating them, the individuals to whom they should be communicated, and the appropriate media for doing so.
  • Technology:  Technology comes last because while it is potentially very powerful, it is only an enabler.   If the program has not attended to the requirements of the stakeholders, the policies are hardly likely to meet those requirements. Consequently, the supporting procedures are likely to be poor. Leveraging technology in such a situation only exacerbates the already spurious results.  Applying this to the school example, no amount of email is going to result in role effectiveness and optimal trust if the appropriate individuals are not sharing the appropriate information with the appropriate people at the appropriate time.  Instead, the resulting worm fight of email can spin out of control in minutes, returning quite the converse.

All too often in BI we are tempted to jump right into the technology.  Some of the time, I think this is because the technology is the fun part.  Mostly, though, it is because the value of the first three steps is not clearly understood.  There is often the perception that if I am not writing code, then I am not doing my job.  Certainly in building a detailed project plan or laying out a statement of work, the technology aspects are the last to come under fire.  “Do you really need all this time for requirements analysis?”  “Process design?  There’s nothing wrong with our processes.”  “What do we need data policies for?”  Sound familiar?

So, what is the answer?  The answer is to start at the beginning with the people.  Each new project, each new client, each new program is an opportunity to establish and nurture relationships.  Even with established clients, it is an ongoing process as roles change or as individual lives change.  As part of those relationships, we continue to establish their individual and collective importance by enlisting those relationships in nurturing others.  In other words, lead by example.  If I don’t have a good relationship with CFO Bob – one in which we have achieved some alignment on goals and vision – Bob is not likely to see the value in spending money for the two of us to establish relationships with CIO Gretta, even though Gretta’s active participation in the new BI program is critical.  Gretta is not necessarily going to jump onto Bob’s bandwagon just because she is paid to.  It is about her vision, desires, needs, and fears as well.  And at the end of the day, it is all about trust.

I have written quite a bit about trust both in this article and my last.  Trust does not mean blindness or inattention.  More than once in my life someone I trusted has shafted me unexpectedly, and I think most people have experienced this.  While trust is essential for successful working relationships, we must proceed with our eyes and ears open, and our intellects engaged.

Bottom line, following the people is really more fun even than coding.  What I learn every day from the people with whom I work is far more valuable and stimulating than what I learn from a block of code no matter how abstruse.  And while finding solutions for people problems is scarier, riskier, and more difficult than solving a technology puzzle, it is far more rewarding when we succeed.  But oh, look at the time.  I need to finish this code before end of day.

What are your top strategies for building trust in working relationships?  Do you actively develop and nurture relationships in both your professional and personal lives?

The Art of Practice

“Steven Humphrey, you sit right back down on that piano bench and do your scales.  Practice makes perfect, you know.”  That was my mother speaking, some terribly many years ago.  Like the piano, that aphorism has stuck with me over time.  It sounds right, doesn’t it?  But if there is any truth in it, why is there so much imperfection in the business world, especially in light of how routinely the term “best practice” gets hurled about? Vendors tell us that their products conform to and promote best practice.  We consultants advertise our services as best practice.  Governance committees establish best practices for their enterprises.  It is easy to search the Internet for lists of best practices on just about any topic. The term is ubiquitous, but what does it really mean?  And how does one recognize a best practice?

Anyone who knows me well knows that I am a word wonk (and I promise at least one linguistic rant here soon).  In this case, I know very well that I am playing with two shades of meaning of the word “practice.”  On the one hand, practice is a routine activity used to improve a skill, like practicing scales at the piano.  On the other, it is a standard or habitual way of doing something, as in “it is our practice to begin and end meetings on time.”  So I ask again, why the imperfection?  I submit that the fault is not just in the aphorism but also in the way we think about the words.

First, I abhor the term “best practice.” I find hubris in the term “best,” as if a practice could be best at all, let alone best in all cases.  Further, there is a subtle implication that it cannot be improved upon; it is best.  It rings like an absolute that nobody should dare challenge. It is limiting and not very useful.  I prefer the term “leading practice.”  The word “leading” brings to mind something that is out in front but not yet arrived.  It leaves open the possibility of variation and seems more welcoming to debate and difference of opinion.   It is a work in process, striving for continual improvement and…well, leading somewhere, not unlike the other meaning of practice.  For the balance of this piece, therefore, “best” will be “leading.”

A leading practice is an activity or repeated action that is considered to be more effective in delivering a desired result than other activities of its kind. This is a rather broad definition and can mean a lot of things absent an understanding of the characteristics of a leading practice.  I had the opportunity some time ago to develop a group exercise to demonstrate how to recognize a leading practice.  The concept was that each organization is a unique ecosystem and an activity that is more effective in one company may not be so in another.  But with an understanding of the characteristics to look for, an organization would know how to identify, craft, and improve their leading practices.

In the first cut of the exercise, I came up with eighteen characteristics.  I stand by all of them (and I have the data to do that), but eighteen is too many for the scope of this article.  Therefore, here are what I consider to be the top eight characteristics of a leading practice.

  1. The practice promotes or enforces consistency.  This applies to consistency of data, processes, decision-making, and much more. Consistency breeds clarity and lowers the cost of maintenance.  Consistency should be distinguished patently from uniformity.
  2. The practice reveals priorities and fosters clarity of direction and alignment.  Most activities in a company should be focused on achieving strategic objectives.  Leading practices keep the collective eye on the ball.
  3. The practice reveals discrepancies and reduces error and ambiguity.  This reduces the cost of rework and troubleshooting, and improves the quality of decision-making.  It also facilitates precision across an enterprise.
  4. The practice promotes continued relevance.  What is relevant today may not be tomorrow, and conversely.  Does the activity include a continuous or periodic check to determine if the outcome or end product is still meaningful to the business?
  5. The practice reduces risk.  Life is full of risk and not all of it can be controlled.  But an activity that addresses controllable risk on a consistent basis adds tremendous value.
  6. The practice facilitates competitiveness.  Does the activity improve competitiveness in the marketplace across one of the vectors of price, quality, and value?
  7. The practice promotes awareness and accountability for results.  These activities provide appropriate measurements for results along with a means for driving improvements.
  8. The practice promotes sustainability.  This supports the ongoing health of a program or organization, not simply short-term objectives.

Clearly, these characteristics are driven by desired behaviors and results.  The behaviors are the habits and disciplines on the human side while the results represent the business outcome of the practice or activity. Any single leading practice will not possess all of these characteristics, but must embody at least several of them in order to be considered a leading practice.  This is one reason why my original list of eighteen is realistic; it provides a breadth of behaviors and outcomes against which to match the practice within a particular organizational ecosystem. I look forward to performing my exercise with other groups of people and seeing how the list might evolve over time.

Note also that while each of these characteristics is distinctly different from the others, each also overlaps with others in subtle and complex ways.  For instance, risk reduction is really an outcome of several of these characteristics.  Relevance is a function of direction and strategic alignment.  The reduction of ambiguity leads to consistency.  And so it is across the larger collection.  The characteristics of a leading practice are more like an ecosystem themselves, balancing the desired behaviors and results across the organization.

Leading characteristics are particularly useful for a governance body that is developing or refining a program’s policies and procedures.  Being able to articulate the behaviors and outcomes that are being sought is the first step in that process.  After defining what needs to be accomplished, the how becomes easier.  It is not unlike planning your menu for the week before writing the grocery list.  Employing leading practices is a key success factor in business today. Understanding them well enough to vault past the buzzword is where the value lies.

I still practice the piano, but I no longer believe that practice makes perfect.  The word “perfect,” like “best,” has little relevance in the real world, hung out as a goal but acting as an artificial barrier.  Practice promotes continual improvement, as does the use of leading practices.  Both are paths rather than destinations.  So I have abandoned the aphorism from my childhood and replaced it with another I picked up on the road.  “Never let best get in the way of better.”  Now it’s time to get back to my scales.

**

In a subsequent post, I will provide detail on the exercise I discussed above that generates the list of leading practice characteristics. It is relatively easy, and the raw ingredients needed are available all over the Internet.