How To Avoid The Reorganisation Mess In Five Steps

There’s no denying that reorganisations, or reorgs as they are colloquially known, are messy affairs. But they might be necessary to meet either short or long-term challenges. Perhaps the environment around the business has been disrupted by new technology, and existing products and services are no longer profitable.

Said Paul Mackler1, CEO of Cygus Business Media:

Reorgs can have a direct impact on revenue generation if done for the right reason and if they are executed well.

Or, the cost of raw materials has gone up and the business needs to establish cost-cutting measures. One organisation I worked for was facing a labour crunch because too many of its employees were hitting their retirement age at the same time. The excuses for reorg are often underpinned by the fact that something urgent needs to be done…now.

But there are compelling reasons not to leap into the reorg bandwagon without first understanding the process. Stephen Heidari-Robinson recommends 5 key steps2 in the reorg process:

  1. Consider Costs and Benefits
  2. Understand Current Capabilities
  3. Consider Multiple Options
  4. Stay Enganged
  5. Implement and Evaluate

1. Consider Costs and Benefits

Reorgs do not happen in a vacuum, and should be recognised as a business function. Hence, clear objectives need to be set from the beginning. Although it’s common sense, too many reorgs happen because of a leader’s whimsical decision to reverse everything that the predecessor had done, or implement change just to make his or her CV look good at the end of their terms.

Increasing revenue by a certain margin is often a clear objective to set. However, for companies that deliver services, a clear objective might be efficiency, where cost savings are realised by doing more with less resources. This does not mean overworking existing employees to death, but securing efficiency gains from either process improvements or automation.

All actions taken in the name of reorgs incur costs, and need to be considered too. These costs may sometimes be intangible and hard to detect, such as the human cost of change and disruption, but they are integral. Frank E. P. Dievernich3 wrote:

Change management without people is unthinkable. Human beings stand at its core as both the subjects and the objects of change.

2. Understand Current Capabilities

Organisations hire people with a diverse range of capabilities. Often, capabilities are nurtured either through experience accumulated on-the-job or new skills obtained through formal training. Considerable investment has been put into growing and developing employees into their roles. Sudden change, like a reorg, can cause permanent damage if they undermine current capabilities.

Hence, a period of reflection and self-diagnosis is needed, where the organisation has the opportunity to take stock of not only its current strengths, but also its weaknesses.

Self-diagnosis can be tricky, but the most important aspect of it is a focus on people, and their attitudes towards the organisation’s goals. A simple instrument to draw this out is a variation of the Activity Card Sort, which is a unique assessment tool for measuring adult human occupation and level of activity4.

To adapt the tool to our needs, we may list an organisation’s existing values into these eponymous cards- such as customer-centricity, compliance, and responsiveness– and invite employees to sort them into categories of importance, ranging from high to none. The sorting procedure allows employees to describe how he or she is involved in, or even understand, the various organisational values.

Very quickly, self-diagnosis can help organisations identify key gaps like whether employees are suited for their roles, or more crucially, how well have core values been communicated up and down the organisation.

3. Consider Multiple Options

In a volatile world, organisational design has become a daily task for executives. Organisational design5 is defined as:

…the complete specification of strategy, structure, processes, people, coordination and control, and incentive components of the firm.

The whole purpose for designing organisations is to increase both its efficiency and effectiveness. Often, it is not necessary to revamp an entire organisational model, but to focus on elements that are not working. Organisational design is not about how the organisation will look like in terms of hierarchy and reporting lines, but how all the different elements of strategy, incentive, systems, staff policy, processes and structure are going to work cohesively with one another.

It’s a great feeling to get a brand-spanking new reorganization chart done and then present it in all its unsoiled glory to the entire company. Unfortunately, that gleaming chart with all its little color-coded boxes lined up with precision has little to do with making a reorganization successful6.

Globalisation and the general loosening of regulations drive a constant reassessment of the organisation as a living, dynamic entity. Today, executives can pick from a wide range of organisational models like virtual, learning, modular, cellular, network, alliance, or spaghetti.

Some models challenge traditional ways of thinking about organisational design, but that does not obviate the need to make an explicit choice in a model. All organisations need formal designs to be efficient and effective.

4. Stay Engaged

In most organisations, executives only involve themselves in setting the strategy and direction of the reorg exercise, and leave the operational and implementation details to their teams. This is the wrong approach. Leaders need to stay engaged to carry out and manage the change. Stephen Heidari-Robinson argues, for example, that new job descriptions still need to be written, key resources like manpower and money re-channeled to other focus areas, and buy-in secured from every level of staff.

A lot of organisations fail in reorgs because they don’t pay attention to this step. In a worst-case scenario, this leads to a mis-alignment between strategic goals and the goals of every employee working for the organisation. That is why CEOs are increasingly seen as Chief Engagement Officers, rather than just being the Chief Executive. At the CEO’s level, for example, rapid commitments need be made on these fronts7:

  • Increased operating margins
  • Quicker execution of company strategy
  • A more rapid adaptation to change and the need for change
  • Increased employee motivation and consequently a decrease in employee turnover
  • The exposure of duplicate or redundant business initiatives
  • The integration of business initiatives across departments
  • Immediate correction of problems related to quality, timeliness, and inefficiencies

Moreover, because digital communication and globalisation has accelerated the pace and complexity of organisational change, Human Resources (HR) play an increasingly important role in promoting new values and installing a more flexible culture8.

5. Implement and Evaluate

Experienced project managers know that all improvement initiatives are experimental in nature, and will remain an iterative process for a very long time. It doesn’t matter how much thought and preparation went into implementing a reorg exercise; it will not be perfect.

This iterative approach of implementing a solution, assessing its outcome, and closing a gap that’s been identified strongly implies a culture of organisational learning. Though most learning organisations have mastered single-loop learning, where the organisation learns from within the existing mindset9; it is the organisation’s potential for double-loop learning that may determine how quickly an organisation reaps the success of its reorg.

In double-loop learning, organisations devote a lot of time in first ensuring that its employees are given critical thinking skills, then providing platforms from which they can share their opinions. In a reorg exercise, this approach encourages discussion and debate, and channels people’s attention towards the shared destination of improving on the initial reorg plans.

Reorgs are essential for survival, especially in a knowledge-based economy, where fast-paced ideas have replaced traditional products as commodities. Because reorg impacts people more than anything else, it can often be a difficult, emotional and lengthy process that requires skillful planning and compromise. A positive approach is all about communicating, engaging and ultimately activating employees within the reorg process, rather than throwing out resources after the reorg has happened.

Show 9 footnotes

  1. Do Reorgs Really Work? Five Chief Executives Weigh In. (2005). Folio: The Magazine for Magazine Management, 34(2), 7.
  2. Heidari-Robinson, S., & Heywood, S. (2016, 11). Getting reorgs right. Harvard Business Review, , 1. Retrieved from
  3. At the Heart: Human Beings in Organizations. (2014). Change Management and the Human Factor
  4. Sachs, D. (2003). The Activity Card Sort: A Factor Analysis. OTJR: Occupation, Participation and Health, 23(4), 165. doi:10.1177
  5. Burton, R., Obel, B., & DeSanctis, G. (2011). Define the scope of the organization and assess its goals. In Organizational Design: A Step-by-Step Approach (pp. 3-20). Cambridge: Cambridge University Press. doi:10.1017/CBO9780511894961.005
  6. 45 things: Why reorganizations fail — and how to get them right (2016). Chatham: Newstex.
  7. Liebowitz, B. (2010). Succeeding at the top: A self paced workbook for newly appointed CEOs and executives. New York: Business Expert Press.
  8. Barratt-Pugh, L., & Bahn, S. (2015). HR strategy during culture change: Building change agency. Journal of Management and Organization, 21(6), 741-754. doi:
  9. Örtenblad, A. (Eds.). (20132013). Handbook of Research on the Learning Organization: Adaptation and Context. . Cheltenham, UK: Edward Elgar Publishing

Digital Humanities and the Real World- The Pipes, the Pipes are Calling

If you asked a scholar what digital humanities is, they’d likely reply with a cautious, it depends. Dredge up any article on digital humanities from the Internet, and you’ll invariably get a Jekyll and Hyde definition. Yes, the author will take pains to explain what digital humanities is, then cheerfully tell you what it’s not. Go on. Stop here for a moment and do a brief search on Google. You’ll see why a lot of people still prefer to say, it depends.

But that’s neither here nor there. Digital Humanities is a smorgasbord of two things: digital and humanities. A more technical definition would be this: digital humanities is an area of research, teaching, and creation concerned with the intersection of computing and the disciplines of the humanities1. Don’t let the big words scare you. If you’re a computer geek, you’d instantly recognise a mashup when you see one. Not mashed potatoes. Mashup.

Long, long time ago, in a galaxy far, far away, web applications used to exist in their own universes. I used one application for emails, another for storing passwords, yet another for shelving mundane notes. It was a simpler time, when web developers dug their own wells, leaped gleefully into it, then refused to come out. In short, web applications didn’t bother talking to each other. No one thought about making online apps like Google Calendar, Evernote, or Yahoo Mail do more than what they were originally built for. Then, Yahoo Pipes came along. If you’ve never heard of Yahoo Pipes before, it’s okay. But Yahoo Pipes was a real thing. It was clunky. It was ugly. But it freed users, or geek-empowered ones, from the shackles of app mediocrity. With Pipes, we were able to stitch connections between different web applications. Long before Google Reader was born, geeks were already using Pipes to merge and manage website feeds. Today, of course, APIs are free and abundant. I think the now defunct Pipes taught us huge things about digital convergence.

So mashups aren’t new. This is important because digital humanities is a mashup between what computers do, and well, what our teachers either called moral education, social studies or history during our Primary and Secondary school years. It was Roberta Busa, a Jesuit priest, who first laid the foundations of digital humanities. He employed computing power to analyse the works of Saint Thomas Aquinas. By drawing out and grouping different inflected forms of words, Roberta Busa successfully created a definitive index of huge and important compendiums of religious history. Roberta Busa did not invent a revolutionary iPhone app. What he did was more far-reaching. He made the work of other researchers easier. By creating new ways of looking at ancient texts, he empowered other researchers to extract unique insights not only about Thomas Aquinas, but also the environment he lived in, the academic life he participated in, and the sources that were available to him at that time.

Digital humanities projects almost always begin with a data source, involve some kind of textual analysis before delivering on an outcome. Because computing is such a large part of digital humanities, it’s no surprise that the digital humanities workflow closely resembles the grind that database administrators perform day-in, day-out. The data management workflow of Extract, Transform and Load (ETL) is the foundation of all data-related activities in the computing world.

In the first phase of the ETL process, a source is identified, and data extracted from it. Because data sources not only appear in a wide variety of formats but are also placed under different security protocols, part of the extraction phase is discovering and inventing methods to pull relevant data out. The most common data sources are flat files, SQL databases, CSV, RSS and XML. With universal programming techniques like Document Object Model (DOM) being established, even static HTML pages can become viable data sources.

In the second part of the ETL process, data is transformed, or to put it simply, cleaned up and organised in a meaningful, consistent way. In a digital mapping project, for example, I might be pulling information from two different websites. Website A uses the traditional longitude-latitude way of plotting coordinates, while Website B uses a projected coordinate system such as Universal Transverse Mercator. Before I begin any kind of analysis, I’d have to make sure the information from Websites A and B express only one kind of coordinates. The attempt to standardise information between multiple sources is an important, and a time-honoured transformation task.

In the last part of the ETL process, data is loaded into its final destination, which might be as simple as an Excel spreadsheet, a full-fledged data warehouse or even a static HTML document. Because these destinations are increasingly likely to be found outside of the company’s firewall as external data 2, they may eventually become sources of data themselves, and the whole ETL process is repeated for someone else.

While the ETL process is fundamental to data management, it’s only adequate if our data management activities finish up at parking the information somewhere safe and secure. Meanwhile, the modern era has moved on. It’s become more complex, demanding quicker insights. The ETL process requires an additional layer to make it truly useful, and more importantly, relevant for the digital age. For ETL, the additional layer is business analytics, which aims to create knowledge from otherwise mute data. Such information is critical in making decisions. An example of of how static data gets turned into knowledge is shown in this simple diagram 3:

The challenges that the ETL process face are perhaps similar to the ones faced by traditional methods of humanities-based learning. While both ETL and humanities are foundational, and thus cannot be ignored, they need another technological layer to inspire a broader understanding of topics that are flocking to new virtual platforms. It’s said that human beings are by nature, social animals. If that’s true, then mashups like digital humanities are the natural response to a very human desire for collaboration.

Show 3 footnotes

  1. Digital Humanities. In Wikipedia. Retrieved May 07, 2016, from
  2. Davenport, T. Big data at work
  3. Cuesta, Hector Practical Data Analysis

How Experience Engineering can make your customers fall in love

It’s 8:30 am. You reach the office and turn on the computer. To your horror, the machine refuses to start. You take a deep breath, recollect yourself, and put in a call to your company’s IT HelpDesk. When the line finally connects, an agent tells you in a businesslike voice: “We regret the inconvenience of your computer problem. All our technicians are busy. We can only send a technician to your place this evening, after 5:00 pm.”

How would that make you feel? Furious, I suppose.

Now, imagine instead that the agent says: “We regret the inconvenience of your computer problem. All our technicians are already out on their assignments. I know I can get a technician to your place tomorrow morning, but let me see if I can send one to help you out by today.” After a short instant, the customer service agent returns. “Good news!” she says. “I managed to book a technician for you, but he’s only able to arrive at your office after 5:00 pm. I know it’s rather late, but at least you’ll get your computer fixed today.”

Although both scenarios led to the same outcome, I bet the second response felt a lot better. The reason is simple. The second response is a carefully-crafted script that is designed to influence how a customer interprets what he is being told. It’s experience engineering at its finest1. Experience engineering can be easily achieved with three specific techniques; they are Advocacy, Positive Language and Anchoring.


Service interactions are often moments of truth for both the customer and the organisation. Although most customer service training promotes the value of threading service interactions with empathy, it is seldom enough. In experience engineering, customer service agents practice advocacy to win the trust of their customers, as well as influence the way customers perceive the level of service they have received.

Ikea has a generous return policy that is founded on the endearing but bold principle of It’s okay to change your mind. Just last week, I took advantage of this policy by returning some chairs that were simply too small for my dining table. Lugging all eight disassembled chairs to the service counter at the Tampines branch of Ikea, I was told by a retail assistant: “I’m sorry, sir, but your wife made the original purchase, so we can only refund the charges to her credit card. For that, we’ll need her signature.”

“But she’s working,” I countered. “She can only come here in the evening. Now, in the meantime, what am I going to do with these chairs?”

“I understand your frustration, sir. I have an idea that might help, but I’d need to check with my supervisor first. Please wait a moment,” the retail assistant said, and went into a back office to confer with her supervisor. A moment later, she returned with a big smile. “Thank you for waiting, sir. I am glad to tell you that we can refund the charges back into your personal credit card instead of your wife’s. With one condition, though. You need to inform your wife that the money is now in your account.”

“Gladly!” I exclaimed in relief.

Ikea could well have maintained their original decision to disallow the refund, but it did not. In its quest to make every transaction effortless, Ikea was perfectly willing to bend the rules a little and process the refund into my personal credit card instead. Of course, I realised that Ikea probably offers this type of unusual refunds everyday, as a standard operating procedure against clueless and disgruntled husbands like me.

The bottom line is this. Ikea’s admirable effort at experience engineering empowered the retail assistant to demonstrate, in a very practical way, that she was fully on my side. I was made to feel special. Before I left the store, I wrote a glowing feedback for the retail assistant who had served me. Smart experience engineering tends to inspire high customers satisfaction scores.

Positive Language

Although difficult, customer service agents must diligently resist the temptation to use words or phrases like no, not, cannot or never. Negative Language conveys defensiveness that is easy for customers to detect and get impatient with.

Say you recently bought a smart television, and for some reason, it’s not streaming the complete suite of internet channels. You call the product support line, and an agent tells you: “I’m sorry, but we do not have your TV’s serial number on record. You cannot receive premium support until you first register your product online.”

An agent who practices experience engineering, on the other hand, might say: “I understand the problem. It looks like I need to escalate this to a network engineer. I see that you have yet to register your product online. This should only take a few moments, and I will guide you through the registration process. Are you in front of your computer now?”

Positive Language conveys respect and a genuine desire to reach a beneficial outcome for the customer.


It’s no secret that customer service interactions, if handled through the lens of experience engineering, requires a keen understanding of human psychology. Customer service agents must be on a constant lookout for opportunities to frame a given solution as more positive and superior by comparing it to another inferior one.

My friend, Anson, recently bought a ticket for a coach that goes from Singapore to Kuala Lumpur. He reached the coach station at 7:00 am, only to be told by the service agent: “Apologies, but I’m afraid we’ve cancelled the coach transfer because of an accident that’s happened at the Causeway. Traffic is very jammed. We can only rebook you for tonight’s leg, at 9:00 pm.”

Anson was naturally upset, especially since he knew that the bus company had several earlier coach transfers throughout the day. He angrily accepted the offer, at the same time vowing never to use the services of the same bus company.

But what if the service agent had practiced experience engineering? She might have told Anson instead: “I apologise for the last minute cancellation. I know I can rebook you for tomorrow morning’s coach, at the same timing. But let me see if I can get you a coach seat today.” After a brief check, the agent might then proceed to inform: “Good news, sir. I got you a seat for a coach that’s going out tonight. I know it’s inconvenient, but at least you’ll be able to start your trip today.”

Anchoring is a strong technique for eliciting support from the customer, because he or she is given some control over the outcome. The customer sees that the business is genuinely going out of its way to provide as much of a hassle-free experience as possible.

Now, if you were in Anson’s shoes in both situations, how would you have felt?

How to create effective flowcharts

Flowcharts are incredibly handy tools for process mapping. I love using flowcharts because they are quick and easy to draw. Furthermore, flowcharts are visceral, in that people instinctively recognise what they represent, how they should be read. To increase the effectiveness of flowcharts, here are a couple of simple rules to follow1:

Define the boundaries of work: Like a race, every flowchart should have a clear start and finish, represented by rounded rectangle symbols.

Use a logical directional flow:
Flowcharts are visual tools. Therefore, it’s vital for a flowchart to be able to tell its story quickly. The best flowcharts strictly follow a single direction: either left-to-right, or top-to-bottom. This makes it easier to see how one activity comes after another. On the other hand, if arrows are allowed to point in different directions, the flowchart can swiftly become a mess.

Use symbols: Good flowcharts capture end-to-end processes. Between the start and end of a typical workflow may lie several kinds of activities. It’s good practice to describe activities with meaningful symbols. This way, a person reviewing a flowchart can immediately grasp the kind of work involved.

Keep symbols the same distance from one another: Remember that the flowchart is first and foremost a visual tool. Thus, it always pays to devote some attention to how it is displayed. Something as trivial as making sure that symbols are the same distance from one another really goes a long way in making the flowchart easier to digest.

Avoid crossing lines: As the title says, crossing lines in flowcharts should be avoided. However, don’t spend too much time trying to make sure every line flows cleanly. If crossing lines is inevitable, then do it this way:

Properly label decision branches: Nothing is more confusing than a decision symbol whose branches are either mis-labeled, or worse, not labeled at all. Always label the branches that emerge from decision symbols.

Identify output of activities Lastly, it’s good practice to label the outputs of activities, when it is necessary for understanding.

Although flowcharts are powerful tools, they are only appropriate for drill-down views within a larger process. Often, these focused views do not involve very many stakeholders, and the alternation of work between stakeholders is limited.

What about you? I’d love to hear from you other best practices you’ve uncovered while flowcharting. Leave your thoughts in the comments section.

Sick and tired of leading lousy teams? Here’s what to do

As we enter a turbulent century, more organisations are looking for new ways to respond to:

  • the growing demand for speed and accessibility of services,
  • the emphasis on delivering an effortless, integrated customer experience
  • radical innovation in technology, technological concepts and platforms,
  • the trend towards a more globalised environment, social responsibility, and
  • uncertain economic pressures.

Challenges at the workplace are so complex, they cannot be solved by a single person, but by a team. Though all teams are groups, not all groups are teams. Groups are made up of two or more people with shared characteristics. Teams, on the other hand, come together to bring about an agreed beneficial change within a fixed duration. In short, teams are formed to accomplish projects.

Teams can either make or break a project. Besides the Project Leader and Sponsor, the real foundation of a good team is people who:

  • dedicate themselves to making the team succeed, are willing to collaborate with others to reach a mutual benefit,
  • possess the requisite knowledge, skills and experience, and
  • become excited at the notion of contributing to a project.

When a project is started, there is often no clear idea about who the specific members are. Organisations frequently make the mistake of picking a member just because he is available, rather than because of his ability. Although effective teams are made up of people with different abilities, it makes sense to pick members with knowledge, skills and experience that are relevant to the project.

Before a team is created, the Project Leader and Sponsor should work out the general direction of the project. For example, is the project process-driven? Does it require changes to an enterprise resource system? Will it modify a long-standing policy? These questions will help the Project Leader and Sponsor pick the correct members for the team. More importantly, though, it will also help the Project Leader and Sponsor assess if existing employees need training, and secure the necessary funds for it. Early planning for teams is essential, and will result in a Team Charter, as well as a Team Profile.

The Team Charter

It is natural for each team member to possess different ideas about the project. Persuading the team- especially cross-functional ones– to travel along the same direction can be challenging. A simple tool like the Goals, Roles and Procedures Pyramid may serve as a useful map. Split into four levels, the Pyramid also doubles up as a powerful troubleshooting tool. If a problem appears at a particular level, for example, the team should look up one level in the Pyramid to discover its root cause 1.

Project Goal

To be effective, teams must maintain contact with the goals of the organisation 2. Therefore, project goals must be firmly linked with the organisation’s mission, vision and strategies. As the project’s goal becomes clearer, so does the team’s purpose. Both are interrelated.
All teams benefit from a shared vision of what the project will achieve, as well as a general idea on what effort is required to deliver outcomes. Project Leaders and Sponsors have a special responsibility to describe how the team’s efforts impact the larger organisation.

When the team works on something they know is important to the organisation, its members become more motivated to give their best. Hence, purpose is the most significant reason for a team’s success. It furnishes the team with focus, as well as direction.

Project Roles

Project Leaders are usually the managers of the day-to-day business functions that will be impacted by the project; while Sponsors often own and control the resources that are required for the project to succeed. Both Project Leader and Sponsor must be in complete agreement about the project, its outcome, and the other key roles that team members will serve in the project. Other key project roles 3 might include:

  • Client: Coordinates or represents the interests and needs of of end-user groups. If there are several end-user groups, each with a differing view, there may be multiple clients.
  • Information Technology Expert: A required resource if the project involves information technology or impacts an enterprise resource system.
  • Technical Specialist: People who possess expert essential skills or high levels of crucial access.
  • Buyer: They procure or commission projects on behalf of end-users and are judged primarily on their ability to source for reliable suppliers and negotiate competitive prices on contracts or services.
  • End User: Often, to streamline and aggregate the concerns of this potentially large group, end-users are represented by clients. However, this does not mean that the project will not benefit from directly communicating with this group at different stages of the project.
  • Quality Assurance: Although popular only in large, protracted projects, the Quality Assurance expert plays a very important role in ensuring that prescribed methodologies are carried out properly.

Experienced Project Leaders sometimes introduce a RACI Matrix to outline the project-related activities that are expected from each Project Role. The RACI Matrix is particularly effective for large, complex teams whose members carry out multiple roles, as it neatly defines the key responsibility areas of members who are:

  • Responsible
  • Accountable
  • Consulted
  • Informed


The Pyramid outlines the general procedures that are required to sustain the project’s momentum, such as the form and frequency of official meetings. Because different project frameworks exist, the methodology that the team intends to adopt for its projects should be mentioned, to provide a useful reference point for future projects. Some examples of project frameworks include Lean Six Sigma’s DMAIC, Agile’s SCRUM, or the omnipresent PDCA method.

At an early stage, Project Leaders must work together with the team to establish ground rules. Ground rules determine:

  • How team conflicts are handled,
  • How project decisions are taken, and
  • A code of conduct that emphasises clarity and respect during discussions and team meetings.

When teams possess a strong understanding of how their work will proceed, they become particularly effective in carrying out their duties.


Team members are individuals who have their own set of motivations and temperaments. When brought together, conflict is likely. Although most people associate conflict with anger and tension, it can be a positive force in projects. Conflict deepens discussions, forcing members to become more creative, and examine new ideas more thoroughly. Besides leading the effort to establish ground rules, Project Leaders must also develop plans to quickly bond the team. In the longer term, Project Leaders should acquire the necessary facilitation skills to manage conflict.

Relations must be managed at a broader level too, as it is vital for teams to know how they interact with other teams, departments and customers. The Project Leader and Sponsor must ensure that the lines of communication between the team and the larger organisation remain open and in working order. Key questions that teams frequently confront are:

  • How to ask for assistance from other teams or departments if it is needed?
  • How to obtain the data that it needs?
  • How to let the organisation know what they are * doing?

Team Profile

When teams form, they are rarely able to unlock the full knowledge of every member. Human capital remains locked because teams always get dominated by the most senior, vocal or confident member, even if they are not the most expert. The genuine experts, sensing that their views would not be appreciated, shut down and take a back seat.

A simple intervention, performed early in the team’s formation, can stop this negative outcome. When teams work together to create a detailed profile of every individual’s knowledge, skills and experience, they are more likely to use their knowledge to devise solutions to problems. In a study on this phenomenon, Professor Bryan L Bonner explains that the simple exercise can radically change the criterion for team power from Social Influence to Information Influence 4.

By listing out a team member’s abilities and how it relates to the project, individuals feel valued and become more engaged. It also helps the Project Leader and Sponsor identify the abilities that are immediately available, as well as any skills deficit that can be addressed either by training and development, or acquiring outside help.

A comprehensive team profile forms the baseline of knowledge, skills and experience at the beginning of every project, and helps the organisation measure the learning outcomes of the project, celebrate the growth of individual team members, and identify potential Leaders for future projects.

Show 4 footnotes

  1. Thus, if teams encounter problems in Relations, the actual cause might be found in unclear or conflicting Procedures. See Mary Federico and Renee Beaty, Rath and Strong’s Six Sigma Team Pocket Guide (McGraw-Hill), pg 63
  2. Peter R Scholtes, Brian L Joiner and Barbara J Streibel, The TEAM Handbook, Second Edition (Oriel Incorporated Publishing), pg 1-3
  3. Peter Hobbs, Essential Managers Project Management (Dorling Kindersey Limited), pg 18
  4. Bryan L. Bonner and Alexander R Bolinger, Bring Out the Best in Your Team (Harvard Business Review, September 2014), pg 26

Mapping team life cycles the right way

Working with teams, I am often surprised by the variety and depth of emotions that individual members express, from initial fear and anxiety, to delight once the project gets underway. Over time, I began to recognise patterns at different stages of a project’s life cycle. The infographic aptly illustrates the 5 main stages.

Not considering cost of quality is dangerous

In projects, teams often have a difficult time quantifying tangible benefits. This is tragic, since tangible benefits are an important way that teams communicate their achievements to the larger organisation. Moreover, tangible benefits help secure buy-in, especially from the organisation’s senior executives. Amongst the most enduring tangible benefits that are articulated are:

  • Labours Costs– a process that initially occupied 10 employees now occupies 4 employees. The savings are derived from the total estimated wage of the 6 employees that have been removed.
  • Material Costs– a process that initially required 20,000 sheets of paper to be printed now requires none. The savings are derived from the total retail cost of the 20,000 sheets of paper. Associated with this is also the cost of printing, which includes toners, staplers etc.
  • Cost Avoidance– a department resists a vendor’s attempt to raise prices by 5 percent, allowing the department to avoid spending an additional $200,000 that year. This usually involves avoiding a future cost increase by delaying, reducing or even eliminating a proposed price increase.
  • Cost Recovery– a department reclaims money that was previously spent on items that are now considered obsolete. Usually, this entails selling equipment back to a supplier, or to any other interested parties.

A tangible benefit that is frequently ignored is Cost of Quality, or rather, actions taken to ensure that a particular product or service meets expectations. These quantifiable activities may include:

  • Verification– costs of labour and materials that are needed to check incoming service, product or process setup.
  • Supplier rating– costs of labour and materials that are needed to assess and approve suppliers.
  • Waste– costs of labour and materials dedicated to performing unnecessary work as a result of errors, poor organisation or communication.
  • Scrap– Defective product or material that cannot be repaired, re-used or sold. Rework or rectification– costs of labour and materials needed to correct defective materials, services or errors.
  • Failure analysis– costs of labour and materials associated with activity to establish the causes of internal product or service failure.

Just about a month ago, my friend Mark submitted a request to his company’s IT department to set up a web server. The first person to receive the request was a Service Representative, who collected all the necessary information. The request was then passed to the Infrastructure team, who promptly asked Mark the same information that the Service Representative had earlier collected. Mark did not know better, and gamely repeated the same step he had done with the Service Representative. Then, Mark’s request was passed over the the User Accounts team, who, to Mark’s utter amazement, began to ask the same questions that the previous two parties had asked. Mark began to feel frustrated and wrote a complaint email to the the IT department. The IT department was apologetic, and promised to retrieve the information from the Service Representative.

Now, if the IT department had had a proper process in place, Mark would not have had to restart his application at every point in the request process. This would have saved a lot in terms of lead and cycle time. Waste is one of the most destructive Cost of Quality. Frequently, business units that are not organised properly cannot see waste, but waste is extremely visible to the customer.

Four Tips About Benchmark Design You Should Know

I often get annoyed when people talk about benchmarking. It’s not that I dislike the whole idea of benchmarking, but that a lot of discussion on the topic is plain wrong.

For example, benchmarking programmes should not be implemented in the absence of a management framework that already tracks performance measurements. Good performance measurements reflect the most critical operating aspects of business processes, systems, governance and function.

In almost all instances, benchmarking benefits from an environment where business excellence frameworks like the Singapore Quality Class (SQC) or the European Foundation for Quality Management Excellence Model are actively applied. Instead of being an orphaned afterthought, benchmarking becomes a natural extension of business, and a core component of knowledge management.

A comprehensive benchmarking programme internalises 4 guiding principles: the four guiding principles 1 are Measurement Focus, Measurement Perspective, Measurement Control and Collection of Data.

Measurement Focus

Organisations are fond of cluttering their dashboards with performance metrics that measure almost every aspect of their operations. After all, common wisdom is that what cannot be measured cannot be improved. However, a lot of times, organisations are measuring things that just not that important. Worse, things get measured and reported, but lead to no real change. How useful is soliciting the customer satisfaction rating of every phone-call if the scores are simply parked in a database, and only dragged out in quarterly meetings?

Performance measurements must be actionable, and for them to actionable, organisations need to:

  • establish where value to a customer is created in either a work area or business process.
  • determine where value is lost, either through process wastes like errors, rework, duplication, or high costs and workplace accidents.
  • focus on business functions whose performance clearly deviates from standards, service levels or regulations.

Measurement Perspective

Like performance measurements, benchmarks arrive in two forms: leading and lagging indicators. While leading indicators are predictive, lagging indicators are reactive. Most leading indicators do not measure actual performance, but predict them instead. Thus, a high turnover rate in the Engineering department- the leading indicator– may forecast a future dip in customer satisfaction, presumably because of a decline in product quality.

Lagging indicators describe, often posthumously, the actual performance of processes over a given duration. Financial metrics like sales, profits and expenditures are traditional examples of lagging indicators that organisations use to compare the impact of actual outcomes versus targeted outcomes.

A comprehensive benchmarking effort enlists both leading and lagging indicators.

Management Control

Although benchmarks can be set at almost every level of the organisation- cascading from the enterprise level right down to the individual employee– benchmarking is essentially people-centric. From the outset, the benchmarking effort must establish clear ownership over who owns what performance metric, based on the individual level of authority, scope of responsibility, and skill sets. It is unfair to assign employees responsibility over benchmarks that they may not have direct control over.

Gathering of Data

While it’s true that performance metrics must be quantifiable to be effective, some organisations rush headlong into creating as many as they can, without evaluating if the data is easy to collect in the first place. The problem is made worse by the fact that most entrenched organisations still lack a robust data-driven culture. Again, business excellence adopters possess a clear advantage, since business excellence frameworks emphasise the importance of collecting and acting on the results of key business enablers like processes, products and services.

The best performance benchmarks are collected without investing heavily in either time, systems, manpower or budget.

Show 1 footnote

  1. Adapted from Christopher E Bogan and Michael J English, Benchmarking for Best Practices- Winning Through Innovative Adaptation (McGraw-Hill), pg 47

Making Process Improvement a Green Affair

It’s easy to underestimate the impact that process improvements has on the environment, but it’s real. Whichever tool a team uses to examine and improve their work, one of the first targets is usually muda. Muda is a Japanese word that means waste. Wastes appear in all processes, even in processes that have been improved. As a result, employees engage in continuous improvement activities like standardisation, 5S housekeeping campaigns, work improvement projects and staff suggestions to make sure that waste is kept at bay.

In almost all processes, 7 types of wastes frequently occur.

  • Overproducing– which refers to purchasing or providing a service, information package or product before it is needed. Overproducing also happens if a particular space- with its air-conditioning and lighting- is made available when there is little or no need for it.
  • Inventory– which refers to work piling up in inboxes, partially completed tasks or documents, files, online or electronic storage. Excess inventory also occurs when files and records are kept without regularly purging old items. This makes searching for records complex, and demands a huge investment in storage facilities.
  • Waiting– which refers to delays caused by pending reviews or approval. Even difficulty in accessing, retrieving and manipulating information cause delays.
  • Extra Processing– which refers to time spent doing unnecessary steps. An employee who has to spend time re-keying or reformatting data, printing extra copies of unneeded reports, multiple versions of drafts etc, is likely to be caught in a loop which triggers other kinds of wastes like Waiting.
  • Rework– which is one of the most common kind of wastes caused by defects in either a service, product or document. A form that contains unclear instructions, for example, may cause the customer to provide wrong information. The person who receives the form is forced to either amend the defective form, or request the customer to resubmit a fresh form. Both are considered rework.
  • Excess Motion– which means that when a worker wants to retrieve anything that is essential to a task, he or she finds that it is out-of-reach. These items may include data, information, files, centralised inboxes, stationary, printers, fax and copy machines.
  • Transportation– which refers to the excessive movement of work between locations. E-mail attachments, documents or files routed for multiple layers of approvals or evaluation, even expertise that is located too far away from where it is really needed can cause this waste.

Wastes are non-value-adding activities that do not directly benefit either an internal or external customer. A service is not enhanced by Extra Processing, for example. Neither does a product take on a better shape or quality by Rework. It does, however, make customers unhappy about the organisation.

In a knowledge-intensive environment, for example, wastes appear in many ways, but are increasingly caused by excessive and unnecessary use of smart devices like mobile phones, laptops, desktop computers and smart watches.

While portability exacts an environmental price in the creation, maintenance and disposal of batteries, all modern devices exact a price in computing power, which is neither cheap nor evenly distributed across societies.

Computing power needs physical spaces to host servers, as well as precious electricity to feed an ever-growing demand for speed, storage and intelligence. Almost all wastes will trigger unproductive use of computing power in the form of extra emails that are sent to chase for late submissions, or a customer staying that much longer in a chat session to finally obtain the information he or she needs.

For organisations that still use traditional paper documents, wastes like Rework are liable to create tons of paperwork, cycling between customer and organisation in a deadly but entirely avoidable loop. Imagine the number of trees that are chopped down to support such horrifying practices.

There is no doubt that that process improvements can play a significant part in helping organisations achieve energy and environmental conservation.

The Ultimate Cheat Sheet on project selection

Modern businesses recognise the importance of driving innovation and continuous improvement through team-based projects. This does not mean, however, that organisations have gotten smarter at selecting the correct type of projects. In this cheat sheet, I list four mistakes that are commonly made, but easy to avoid.

Selecting problems that no one really cares about

It’s tragic, but teams, departments and business units still choose projects that nobody cares much about. Often, it’s because the scope of the perceived problem appears too minute, or the potential project might not be critical to business objectives. Whatever the case might be, a neglected project suffers from corporate inattention, and the team involved in it will wilt.

Selecting a solution to implement rather than a problem to investigate

Nothing alarms me more than facilitating a team of employees who, instead of investigating the root causes of a problem, have already determined the solution. I find this fairly typical in projects led either by newly-minted IT Professionals or employees who have grown too close to the process.

In this instance, a team of managers working at a college admissions office might describe their project with an ambitious title like: Automate the fee payment process with an online application. The title is already a warning sign that danger lurks ahead. By enlisting words like automate and online application, the team has already made up its mind on the solution. No problem was investigated.

There are very little exceptions to the rule. Projects should always be described from a process standpoint. The team from the college admissions office would do their project far greater justice by describing it as an effort to Reduce the turnaround time for students paying school fees instead.

Selecting a process that is in transition

Businesses nowadays face lots of turbulent change, either in technology or in regulatory compliance. Inviting teams to improve a process or function that is going to be changed soon will only waste company resources. There is no point investigating a manual leave application process, for example, when some other team is independently migrating it to an Enterprise Resource Planning (ERP) system. The work being done by the first team would quickly become redundant.

Selecting a system to study, rather than a process

A common error committed by new teams is to be too ambitious for their own good. Instead of breaking a project up into manageable bits with short durations and clear targets, they attempt to take on an entire system or framework of business functions at once. Leave such high-order improvements to management teams or portfolio managers. Ongoing work improvement teams have a better chance of success if they focus on a smaller process to study and subsequently improve. Realistic timelines and targets make for more motivated teams.

Are there particular types of projects that you consistently avoid? Do share by commenting on this post!