Synaptus

Gemba Panta Rei has an article that is relevant to, People or Process, a recent post on this blog. I think this highlights the benefit of looking at process or environment first when you have a people issue.

"in Japan the first response to a high rate of absenteeism is to conduct root cause analysis into the behavior of absenteeism, leading to kaizen. In Europe the management would replace the worker who had an attendance problem with another workers. Problem not solved, but deferred."

If its a flawed process, or if you have a flawed understanding of competencies necessary to perform the job, switching people out does not solve the problem. Combining a quality process with a clear understanding of the innate competencies and values required to be successful in the job is a powerful combination. Much more powerful than either applied independently.

I’ve been engaged in a conversation with Gary Farush over at ComplexWork regarding whether performance issues can be addressed by people or process. We agreed that sometimes its people and sometimes its process. Gary contends that people tend to get blamed first, and that by not addressing the process issues they tend to recreate the same problems.

This is probably true. People don’t do bad work because they want too. They tend to act in they way that makes the most sense to them. So, when expected results aren’t being delivered, you should look at these five process/organizational environment issues before you start blaming the people.

1. Inertia or Momentum: "That’s the way we’ve always done it"

2. Conflicting Priorities: Compensation or rewards are in conflict with specific objectives. Or a person is being pulled in multiple directions by various levels of management.

3. Bad Inputs from Upstream in the Process: The person is having to deal with poor requirements or bad inputs from upstream.

4. Lack of Tools, Knowledge, or Understanding: A person can’t perform their job satisfactorily if they aren’t made capable through enabling technologies, training, or expectations.

5. Management Inattention: The work itself is not being managed. This can actually manifest itself as any of the prior four points.

All of these causes can be identified, managed, and the impact on your business reduced. There is also a very issue though that certain jobs require specific skills and innate competencies. Skills can be trained. Innate competencies are part of how people are wired.  When you have addressed the five problems above and performance doesn’t improve, match the competencies of the people to those best suited for that job. Also, it is probably smart to ensure when hiring that you getting people with the best set of innate competencies for the job.

BPMG.org points to an article on SearchCIO.com that talks about the rise of relationship management skills over technical skills in IT organizations. This is driven by the automation and outsourcing of IT capabilities. The IT employee of the near future will be more likely to be handing customer service requests and managing vendor relationships than plugging in hardware, installing or configuring software, or writing code.

“Morello said IT organizations will become increasingly automated and outsourced. As a result, IT employees will be asked to fill multiple roles, rather than just focus on a single job. And one of their most important roles will be managing "points of interface" with other parts of the business. “

“IT employees will need to speak the same language as business stakeholders. This means less demand for specialists (IT employees with a deep understanding of specific technology) and generalists (IT employees who have a broad set of relatively shallow technology skills). IT will still need technical skills, but the most valuable technical employees will know how they can apply those skills to different situations in different parts of the business.“

So project management, collaboration, and customer service will be the key capabilities of IT. And new capabilities to create a common business framework to focus and align a distributed organization will be necessary. How many of your key employees are being hired or developed with these skills in mind? What framework are you putting in place today to create a common understanding of what the business actually does?

I have had an interesting experience the last few days. I have been going through all my old business cards to try to reconnect to people whom I have met with over the last decade. My goal is to expand my network of people I have met with in the past and introduce them to the blog. The interesting thing is how many of the people no longer work at the business they worked at in the past. My sample is about 300 business cards that I held onto and is not a very controlled study. These are only people that I spoke with and sent an email to after meeting them.

A brief survey says that only business owners are still at the companies they were at 10 years ago.  Over 70% of people are not with companies they were with five years ago. About 50% are not with the companies they were with over 2 years ago. I don’t know how this matches up to national averages.  But I bet it is representative of the huge amount of employee turnover faced by most companies. In many businesses the knowledge lives within the people. Sales people and customer service people have relationships with customers. Working consultants have practical knowledge about how products "actually" work at the customer. Internal management and employees have the knowledge of how things got the way they are. All of this is critical to the success of the business and the costs of turnover are much higher than just the cost of hiring and training a new person.

What are the steps to managing this cost? Maybe we should reduce the ability of people to hold value away from the business. But this reduces their sense of contribution, reducing performance and driving up turnover. Maybe we should capture knowledge in large databases. But even knowledge management practitioners realize that capturing the knowledge is very difficult and that getting people to go out and find the knowledge to reuse is impractical. Another way is to encourage people to talk about their knowledge with their co-workers. Build out the knowledge in the business. Increase the sense of contribution of knowledge workers and increase productivity by sharing learned experiences throughout the business. What are some ways to manage the relationship between employee retention and knowledge? What have you seen that works to address this problem?

David Anderson over at Agile Management has a series of posts about HR Myths. David blogs on software development, management, constraints, and agility. I come from a technology development and implementation background so I may be biased. But, I believe that the software industry is one where the impact of knowledge-based work, the transitional worker, outsourcing, speed, and unique customer requirements have all coincided over the last 10 years. Since many other jobs will begin to fall into this space over the next decade, I think it is critical to learn from what has worked in the software industry. Here are some HR policies that David has identified that make working in software development more difficult.

In HR Myths #1: Merit Based Pay, David discusses why it doesn’t make sense not to hire top quartile performers, something pay bands make difficult.

"We don’t care about productivity look at our cost control"

Top performers may be 10-20 time more productive than mediocre performers. Yet "companies which claim to be meritocracies, in fact, are not. They pay people in a very narrow band. In my example, you can be sure that everyone on that Level 56 grade is being paid between $27,000 and $28,500 despite the fact that some of them will be 10 times more productive than others."

Focus on "productivity first, investment second and cost last. Cost first generates mediocrity and mediocrity results in very poor performance from a software engineering organization"

In HR Myths #2: Divide and Conquer, David discusses how HR departments practice of negotiating pay down at hiring time, restricting the ability to reward performance after hire, and then hiding how much everyone makes to avoid conflict, may be counter productive.

"In almost all companies it is directly against company rules to discuss what you – the knowledge worker – are paid with your colleagues. Why? Simply put, it is a divide and conquer strategy by Human Resources. They believe that by enforcing silence with a threat of summary dismissal, they will save the company money and reduce complaints from disgruntled employees. In a few companies, it is also illegal to discuss your pay scale grade with other employees. This is the ultimate in Big Brother style control because it theoretically prevents employees from learning that someone doing the same work is on a higher grade than them. HR believes that this enforced silence reduces complaints, saves the business money and makes employees happier."

HR Myths #3: Performance Buckets

"The first fallacy is the concept of an equal distribution of performance across a team – someone has to get a 1 and someone has to get a 5. The idea is based on the statistical bell curve normal distribution. However, when your statistical sample is (for example) less than 20 then any statistician will tell you – you do not have a basis for a normal distribution.

The second fallacy is that all teams perform equally and that someone from every team deserves a 1 and that equally someone from every team deserves 5."

In HR Myths #4: Tribal Markings, David discusses how companies make temporary workers feel inferior and how it can impact group performance.

"Why do HR departments insist on issuing different colored badges to contingent contract labor and vendors on long term contracts? It’s clearly tribal. It clearly marks the individual as somehow less worthy. Why? The assumption is that temporary staff are less trustworthy. Hmmm. This feels that it belongs in medieval Japan’s early Edo period where Samurai without a master – ronin – were treated with suspicion."

In HR Myths #5: Pay for Performance, where David discusses the issues associated with pay for performance that can lead to reduced organizational performance.

"Pay for Performance can lead to dysfunctional behavior encouraging individuals to look out for themselves and discouraging team working that enables higher productivity from the whole team."

Read all the entries if you have the time. The issues facing technology development are people issues, not technical issues. Equitable compensation, temporary workers, and uniquely skilled workers are issues increasingly faced outside of the technology sector. It sure makes sense to learn from the really smart people in an industry that has begun to figure this out. It isn’t true that life is different in technology so those lessons don’t apply to us. We can apply the lessons throughout most organizations. Which of these myths are impacting the performance of your organization?

I think the conversation theory post may have been a little dry. It all sounds so theoretical. It’s so far out there you may be wondering how can it be applied in business. So here’s a a couple specific examples.

We had a client that had five IT departments, one to support each line of business. Each group believed that their business was so unique that they had to have their own support groups. The CIO of the company thought that there was probably a lot in common between them, he was just struggling to get everyone on the same page. Everytime they tried it would break down in a defensive battle. With some of the executives from the operations group, we helped facilitate the development of a common semantic model of the businesses. We started with some clearly common concepts and worked our way through the business. At the end of the effort, management reached an agreement that about 80% of the business models were the same. Working towards developing a common background of understanding, instead of defending a previously established set of concepts, led to a breakthrough for the business. We talked about what we talked about, and common understanding became explicit, rather than each person defending how their view of the world was correct. Combining common technology and functions saved the company millions of dollars a year. The added organizational agility and synergy probably contributed to the massive growth the company experienced over the next two years.

A software development group was struggling to get what product management was promising to the customer in a timely fashion. There was a lot of conflict and frustration. Customer commitments were consistently missed. Working with key people in development and product management, we worked our way through how work was coordinated, how commitments were made, and how understanding was established between the customer, product management, and development. We identified the key points that were leading to waste, quality problems, and rework. Then we talked about the conversations that were leading to those breakdowns. The rate of work through the organization doubled in just over four weeks. We didn’t change any people or technology, we didn’t cut any scope. We spent time talking about what they talked about to make the conversations more productive.

These are not isolated circumstances. This is how people interact. When people from different backgrounds or with different roles get together, they participate in a way to justify their groups norms. When these norms get in the way of successfully moving work through the organization, these problems tend to go unexplored. Because talking about what we talk about is considered threatening, too touchy-feely or too theoretical. I believe there are huge returns for addressing this situation. Look around your organization, do you think the returns are there if there was a way to address it? What would it take for you to start talking about the conversations in your organization?

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?