Visualisation: That crucial element for Agile in ERP

Once upon a time, we wanted to use Test Driven Development (TDD) on a small ERP delivery project. This would reduce documentation by 70% and lead to a time saving of upto 40%. We were very excited.

We ran the familiarisation workshops. Explained how the method will be different – to the customer and to our own development teams. Got everyone’s concurrence. And then we started with a small project in pilot.

 

Except, it didn't take off. But that experience taught me something really important about adoption of Agile in ERP projects. The missing link was simply this – because ERP (even small ERP deliveries) are huge, we were not able to visualise the end product. That is why we could not start with Test Driven Development.

 

Once we had the Root Cause Analysis, it was relatively easy. For the next application, I sat and visualised the ENTIRE application – all user types, with all their screens, and behavior of each button.

 

We didn’t have the luxury of standard screens that most ERP customers have – they know the standard screen buttons available to them and know what they look like. We had to visualise the entire application from scratch.

But here is the important thing – once the wireframing was done, it was much easier to do Test Cases. We simply knew what to expect!

 

So here’s the recommendation – when we try to do TDD, especially on non traditional areas like ERP, spend some time and expense on a soft skills trainer – and do a visualisation, wireframing workshop. For the business owner and users. If they can visualise what they want, the rest of the exercise becomes much easier. Today, I find Visualisation to be a really powerful element in application design.

 

And visualisation is a specialised skill. Usually, it needs to be learnt.

Investment: The Core of a Change Management Program

I play this online city building game. It’s a MMG (Massive Multi player game) which means that you don’t just build a city alone, you also interact with other players, attacking their cities and protecting your own. Obviously, the game rewards you for this mutual destruction.

At level 6, I attacked a Level 22 player, and won! Imagine my happiness. Which was successfully doused when, 2 days letter, I got a threat message from the said player, telling me that my cities will be “destroyed” in no time. I laughed, and wrote back to him, saying that it is only a game, and that he could destroy all he wants. I can walk away from the game in 10 minutes and never look back.

At level 30, when the same player attacked me, I wasn’t so amused. I sent *him* a message saying that I play a solo game, and that he had better stay away from *my* cities.

So, what changed? This: I became more *INVESTED* in the game. Suddenly, there was a stake to protect.

That’s what this post is about. We brought that learning back to the Change Management projects we were doing. The objective of change management is not to familiarise and train. It’s not to remove resistance or aid adoption.

The CORE of change management – is to make your user *INVESTED* in the change. It becomes theirs and *they* have a stake to protect.

In designing change management interventions today, the first question one asks is, “Will this make them invested in the new state of things?”

I have found that this change in perspective has greatly enriched the interventions. It makes it mandatory for us to find what will get them invested. And it has helped me understand that time is a major factor in ensuring this *investment*. Like leadership and parenting, it cannot be rushed, nor squeezed into “quality time”.

The Data Journey Diagram/Data River Diagram

Today, I am going to talk about a tool that I have just created. The tool is here for discussion, but NOT for re-use or re-distribution. Please use your conscience and do not re-use this tool without my permission, (which can be had for the asking).

The tool is called the Data Journey Diagram.

What

Graphical illustration to help users understand the usage of data generated by them, and to help BI designers see the most expected fallacies in their data.

For

Primarily, the tool is for the end users who generate data and the Analytics consultants who design the analytics solution for an organisation. The other stakeholders are the IT department, legal, security and line businesses.

How

The tool is very simple. We put the end users, the MIS team, and the data analytics team in one room.

Then we create a meandering river shape on the board. The Analytics Consultant puts a simple report at the end of the line. Then, he puts in all the data elements that go into making that report.

Slowly, each stakeholder who owns each data point, writes down where each data element comes from – all the processing points, and all the hands that the data element passes through. The river is used as a rough measure of time flow.

For each data element that comes from a different source, at the point of convergence, we draw a separate line to indicate a contributing tributary. Then the journey carries on backwards until we have a river system in place – indicating all the places where the data comes from, how it all comes together et al.

 

Ground Rules

At each stage, ONLY the stakeholder who owns the data at that point, will be allowed to create a “milestone rock” and name it. No one else.

 

Limitations

This tool does NOT:

A. Indicate dependencies.

B. Indicate And/or relationships

C. Indicate mathematical or logical operations. We know that 2 data elements come together, but we do not know if they use averages or totals.

 

What is achieved

At the end of this exercise, end users are able to appreciate, in very simple terms, how their data errors impact decision making at the CEO level.

The Analysts are able to see sources of the data being used in the high end analytics reports, and can talk to the stakeholders right there to find out if there are any anticipated data errors – time lag, fallacy, human error etc. These are VERY important inputs for the analytics design team, because GIGO is as true today as it was when computers were invented. 

So, what are your thoughts?

 

What the Everest teaches us about creating great organisations

If you want to trek up a hill, you can do it alone. And with some practice and grit, do it really well.

 But no one, and no one, can climb the Everest alone. To conquer a mountain, you must climb with a team.

The rules of the mountains teach much. There is no hierarchy. The respect is earned not by who pays whom, but by who knows what and who does what.

The Sherpa who, strictly speaking, is a paid porter, gets much respect. Because he has been up and down that mountain many times, and because he has spent his life observing this mountain, worshipping her. He understands her moods way better than you ever will. When he tells you to turn, you always do. Because he knows better.

What if we spent some time doing that in organisations? Listening to people who have been around a long time.. understanding from them why things failed when they failed, what happened in the past. . it will waste time and bind our thought process. But it will also teach us lessons that we dont need to relearn.

 I can remember a case study that we did at one of the courses. The details are not important, but the message was the same.

Do you think this would work for organisations? Why or why not?

* This post first appeared on my blog on ITtoolbox/toolbox.com on January 28, 2014

On Requirement Gathering

If you are a system design consultant, this piece is for you.

There is a children's poem that explains how the battle was lost for want of a horse shoe nail.

Take a printout of the poem and tape it just above your screen.
Remember that poem when you are doing requirement gathering. It is ALWAYS the small things.
****
When do you do the transaction - how long after you have done it in the real world? Why do you think that is the optimal time?

What do you look for when deciding your sales pitch? What are the elements you need at once place, together?

When do you think its ok to share your password with a colleague? For which apps will you never do it?

What will you do if your orgn KRA requires you to fill daily updates, but you are in a field area with no signal?
***
After 15 years, I have found that the level, industry, or technology does not matter. When a project is delayed or faces user resistance, very often, it is because we did not ask the human questions.

We did not understand the fine print of their lives.

At its core, requirement gathering is a human process. All our phenomenal technology - retina tracking, gesture analysis, only goes so far. In the Indian system, the importance paid to the individual, more than the 'system' is at the core of this human centric approach.  

As requirement gatherers, we should try to understand that this is a human interacting with a system, where the human is in charge. With that conscious shift in understanding, we will find ourselves approaching the discipline very differently. 

Shifting the consciousness to gratitude every morning

If you have noticed, before opening the store, a shopkeeper bends down and touches the floor of the shop. A performer touches the last step of the stage before getting on the stage. An auto driver starts the day by doing a small agarbatti or pooja in the auto.
Ever wondered why that is?
The shopkeeper, performer, and auto driver get their livelihood (rozi-roti) from the shop, stage, and auto respectively. Every morning, before they start work, they are thanking the means of their livelihood for providing for their families, and praying to it to bless them with a good performance.

There are some things that don't take a lot of time and effort, but cause a massive shift in our consciousness. The practice of thanking our livelihood before starting our work day is, I think, one such.

Wealth Generation in everyday life

One of the questions that I often asked myself is: How did Indian households accumulate wealth through literally centuries of Muslim rule. During this rule, Hindus were taxed at insane rates, and at many more instances than the non Hindus. The historical texts I read recently had stories of how the rulers prided themselves on systematically stripping the Hindus of all wealth, forcing them into penury and then incentivising conversion to Islam by giving monetary benefits.

Important Disclaimers
1. Please do not judge these rulers by the standards of today. Secularism, which is a given today in most modern civilisations, was a luxury in almost every part of the world until just 200 years ago. Remember the Protestant British crown and the impact on the Catholic church? These rulers were not being barbaric. The instruction of the time started by dehumanising all non-followers of a religion. In their minds, the missionaries of Christianity and the Muslim rulers were both converting these people back to humans. We have no right,  therefore, to judge them by our standards. Please refrain. All hate content will summarily deleted. My focus is on understanding financial and trade practices of India. We will stick to that mandate, using these conditions as the context within which these practices were used and how they managed to do some very important wealth generation and preservation.

2. This piece is a result of my research. Most of my sources are family practices, folk lore, and things head from practitioners. Indians have not, to my knowledge, documented their wealth generation and preservation practices. But, thankfully, they have kept their family traditions alive over hundreds of years. The belief system is still very well preserved. I observe and learn from that.

3. Every system has its pluses and minuses - if we judge. If we learn, they are just actions and consequences. My submission is - learn. Do not judge. How you apply these lessons, or whether they  can be made relevant today, is something we can decide for ourselves.


After much searching, am sharing some findings here:

• The family as one unit. 

The unity of the family is so inherent in the culture that even in Independent India, the Karta system is recognised as a type of economic entity - the wealth of the entire family is grouped together, and the expenses are done from the same core. As everyone lives together, expenses are pooled. Clothes are passed from one child to another. Ditto for toys. Skills are distributed, minimising people's dependence on external factors.

• Order of investment

In most Indian families, the first asset that is acquired, if not inherited, is land and real estate. A house, farming land, a shop - the type of real estate depends on the lifestyle and varna of the family. But the uniformity of the preference for this asset type is remarkable. After this, one invests in gold and keeps enough for impending weddings of the next generation. Then, other assets are acquired, if any. 

Do you know why that is important? The rate of inflation on these 2 assets is the highest. If they are secured, they give the highest returns, and one is able to invest at lower values. 

• Consistent small value purchases

At all festivals, a little gold or silver is bought according to the means of the family. Even if a family is very poor, at least once a year, they have to invest in metal as a form of religious ceremony. These small value but consistent purchases slowly build up the corpus of the family. In many trading families, there is a custom of adding one gold coin every Diwali. Imagine the value of that gold within 3 generations - 50 years. 

• The Hundi system and trade practices of pooling 

The Hundi system is well known. This system entails everyone contributing a small sum of money every month. The entire pool is handed over to one member of the group every month by turns. This way, everyone invests a small amount every month but gets a lumpsum perhaps once a year. This was not the only practice of pooling. Several trading communities, in particular, have a parallel system of pooling in parts and harvesting in bulk. 

• Temples as the custodians of wealth 

Almost all religions have the practice of making a small offering to God when we go to a religious place. This makes our religious places incredibly rich. In some South Indian states, the king, through assumed divine birth, is also the owner of the temple treasury. 

This serves many objectives: 

One, in the absence of state sponsorship , the temples could run religious events and ensure cultural continuity. 

Two, temples cannot be raided and looted as easily by rulers as individual homes. A single seth becoming too rich can be forced to part with his wealth by the ruler. But not a temple. 

 

If there are any other lessons, please do share. This is a very important area for us to learn from.