Drucker on Functioning Communications, Part 2

In his book, The Essential Drucker: The Best of Sixty Years of Peter Drucker’s Essential Writings on Management, Peter Drucker analyzed the ways that management practices and principles affect the performance of organizations, individuals, and society. The book covers the basic principles of management and gives professionals the tools to perform the tasks that the environment of tomorrow will require of them.

These are my takeaways from reading the book.

Drucker believed that there are four fundamentals of communications.

1. Communication is perception.

2. Communication is expectation.

3. Communication makes demands.

4. Communication and information are different and indeed largely opposite—yet interdependent.

Sometimes we use the words communication and information interchangeably. Drucker believed that they have different but interrelated purposes

Drucker asserted that communication is an act of perceiving, while information is a form of logic. Information should be formal and impersonal. That means information should be free of human emotions, expectations, and perceptions. When that is the case, information becomes more valid and reliable, thus increasingly informative.

At the same time, information is not very useful without communication. Because of information’s formal and encoded nature, we must first communicate the code so the recipients can know and understand how to use the information. This prior agreement or protocol for understanding the information requires some communication.

Also, Drucker asserted that more and better information does not necessarily solve the communications problem. Information alone also does not bridge communications gaps. On the contrary, we need more functional and effective communication if we wish to relay or share more information. When we produce more information without paying attention to how we communicate, we create even more communications gaps.

Consider how critical communication is in the age of abundant information; can we do anything to be more effective in communicating? For organizations and team, Drucker believed that management by objectives (MbO) is a prerequisite for functional communication.

By properly practicing the principles of MbO, both the subordinate and the manager benefit. They benefit by recognizing their common ground and having a focused collaboration on something that is real to both parties. When both parties realize that they see the same reality differently, that recognition is a form of communication.

In the end, communication is about shared experience. When both the sender and receiver perceive the same reality, have consistent expectation from the exchange, and agree on the common action or result from the exchange, effective communication becomes possible.

Drucker on Functioning Communications, Part 1

In his book, The Essential Drucker: The Best of Sixty Years of Peter Drucker’s Essential Writings on Management, Peter Drucker analyzed the ways that management practices and principles affect the performance of organizations, individuals, and society. The book covers the basic principles of management and gives professionals the tools to perform the tasks that the environment of tomorrow will require of them.

These are my takeaways from reading the book.

Drucker believed that there are four fundamentals of communications. Three of them are:

  1. Communication is perception.
  2. Communication is expectation.
  3. Communication makes demands.

True communication can only begin when the receiver perceives something from the sender and responds back. This receiver-first concept means that it is the recipient who initiates communication, not sender. Until the receiver responds with something back to the sender, there is no communication, only noise.

Communication can happen only when the sender attempts to communicate in the recipient’s language. Therefore, Drucker suggested that the first question in communicating must be, Is this communication within the recipient’s range of perception? Can he receive it?

Effective communication also must account for expectation. As a rule, we see largely what we expect to see and hear largely what we expect to hear. We also tend to tune out sights and sounds that we did not expect to take in and process. For us, those extraneous sights and sounds are merely noise.

That is because the human mind attempts to fit impressions and stimuli into a frame of expectations. We resist vigorously any attempts to make us “change our minds” or perceive anything that is contrary to our expectations or breaks our psychological continuity.

It is imperative that we must know what the recipient expects to see and hear before we attempt to communicate. Only then can we know whether communication can utilize the other person’s expectations to receive the message or be more receptive to the message that might consider being contrary or disruptive to the expectations.

Communication always makes some demands. It always demands that the recipient become somebody, do something, or believe something. If communication fits in with the aspirations, the values, the purposes of the recipient, it is powerful because it appeals to motivation. If communication goes against the aspirations, the values, or the motivations, it is likely not to be received or to be resisted by the recipient.


(從我的一個喜歡與尊敬的作家,賽斯 高汀)







What I learned about Managing IT Projects from Playing Online Games


Time flies when you’re having fun. It seems like just yesterday I grew up playing video games on Atari and Nintendo, and now we have many more gaming choices available to us. To this day, I still enjoy playing video games on computers. Gaming for me is not merely entertainment – I enjoy learning and understanding the design and mechanics behind a particular game. I also enjoy the socializing and friendship-building aspects of the online games.

Many computer games clearly were built to provide entertain value, but there is a surprising amount of wisdom to pick up from some of today’s more sophisticated online games. One aspect of playing those online games involving social activities of organizing a group of players to accomplish a common objective, usually involve slaying a dragon or a boss monster. It is fascinating to me that one often can find some intriguing parallels between organizing a raid and organizing a project team within an organization. Whether it is organizing a 25-player, 6-hour long raid or organizing a 25-member, 6-month long project, some leadership and management principles seem to apply for both cases.

Here are some lessons I believe many younger IT colleagues might be able to learn from spending some time in the virtual world.

What are we trying to accomplish and why?

In the game world, we ask which dragon do we want to slay tonight? Announce the final objective up-front and let people know what is in it for them. Players come to a particular raid for many of their own reasons. Some will come for a specific loot or reward. Some players come to the raid to experience a particular portion of the game content. Some players will come to a raid to learn more leading a particular raid. Some will come just for fun and sight-seeing.

In the real world, people band together to form a project team for a variety of reasons. Those reasons could be driven by organizational, political, or other factors. The why factor always should be aligned to a business goal. Helping others to understand the end state up-front can help to build commitment and to foster positive motivation.

How are we going to accomplish the objective?

In the game world, we need to understand the details of the encounter as much as possible before you can have a successful raid. “Know the fight” is a common phrase used in online gaming. Today’s online game raids can be quite sophisticated and involve many stages or phases. Everyone participating in the raid should have a basic understanding of the raid and what to expect during each phase. However, knowing the fight at a high-level is just half of the battle. Each segment of the raid will have certain activity requirements that need to be met, often under some time constraints. If the requirements are not met in a timely fashion, it is quite possible the raid will fail. To plan ahead, the raid team needs to translate the requirements into workable tasks and assign a time line.

In the real world, it works pretty much the same for a project. The project team should have a common understanding of how the project should be executed at a high, summary level. The project team then breaks down the work into tasks and assigns deadlines or timing dependencies to those tasks.

Whom do we need for this effort?

In the game world, a raid will require a collection of players to fulfill a variety of roles. In online games, the roles can also be referred as jobs or classes. To complete a raid successfully, it will require a proper combination of roles all working together and executing the tasks along the way. In addition to having the proper roles, the raid team will also need skillful players in order to succeed. The skillful players know their jobs/classes well and understand how their roles fit into the raid encounter. The more skillful players can also provide valuable input into the raid and support everyone else to get the job done. Very often, the most time-consuming aspect of organizing the raid is to find and recruit the classes/players you need for the raid.

In the real world, we also need people with the proper skillsets and competency level to execute a project. Staffing a project team with a perfect combination of the skillsets and personalities can be a difficult task. Sometimes, the staff choices are given or established by the organization beforehand or is not entirely negotiable for some reasons. When those things happen, the project team will work with what it has. Sometimes the project team might need to recruit additional people or to replace individuals in order to cover the skill or competency gaps created by the project team make-up.

Which tools will we need to manage the effort?

In the game world, the game client application serves as the foundational tool for all raid team members. Having access to the same information by everyone is critical to the successful execution of any raid. Many raid teams rely on websites or in-game chats to communicate pertinent information about the raid. Very often, critical information also must be delivered quickly. Many raids today are also supplemented by another communication tool, such as voice conferencing. The game world can be unforgiving, and unwanted things can happen extremely quickly. A few poorly-timed missteps by the raid members can easily add up to a deficiency that is too severe for a raid team to overcome, leading to a wipe.

In the real word, consistent execution of a project requires all project team members to have access to the same project information via a set of common tools. Information can be communicated in written form or in verbal form. Project plans, meetings, memos and minutes are just a few tools we often use. The real world can be just as unforgiving as the virtual one. Poor communication can add up to either severely delay a project or sink one.

When Games Mimic Life

Even with the proactive planning in place, many things can still go wrong. Risk management most also be practiced when operating in both worlds. In the game world, risk management takes the form of having a robust combination of roles and solid communication channels. In the real world, we often have a lot more risk management options available to us if we put in the proper level of planning. There is no reason why we cannot do what we can to be properly prepared and well organized for any project.

Whether in the game world or in the real world, producing positive results with a group of people takes leadership, management, collaboration, and communication.

Footnote: Wall Street Journal reported that a new study reveals that adults who played a video game helped their mental agility more than adults who did crossword puzzles. Just saying.

Image Credit: Courtesy and Property of Blizzard Entertainment, Inc.

Problem Management Process Design – Part 3

This post is the third and the final installment of the series for designing a problem management (PM) process for your organization. Previously we discussed the elements and considerations that should go into designing a problem management process. We elaborated those considerations further with a sample list of process requirements, a sample process flow, and a sample RCA form. We will assemble all the information together into one process design document that can be used to implement the process.

Problem Management Process Design Example

In addition to the process requirements and the process flow, I believe a process design document should call out the following information pertinent to the implementation of the process. For example…

  • The Policy section outlines what policy statements (IT or corporate) governs the process and what expectations the organization wants to set for the process.
  • The Scope section specifies which incidents or events will generate a problem record. Your organization may have a pre-defined set of criteria on how problems are triggered, and those criteria can go into this section. Some organizations may also choose to group a series of closely related incidents and trigger a problem record for those incidents.
  • The Roles and Responsibilities section outlines the roles that will be involved in the process and their corresponding activities and responsibilities.
  • The Artifacts and Communication section describes what documentation methods will be utilized by the PM process. It provides the procedural information necessary to carry out the PM process. The communication protocols section describes the recommended communication methods and their frequencies.
  • The SLA and Metrics section describes the metrics that will be used to measure the process performance. The tutorial document has outlined some examples. Develop and measure the metrics that you can capture reliably and that your organization also cares about.

To reiterate, the primary goal of the Problem Management process is to identify the problems in the IT environment, so we can eliminate them by performing root cause analysis on the problems. As a capable IT organization, we should be able to correctly diagnose the root causes of just about everything that goes wrong within our IT environment and to implement solutions so similar problems or incidents will not reoccur. With proper documentation, the Problem Management database is a great learning tool. Also, another benefit of having a well-run problem management process is having the ability to review organizational decisions made about addressing a particular problem. Known errors do not need to be purely technical. They could also be the documented decisions about how we plan to address certain problems. The root causes, solutions (proposed or implemented) and the workarounds documented as part of the Problem Management process will benefit the Incident Management process immensely when similar incidents surface due to the recurrence of a problem.

I hope the information presented so far has been helpful. Please feel free to suggest options or other approaches that have worked for your organization.

ITSM Tools Operation Continuity Plan – Part Two

We discussed the first several topics (scope, data considerations, and external dependencies) that should go into an ITSM tools operation continuity plan during a disaster recovery (DR) scenario. In this post, we will conclude the discussion by covering the people, procedures, checklist, and validation sections of the plan.

Recovery Team and Communication

The section spells out the key roles and the staff members who will be responsible for implementing the plan. It will include the typical information such as name, organization affiliation, location, and contact details. This section should also include agreed upon communication protocols for the duration of the recovery process. For example, teleconference bridge information could be something useful to include, if that is your organization’s standard practice. Also, if your organization has a major incident handling practice with standard communication and reporting requirements, you can cover the pertinent details within this section or at least make a reference to it.

Recovery Procedure and Configuration Details

This section outlines the recovery instructions and procedures with as many details as necessary for a successful recovery. This section also provides all configuration details that need to be in place in order for the recovery solution to work as designed. Just how much information do you really need to include in the document? I believe the level of detail will largely depend on whom your organization anticipate will execute the plan or heavily influenced by your organization’s disaster recovery plan.

By default, I would recommend having the level of detail based on the assumption that the people who will execute the plan are NOT the same folks who operate the production environment pre-disaster. This is the safer router in my opinion.

For example, your organization uses ITSM product XYZ, made by company ABC and operated by an off-shore team from vendor OPQ. When a disaster strikes your data center, the network connectivity between your data center and your production personnel from OPQ was cut off. At this time, your OPQ vendor has another team at a different location who can access the recovery site and knows your ITSM product. With a properly documented recovery plan with the right level of details, you can leverage your vendor’s second team quickly to start working on the recovery without any help from the production team.

Checklist of Key Actions or Milestones

To help everyone who needs to understand and execute the plan, I recommend having a section that outlines the key tasks and activities so no important activities will be missed. The checklist can also be used to show the various communication and escalation points.

Testing and Validation Steps

This section outlines the detailed testing strategy and validation activities required to implement the recovery plan. Similar to the recovery procedures section, it is highly recommended that these instructions are comprehensive, so the recovery solution can be fully tested by people who may not be the same team as your production crew. The section should also account for all potential conditions, events, and scenarios. The section should contain information that can be used during the testing such as:

  • What are the success criteria for the test objectives?
  • What are the assumptions defined for this test, if any?
  • When is the testing window?
  • How should the security setup be taken into consideration?
  • Which tool modules will be tested?
  • Who will be conducting the test?
  • What are the steps to validate the application and data integrity?

Return-To-Normal-Operation Procedure

This section describes the instructions/procedures necessary to return to the normal production environment once it has been restored. For this section, I would say probably the most key information to explain is how the data will be synchronized between the production and the DR systems. Again, the key objective is not to lose any data captured by the ITSM tools while it was operating in the DR setup. This section will also include the necessary testing and validation steps to ensure that the production system is back in full operation, so the DR system can be fully shut down and return to the stand-by mode.

An ITSM Tools Operation Continuity Plan Example

I hope this particular discussion on the ITSM tools continuity plan provides something of useful tidbits for your organization to think about and to plan for. Considering the importance of the data and transactions captured by the ITSM tools for many organizations, having a workable continuity plan is really not optional anymore. If you don’t have anything in place now, I recommend start small by drafting a plan and making the scope compact enough to cover just a few high probability and high impact scenarios. Work with someone within your IT organization who is responsible for the overall IT continuity plan, so your plan can integrate well with the overall IT and business objectives.

SACM and CMDB Tools – More Planning Considerations – Part 3

In part 2 of the series, we discussed some key considerations for a CMDB solution and expanded on those areas such as the Scope, the Roles and Responsibilities, and the Data Model. In this post, we will discuss additional areas such as Control and Verification, Key Performance Indicators, and Awareness Campaign, Communication & Training.

  • Control and Verification: Who can add, change, or delete information from the CMDB and under what circumstances? Will you use some type of a gate-keeper process, like Change Management, to regulate how information coming into and being updated in CMDB? Remember trust and authenticity of the CMDB data are what make the CMDB useful. How do the relationships between CIs get determined and mapped? Not all relationships can be mapped automatically by the tools, so some manual changes to the CIs and relationships are still necessary. All updates, automated or manual, to the CIs should be tracked by the CMDB tools with a complete history and audit trails. How often do you audit the accuracy of the CMDB and reconcile the differences? Can your CMDB tools help by automating the verification and reconciliation tasks as much as possible? When you have hundreds and thousands of CIs in the CMDB, manual audit and reconciliation get labor-intensive really quickly and degrade CMDB’s usefulness rapidly over time. This area will need some well-thought-out and clear work instructions, so people will know exactly how the CMDB will be maintained.
  • Key Performance Indicators: What metrics will you track in order to measure the effectiveness of your CMDB solution? I will outline some potential metrics, and you need to decide what ultimately is important to your organization. When I was planning for a CMDB solution not too long ago, I used Randy Steinberg’s “Measuring ITIL” book for gathering metric ideas and inspiration. I would recommend checking out Randy’s book, not just for configuration management but for other ITSM processes as well. The lists below outline some metrics suggested in Randy’s book and some of my own.
    • Some example operational metrics:
      • A: Total Number of CIs
      • B: Number of CIs Audited
      • C: Number of CI Errors Discovered
      • D: Number of CI Changes
      • E: Number of CI Changes Without Corresponding RFC
      • F: Number of  Incidents Related to Inaccurate CI Information
      • G: Number of  Change Failures Related to Inaccurate CI Information
      • H: Number of CIs Without Assigned Ownership
    • Some potential indicators:
      • CMDB Audit Ratio: B / A (Target 100%)
      • CMDB Accuracy Ratio: 1 – (C / A) (Target 100%)
      • CMDB Compliance Ratio: 1 – (E / D) (Target 100%)
      • CMDB Support to Incident Index: F (Target 0)
      • CMDB Support to Change Index: G (Target 0)
      • CMDB Ownership Rate: 1 – (H / A) (Target 100%)
  • Awareness Campaign, Communication & Training: What mechanisms will you use to get the words out about the CMDB solution? I can guarantee you that, as soon as people find out a CMDB is in the work with information that can impact or benefit their lives, they will want to have their say. This is where the governance decisions come in. Everyone is welcome to provide input, and they should especially during the data model design phase. How will the input get taken into account and how will the decisions be made? During the implementation, how will the progress be communicated? Expectations need to be reasonable and in-check because my experience tells me that people often have an inflated idea about CMDB and what it can do. Sometimes we don’t do ourselves a favor by hyping up the CMDB solution too much at the beginning. After the CMDB is ready, who will operate the tool and need to get trained? A CMDB solution is a good thing to get excited about, and people intuitively understand the benefits of CMDB when it is done well. However, we often get into the trouble of promising too much and delivering too little when it comes to CMDB. Awareness and communication are two things that will need to be sustained during design, during implementation, and well into the maintenance / care-and-feeding phases.

There are a lot to think about when planning for a CMDB solution and, for many organizations, those consideration areas I have mentioned barely scratch the surface of the real issues they face. Like many ITSM initiatives, SACM and CMDB solutions are very much people endeavors, with the process and tools, while still important, playing more of a secondary role. In the next post, I will walk through an example CMDB solution implementation scenario. It is by no mean and end-all-be-all approach, but it can be a starting point for some organizations that can use a starting position.

Links to other posts in the series

Major Incident Handling Process Design – Part Two

This post is the part two (and concluding part) of a series where we discuss the Major Incident Handling process and how to put one together. Previously we discussed the elements and considerations that should go into the process design. In this post, I have elaborated some of those considerations further with a sample process flow and a corresponding process design.

Sample Major Incident Handling Process Flow

Sample Major Incident Handling Process Design

A major incident generally imposes higher impact and requires special attention to resolve it. To summarize, I think an effective Major Incident Handling process design should clearly define at least the following who-does-what-by-when-and-how elements:

  • What constitutes a major incident in your organization? What criteria do you use to quickly and effectively determine and declare a major incident?
  • Who is accountable for coordinating and controlling the activities during a major incident exercise? The Major Incident Manager role can be fulfilled by a person or by a team, and she needs the proper authority to direct the activities and the people who are involved.
  • How the resolution efforts will be coordinated and conducted? The exact details may vary from one organization to another, or even from one incident to another. The general approach should be worked out beforehand, and the Major Incident Manager should be trained to utilize the approach as consistently as possible.
  • What escalation or communication approach will be used during and after the Major Incident?
  • What metrics will be used to measure the effectiveness of the process? Keep them simple, easily understood and reasonably painless to collect the data.
  • What format of communication and reporting will be used for the major incident? Who will get what type of information? Try to keep the contents appropriate for the intended audience.

I hope the information presented so far has been helpful. Please feel free to suggest options or other approaches that have worked for your organization.

Links to other posts in the series