Synaptus

Gordon Pask (1928-1996) was a psychologist who contributed an important theory in the area of instructional psychology. So why do we care? The theory is called Conversation Theory and the fundamental idea is learning occurs through conversations about a subject matter which serve to make knowledge explicit. Due to the pace of change and the high level of service demanded by customers, learning in organizations is becoming more and more important. So, there are three interesting concepts I want to discuss about Conversation Theory that apply to how businesses works today.

First, knowledge is not explicit until both people understand it. That sounds circular, but its important to think about this. Whenever two people are talking they come from different backgrounds and experiences. Since everything we learn is informed by what we already know, then if we don’t share a common history,  or common background of understanding, then we won’t have the same understanding of what we are talking about. We call the common background of understanding "group norms". When someone from outside the group tries to participate in a conversation, they might not understand all the implicit concepts that the conversation is built on. You will see this whenever people from different specializations are dealing with each other. Sales doesn’t understand the field. The field doesn’t understand IT. IT doesn’t understand Finance. Instead of forcing the other participant to understand something "obvious", take a moment to understand why it isn’t obvious to the other person.

Second, concepts build on each other. You can’t force the next concept until a dependent concept is understood. When Frank, the best man at my wedding, was trying to get his four year old daughter, Devon, to learn French, he had a teacher walk her around the neighborhood. The teacher walked around saying, "The French word for tree is [whatever the French work for tree is]." "The French word for house is …" She spent about 30 minutes going through this with Devon. When they finished the walk, the teacher asked Devon if she had any questions. Devon responded, "Yes. What is a word?" The lesson was lost because they didn’t share a common context for knowledge to become explicit in. Looking for what is not explicit in the background of understanding is a key step in resolving many conflicts and breakdowns in organizations.

Finally, Pask says we participate in different conversations in different ways. So we participate in conversations differently with our children then we do with our business partners or the rude person in the parking lot. The way we participate has to do with what we have seen or experienced as successful in other conversations. What’s compelling here is that very few people take anytime to understand how they are participating. So while we might choose a way of participating that is in the best interest of the situation, we might not. If I had a dollar for every person who said, I can’t understand this because I’m not technical or I’m not for the field I would have a lot more dollars that I do. They are making a choice to participate in a way that they prevents knowledge from becoming explicit. Understanding how we and others are participating in a conversation has a lot to do with how successful the conversation will be.

As you run into situations where there are breakdowns in communication, problems with understanding, or conflict between individuals, apply these two concepts. Instead of driving the "obvious" point home of assuming the other person is stupid is will never get it. As you work in your job, look for what is not in sync in the common background of understanding, try to understand what concepts are needed and relevant to make the point, and practice participating productively. With the growth of diversity, rapid changes, and the integration of concepts from multiple fields this is an important skill to begin to develop. If both parties can learn to look at these three concepts, tremendous advances can be made in improving collaboration. Do you see any points where these concepts would prove useful?

I was a contributor to the development of Microsoft’s "Business Architecture" offering in 2005. Since then Synaptus has been engaged in performing several Business Architecture Services engagements for Microsoft. so that means we do technical work, right? Or that Microsoft is selling some application in their Business Architecture Services offering? No and no.

In my conversations with business executives there is a lot of confusion about what Business Architecture is. Business Architecture provides the link between the strategy of a business and what a business actually does to accomplish its strategy. At the highest level, it isn’t about process, technology, or people. The whole point is that by describing what a business does and where there are gaps in ability to achieve the strategy in terms of capabilities, management can more easily decide where to focus its efforts.

Enterprise Business Architecture defines business architecture as:

"what the enterprise must produce to satisfy its customers, compete in a market, deal with its suppliers, sustain operations and care for its employees."

"Enterprise Business Architecture defines the formal link between the enterprise business strategy and the results predicted from supporting strategic initiatives. "

"A comprehensive framework used to manage and align an organization’s business processes, Information Technology (IT) software and hardware, local and wide area networks, people, operations and projects with the organization’s overall strategy."

National Institutes of Health

"business architecture serves as the interface between the needs of the enterprise as reflected in its work and the IT solutions that facilitate that business. "

Nexient has the best definition I found, although it is applied specifically to government:

"Business Architecture provides a disciplined approach to the alignment of programs, services, and processes with the strategic goals of government. It is a formal, structured mechanism for evaluating the current state of programs, services and processes against the desired state, and for giving decision-makers the information they need in order to direct resources - human, financial, technical - to the best effect."

So its not about technology, its about the business. Here are some keys concepts to wrap your head around business architecture:

1. Strategy is difficult to execute unless you can clearly articulate what a business has to do to accomplish it and then align all the efforts of the business with that strategy. For example, increasing profitability is a complex thing to accomplish in a business. Business Architecture is a way of understanding this complexity in your business. It can overcome "silo-myopia" to help define what is the next most important place to focus process, technology, and people efforts to accomplish your strategy.

2. Business Architecture involves models of the business. Because people live at different levels in the organization, have different responsibilities, and may have very different areas of expertise, not everyone has the same perspective of what is important to the business. Without a way to model and gain agreement on what the business is about, strategy is difficult to execute and conflict will arise when prioritizing efforts.

3. It involves extending your view to articulate your strategy and customer capabilities.

4. Because it talks about what you do, not how you do it, it remains stable even when the implementation changes.

What is fascinating is that most Business Architecture projects are run by IT departments because they need this clarity in order to build systems that will concretely manifest themselves. However, when IT owns the Business Architecture you essentially have the technology people defining the strategic direction of the company.

One final quote from Enterprise Business Architecture:

"No one will ever consider building a complex structure such as a skyscraper, automobile, ship or airplane without blueprints based on a complete set of integrated architectures. However, we consistently build, merge, reorganize, and run enterprises without a set of equivalent blueprints or architectures. "

Who owns the blueprint for the future of your business?

This blog is part of Synaptus’ efforts to participate in the world of social marketing. We are also publishing an e-zine and updating our website to begin to actively participate in the conversation taking place on the Internet about the changes in managing organizations. In addition to continuing to partcipate as speakers and contributors to professional organizations, our marketing efforts are also expanding into articles. We know we have something to add to the conversation about managing businesses successfully today and we are working hard to get out there to contribute. There are two interesting lessons from this exercise.

One of the fascinating lessons that has been reinforced to me is how hard it is to do simple things. Betrand Russell once said, "Things are relatively clear until you try to explain them to someone else." This is very true in my social marketing efforts. To set up the blog I had to figure out how to publish a blog service. I had to learn the technical aspects about publishing, promoting, and providing an RSS feed to the blog. We had to work with our web developer to get a template set up. We decided to outsource to http://www.typepad.com  and are still experiencing some technical issues with our website developer with getting the blog to show up the way I want it to. From an e-zine perspective I had to find a publisher. There are issues around privacy and publishing and unsubscribing that all have to be managed. Then you have to promote and make subscribing to your e-zine easy. We decided to use http://www.intellicontact.com as our newsletter manager/publisher. On the web and our articles, we are still working on figuring out Search Engine Optimization (SEO) and article publication. And just now we are starting to reach out develop a community around the blog and the e-zine.

The new lesson is about the breadth of the outreach from social marketing. This is definitely different than targeted marketing, where you send a specific message to a specific audience. When you blog, you are reaching out to anyone with a browser and a search engine. The following is a list of people who have participated in my blogging experience that I might not ever sell to. But they have something to add to the conversation we are having on the internet.

Healthy Web Design: "Helping independent professionals who love what they do develop and build a successful website." Dawud Miracle has a wealth of information he shares around building your website, blogging, and finding your voice.

Heart of Business: Can you hear it beating?… When you want to make a difference, but need to make a profit.

Breathing Space: Home and Office Organizing: Creating space for who you are and what you do

Conscious Cooperation: "Conscious Cooperation" is about how the decision
to cooperate can drastically improve working communication and results in the construction industry and beyond.

Engaging the Disquiet: Helping men who feel something missing in their lives.

Inquiry365: A personal blog where Mona Grayson, a professional facilitator, will question at least one that has brought her stress each day.

Mindfulness Maverick: This blog is first and foremost a reminder to not take yourself too seriously in the overwhelm of work and second to give you real practical mindful tools to reconnect on what is most important in any given moment.

Your Ideal Customer:  Elisa H. Gillispie is just starting a blog where she writes about her business.

Project managers often fall into the percent complete trap when running projects.  Percent complete gives the feeling of making progress, but provides no value to the managing the project. In There is no such thing as percent complete, Johanna Rothman says:

"Percent complete makes no sense. Features are done or not done. You can count done features and see how far along you are. You can’t reliably count any percentage done."

This doesn’t apply to just software development, this is true in an type of project. The only questions about completion that matter to coordinating and managing the project are:

1. Are you done? Done means that the consumer of what you were working on knows you are done and you don’t owe them anything else for them to use it. You should mark the task as 100%.

2. If not, are you working on it and when will you be done? This allows the consumer of whatever you are working on to get ready to work on it.  You should mark these tasks as 50%.

3. If you don’t know, what do I (the project manager) need to do to help you answer #2? Are you short of resources, do you have unclear requirements, are you waiting on someone else’s work, have you even started on it? You should mark these as 0% done. You aren’t working on it until you are have the resources, requirements, prerequisites, and intention to work on it.

If tasks are too long, then the only way to show progress is to update percent complete on tasks. Try to keep tasks to verifiable pieces of work that are relatively short, probably two to three weeks. Reflecting a percent done just to demonstrate progress doesn’t provide any insight into the status of the project, doesn’t help coordinate work through the project, and artifically demonstrates progress. As project managers or executives with projects reporting to you, are you keeping track of percent complete or what is done?

Kevin Meyer over at EvolvingExcellence has a great article Lean Won’t Work Here. He points to an article in CIO magazine by Dean Meyer (no relation to Kevin Meyer) that describes all the reasons why Lean won’t work in IT. Dean (non Kevin) says:

Apply Lean and Six Sigma to a job that involves diverse tasks, relationships and creative problem solving (like what most IT staff do) and you may find you’ve created a very efficient organization that fails to accomplish its purpose.

As Kevin (not Dean) points out, the problem is that Dean is fundamentally wrong. The to pillars of lean are to reduce the time to customer value and respect for the individual. The problems the article highlights are not problems with lean, but with the application lean.

The problem is not just that the management of many organziations don’t understand the point of lean, but that the consulting firms helping them don’t either. These resulting disasters further muddle the lean story. It’s no wonder that an industry that has this understanding has satisfaction rates below 30% with their service and fails to deliver projects to their customer up to 70% of the time. From the standpoint of Pragmatic Process Improvement, you have to focus your efforts where it will benefit the business. You can’t view process improvement distinct from value creation and human interactions. Despite what Dean Meyer represents, lean is completely aligned with both of these pillars.

Ram Charon is interviewed by Workforce about the nature of leadership in organizations.

"the work gets done from a meshing of the parts of the organization. When people work together, that is by design a social system. Leaders need to understand these relationships and how people communicate—they need to understand the social systems. If you don’t know how they work, you can’t be successful. That’s new to the 21st century."

It is no longer sufficient to define strategy and map processes. Organizational leaders need to develop effective methods of understanding the social systems that make up their businesses. If this sounds like psycho-babble or Kumbyah to you, then the challenge is in finding pragmatic ways to get a handle on the way people communicate when they work together. Lean, Six Sigma, BPR, and other process improvement efforts unleashed a wave of productivity from organizations between 1950 and 2000. The next wave is in improving the way people innovate, coordinate, learn, and commit.  Does this sound like psycho-babble mumbo jumbo to you? What are you doing to find ways to get a handle on the creating productive collaboration in the social systems that make up your organization?

This past weekend I helped chaperone a trip of 11 and 12 year old girls to the State basketball championships in Griffin, GA. We ate at a few fast-food restaurants while we were there. There was a striking difference in the quality of the service at Chick-fil-a and at Wendy’s.  Even though the prices are higher, the coaches and parents agreed that when they go to a fast food restaurant they will drive out of their way to go to Chick-fil-a.

What leads to this striking difference? I don’t think it’s the processes. I’m sure both companies have well documented processes for all aspects of their stores. I don’t think it’s the technology. While Chick-fil-a’s technology may be better, it can’t lead to this striking of a difference. I went out on the Internet to do some research.

Dan Cathy is the president of Chick-fil-a and the son of Truett Cathy, the founder. He says that Chick-fil-a’s exemplary service begins with hiring the right people. Same small town, same talent pool to draw from, they must have a much higher cost to get good people. It probably eats into their profitability to attract better talent. So is it good business to make sure you select people that will help your business set itself apart. According this article over at Fast Company, between 2001 and 2004 sales increased 40%, to $1.53 billion, and the number of locations jumped from 958 to 1,160.

Employee selection and placement requires defining the qualities of the right people for your business, then selecting for candidates based on these qualities. Don’t underestimate how critical this is or people may be driving out past your store to pay a higher price to your competitor. What steps is your business taking to make sure you are getting the best people for your business?

At a time when competitive forces have forced Pfizer to reduce its workforce by 10%, it is also facing pressure to move faster than before with less than before.  They are responding by moving to a "just in time" approach to talent. Instead of hiring for specific jobs descriptions, they are establishing an employee selection and placement system based on competencies. Travis Sinquefield over at Disorganizational Behavior points to a recent article from Workforce Management.

"In recruiting, this means Pfizer, which used to hire candidates according to job descriptions, now evaluates what competencies the candidate demonstrates

…

Similarly, Pfizer is focusing on developing employees based on competencies rather than grooming them for a specific role, he says. "

Travis points out that:

"When you hire a person based on the job description to be filled, you will probably end up with someone who has the skills to do only that job. Instead, Pfizer is taking a different approach, creating a flexible workforce where people with the skills and competencies needed can be moved into a position where those skills will be of value."

Without a clear understanding of the competencies needed in your organization, your employee selection process will select based on job skills and hope for a good fit. If you based your employee selection, employee placement, and employee development processes on competencies, you can develop a more agile workforce. This interchangeability increases the businesses ability to respond to the market without having to add as much overhead. Do you have a clear picture of the competencies needed in the jobs in your organization? How could you implement this concept in your business?

I spent the last week at a Project Management Institute (PMI) standards meeting where I serve on the OPM3 second edition standards team. There was a very interesting conversation that took place over the weekend regarding whether PMI standards should be considered best practices. The answer in general is no. A standard is considered to be a generally accepted good practice. In an emerging discipline, it is likely that there are best practices not in general use yet - so they won’t be part of the standard. This introduces two interesting questions. Are standards worth pursuing and what role does PMI play in thought leadership around Project Management?

First, standards are good practices. If you aren’t up to the level of the standard yet and project management is important to you, you should be working to achieve the standard. Just like you can’t learn advanced financial analysis until you understand adding and subtracting, if you don’t understand or aren’t can’t achieve even the standard, you probably aren’t very good at project management. I just hope that your business isn’t dependent on being able to implement projects to achieve their strategic or operating goals. Most of the project management disasters I’ve been involved in have involved people trying to skip the basics to jump to an approach that involved implementing some new practice. The Organizational Project Management Maturity Model (OPM3) helps you figure out where you stand relative to these standards and helps you develop a roadmap so you can work on improving your ability to effectively perform projects. At the end of the day, a lot of PM is still blocking and tackling, you just can’t get past it.

Secondly, PMI has people on staff and thousands of active volunteers that probably spend to much of their time thinking about project management. There is a full time research staff looking into project management and exploring best practices. I believe I heard that there were 50 research papers published by PMI last year (2006). So, while the standard doesn’t reflect emerging best practices there are conferences and local chapters that explore and promote advanced thoughts about project management. As I just experienced this weekend, if you want to sit around and discuss the merits of emergins best practices in project management there isn’t a much better community than PMI.

At the workshop I am attending this weekend the concepts of lessons learned has come up several times. Several times someone in the group has said, "we have the lesson’s learned from the last time we did this, haven’t you reviewed this?" In each case the manager in charge of the project replied, "I didn’t know they were out there." Despite the diligent efforts to capture lessons learned, the organization isn’t benefiting from prior experiences as much as they could.

So when is a lesson learned considered learned? Stopping at the end of a project effort and identifying the things you wish you knew at the start of the project is a very powerful technique. Writing these lessons down for those coming after us is an important way to archive this information. But without a way to make sure that the people who will be responsible for the next project understand the relevant lessons learned, this is not productive time. There are three suggestions for handling this.

1. The people who are taking on projects must take the time to look for and review lessons learned from prior similar projects. This means that lessons learned must be stored where they can be found and tagged so that the relevant lessons can be identified.

2. There could be someone in your organization who is familiar with the lessons learned that are out there and provide some context to new managers.

3. Whenever possible, there should be a meeting with the new manager, a person with prior experience, and a someone who is familiar with the library of lessons learned where a conversation takes place. Even if 1 and 2 are taken care of, people learn much more from hearing stories than from reading a formal document.

Remember, documenting interesting lessons is valuable, but nothing is learned until it is available for someone to use it when it matters.