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?