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