What games teach us

A year or two ago, we created a game in the family, to participate in a Board game making contest. The game did not win anything, but in doing test play and refining the game, we all loved it so much that it became a regular in the family. 

Its a trading game based in the SIVC. There are traders and producers, about 7 types of commodities, regulated markets that display the buying and selling rates of the commodities being traded on that day in the market, and of course, free price negotiation among players, ability to add warehouses and factories, get a trading license or a factory license, some protectionist laws that protect domestic producers against price hedging by traders in the home port, and some regulation around how many ports a player might visit in each game play, so that monopolistic players do not develop and every trader, big or small, gets the same trading opportunity in every turn. 

Over the last few years, I observed that while 4 of us play the game, everyone has a very different playing style and strategy. But what was amazing is how closely this mirrors our real life business and investment decisions. 

My brother focuses on commodities that are high margin, but low value, so absolute wealth generated is lower, but they are regularly traded at all ports, so they are high frequency trades. In real life also, he tends to enter businesses that are high margin, high volume, and he has patience, just like in the game. He uses his cash wisely. 

My son bets on a single commodity - it has high value and high margins, but low liquidity. In real life also, he only picks up blue chip stocks and sticks with them. 

I, on the other hand, keep cash rolling. So, i make moderate profits on each trade but don't have the patience for the big kill. I also always keep a diversified portfolio of commodities on my boats. My real life investments are also low risk, high liquidity, and low margin. 

Interesting, isn't it? 

Have you ever learnt something about yourself or another person from a game? 

On setting up an organisation

Let's say you are a leader looking to start a new firm. You have resources, the mandate, and the authority. You also have that manana from heaven - a clean slate. 

Here is one recommended approach to putting your organisation together, if you have the resources.

Organisation Structure

Obviously, one of the first things you will think about is Organisation Structure. 

This part outlines the steps to create an organisation structure that will actually work. 

But first, lets talk about the things that DON'T work. 

• The Structure is led by the leader, not the consultant 

A therapist knows the right behavioural elements, but they don't tell you what to do. Instead, they do the frustrating job of pestering you with questions until you realise what you want to do. There are two kinds of consultants you can bring on board - the first, will do what a therapist does, bring the org structure from within you, because you have to live with that structure, not them. 

The second kind will come in and tell you how you should operate, and put 15 analysts on the job. 

Get the first kind. With one key difference. When they see you doing something that is obviously not going to work, they tell you that upfront. If there is enough trust in the relationship, this leads to mutual learning and saves time. If not, the consultant will have to use the option of asking questions until you realise what is going to work for you. 

Here is why the leader is the key decision maker on culture. 

In Nov 2020, the new CEO, Thierry Delaporte, completely overhauled the org structure of the company. This is the email that he wrote to employees then: 

https://www.cnbctv18.com/information-technology/wipro-ceo-thierry-delaporte-writes-mail-to-employees-highlights-organisational-changes-full-text-7469451.htm

Less than a year later, Wipro had changed its story completely. 

https://timesofindia.indiatimes.com/business/india-business/a-frenchman-sitting-in-paris-turns-wipro-around/articleshow/87091176.cms

How was a behemoth like Wipro transformed in under a year? 

The leader created an org structure that allowed them to monitor the business in a way that worked for them, and then appointed people they trust in key roles. 

THAT is the power of leader led org structures. 

• There is no such thing as Industry Standard or Industry Best Practice 

The only thing that matters is common sense and alignment. Some industries have to do some things more than some other things. We take inputs on that, sure, we understand what others are doing and how its working for them. But we do not make those practices our goalposts. Not in anything, and certainly not in strategic things like Org Structure or Business Planning. 

In an emerging industry, we have the luxury of defining the industry standard. In legacy industries, that bandwidth may be a little lesser, but its there. 

In the early 2000s, all Indian IT companies moved to this grid structure - Verticals and Horizontals - Industry * Geography. It was this matrix structure that was dismantled by Thierry Delaporte. 

What Works aka How to define an Org Structure 

A. Define your first line. 

How do you want to view your business. If you had to get 5 key things about your business on your fingertips and have 6 people on a hotline, what would those numbers be and what would be those 6 roles? 

That's the first step - to define your first line. 

B. After that, do a culture workshop. 

A Culture Workshop is the most important thing that you will do in the Org Structure journey. Write out the 6 words that reflect the culture that you want. 

A CEO I worked with recently was insistent that the word he wanted was "family". Even in a competitive industry like IT, he did not want to create a culture focused on competition or personal excellence alone. When thinking of work, he wanted people to think of the office as a family they belong to. 

In the two years since then, we have done 3 employee dipsticks and family comes right on top when people talk about what their culture is. Trust comes a close second. :) 

C. Then, write the JDs and hire the right people 

JDs are important, esp for your direct line of reporting. Hire the right people. People who bring their own functional expertise, and more importantly, share the same keywords for culture. 

Trust has two components - Intention, and Action 

The first is about shared values. The second is about delivering results. Trust is a biped, it needs both to walk the talk. Ensure you bring people who share the values, but can also deliver business results in a foreseeable time frame. That is the only way that their teams and your stakeholders will trust you. 

C.1 The Compensation 

Do have numbers in mind, but be flexible. This is the only place where "industry standard" almost trumps "What we bring to the table." 

D. The Org Structure guidelines

The next step is to create guidelines for an org structure. You can decide lean and efficient, or gig workers preferred, or diversity first - anything works. But do have a small set of guidelines that you communicate clearly to your first line of command. 

E. Let them make their own organisations 

After this, let them make their own organisations. In fact, have this as a key interview question - as a department head, how would you like to structure your organisation. 

Making it Run

A. Involve your own HR team as early as possible. The longer you let consultants run the show, the harder the KT. 

B. Put HR processes in place. Follow an HR Portfolio management approach. Don't go piecemeal. 

C. Invest in human process excellence. Don't think of the function as paper pushers. Give them aggressive talent targets and give them the teeth to bite. For instance, if a manager loses more than x% of their team over a period, they should be able to highlight that as an organisational process. If they find it hard to fill a position for more than x weeks, either they complain or you complain "We are trying our best" or "Market is tough" is not acceptable response. 

D. Hold your HR accountable. Typically, HR tends to enter the room with reasons like "Business needs". But there will be no business without people. Their core job is to marry business needs with talent aspirations. That is literally their job description. If you bring a numbers based approach to HR, you will find that it is hard to hire the right HR talent, but once in, they will LOVE working with you. 

E. Do NOT compromise on values and culture. It never pays. Its very short term, and it guarantees failure. Even if the values route appears to be longer, more painful and far more expensive, remember that markets can stay volatile a lot longer than economies can stay solvent. So, responding to volatility with volatility-supporting behaviour does not guarantee success. 

How to Manage Client Scope Creep

This post is the result of a good conversation with Abhishek at a recent event. 

He asked how we managed to ensure that there was no scope creep. My projects have usually been on track and within budget, and as Abhishek mentioned, client scope creep is one of the major reasons why large IT projects go out of budget or schedule. 

So, if you are a budding project manager responsible for client management, here is the secret to building great client solution and even better client relationships. 

Most client scope creep comes from 2 areas: 

A. Complex Workflows, where more approval levels are added. 

B. Reports 

The first thing you have to remember when dealing with client scope creep is that they are not trying to trouble you. Their intention is not the squeeze the juice out of you. Their intention is to do the best that they can for their company at the least possible price. 

Surprise! That is your intention too! 

Most vendor PMs do not understand this intention and objective synergy. But when you do, you realise that you and the client PM are on the same side, trying to do the same thing. 

The only thing is, we are using two different approaches to do it. 

So, Step One:

Establish Commonality of Purpose 

Sit down with your client and establish commonality of purpose. Both of you are working towards the same thing: 

A. Create the best possible solution

B. In the least possible time 

C. At the least possible cost

Once it has been stated, it appears intuitive. Yet, until we say it out and put it on the table, it is not so apparent to the other party. In fact, if you wait at the water cooler long enough, you will definitely hear the Project Managers from both sides cribbing. The Client PM usually says one or more of the following: 

• The vendor does not want to do any work or wants to do shoddy work and get away with it. 
• They are not doing enough KT 
• Even for small change they give such a huge estimate, and change request for everything! 
• They just don't understand our business and requirements. I don't know how to explain. 

The Vendor PM will usually say one or more of the following: 

• The Client is really miserly. 
• They always underestimate the time it will take to do something. 
• They are paying us for a cow and want us to make an elephant. 
• They don't understand how the system works. 
• They have such weird requirements! Who works like this? 

So, the step of establishing commonality of purpose is the most important one. It establishes trust and ensures that you row on the same direction, not in opposite directions. 

Once commonality of purpose is established, the next thing is to understand where scope creep is coming from. 

Step Two: 

Diagnose and Guide 

Most scope creep comes from the two areas I have mentioned above. You do your own diagnosis on your projects and understand WHERE the scope creep is coming. And then ask yourself WHY. 

What problem is the client trying to solve by doing this extra work? 

Let's get straight to taming the beast. 

Step Three 

Managing Scope Creep and Making Great Friends 

Here is the most important tip anyone will ever share with you on managing scope creep. It is so important that I am going to write it in caps. 

START WITH YES. 

Whenever the client asks you whether something can be done, NEVER start the conversation with No. if you know that it can be done, start with, "Yes". If you are not sure, start with "We will try to find a way to do this." 

Managing Workflow Complications

Most clients who try to add additional approval and exception workflows are basically trying to tame one beast - Compliance. 

That is the core objective. 

Start the conversation by saying - My work ends with doing the coding. Your work starts after that and goes on forever. So, my work is the shorter one. Let's talk about how this will work after go live in your business. Let's discuss a few scenarios and understand how much additional work it will add for your users, and what you are doing about it now. 

After that, listen. Let them explain all their use cases and exceptions. Understand their compliance needs thoroughly and most importantly, understand how users manage exceptions now. A system that can be excepted by the user in an emergency will eventually be excepted as a matter of course. The user's onboarding learning curve is slow, but their bypassing learning curve for any system is amazingly steep. So, if you make it necessary for users to bypass the system for one thing, they will be bypassing it for most things sooner than you realise. 

After the client has finished putting their requirements on the table, don your product specialist hat (or get your product specialists on board) and design a solution that meets their needs without being overly complicated. I can assure you that most workflows can be simplified. 

Pro Tip: For each workflow step, ask your client: 

• How will this step increase the transaction load of the user? 

Let's understand this with a real life example: 

Let's say that the client wants all travel to go to the department head. The questions we ask then are: 

A. How many travel requests will the DH have to approve in a day? Week? Month? How much time will it take them to approve each (assume reading time). If we go with 5 a week and 5 minutes per TR, that's 25 minutes of extra work per week. For an already stretched executive. 

Next, ask them how they plan to manage situations that are definitely going to arise - the executive on leave, too busy, traveling himself, etc. 

Usually, in such cases, a thing called Delegation of Authority is used. 

Let the client think about that. And then help them understand how to balance compliance with minimum transaction load on the users. 

• What value is this step adding to your process? 

The most frequent response to this is "It gives us better control" or "Compliance." 

Do not resist. After the client says this, sit back in silence and let them think. 

If they do not appear to be making headway, ask gently, "Are you creating a better process, or are you helping someone do CYA? Think about that. If the system can be hacked, it will neither lead to better compliance nor control. Every new control element you put in there is also a hacking opportunity. Think about the real business value of every step. And its real objective." 

Always be mindful of the client's imperatives. 99% of the times, clients see the difference between business value and CYA. But some cultures are necessarily CYA cultures. In those cultures, you can only help the client by perpetuating the CYA culture. Do that. 

And most importantly, NEVER disrespect the client - neither in public with your team, nor in private in your head. A Lot of delivery managers and PMs get together to laugh at clients in private. The client does not know tech as well as you do, and you don't know business as well as they do. Further, respect cannot be faked. Come from a place of real understanding, and you will create synergy. Come from a place of negotiation, and you will create a tug of war. I am still in touch with client PMs who worked with me 15 years ago, and more. 

Managing Reports 

Report requirements are the biggest headache for most PMs. The client wants to extract every element of data being put (or not put) into the system in about 15 reports on average (that's a joke, not a statistic). 

So, how does one tame the report monster? 

There are, once again, 2 simple questions that one asks the client. 

Since I have dealt with dashboard design and report management in another post, will just quickly state the 2 questions here: 

A. Who will enter this data? 

Request the client to go through their entire data flow process (you can use a proprietary methodology I have listed elsewhere on this blog - the Data River Diagram) and have them understand how the data will flow into the system in the first place. 

Is there enough reliability of that data for us to use it in reporting? 

B. What decision will it aid / How will you use it? 

Every pixel on an executive dashboard is important. Every second of executive time is important. If a data element is making it to reporting, it must help the user do one of the following: 

A. Monitor and control 

B. Diagnose and Correct 

C. Predict and Decide 

If the report is not fulfilling one of these 3 objectives, it should not be there. 

Your clients will truly appreciate your trying to create reports and dashboards that are relevant for the long term. 

In fact, invest some time in creating a report library that you know helps other organisations create effective dashboard and reporting interfaces, then proactively share it with clients. Will significantly shorten the cycle time and will also help the client see value in your work. 

So, are there any best practices that have helped you deliver better business value to your clients? Do share! 

How do we address the Knowledge Vertex?

 We talk about 21st Century Skills and 21st Century Attitude to work. The third part of that triangle is 21st Century Knowledge.

The importance of that hit while reading Priyanka Singh's edition this morning. It explains cryptocurrency in a phenomenal, easy way. But while reading the edition, I realised that the Knowledge vertex of the Attitude - Skills - Knowledge triangle is missing in our lives.

This Digital First generation is being taught by us - an analog first generation. The millennials are making an amazing new dynamic world, but who is teaching that to their peers and juniors?

Many children in the world don't know about GPT-3, yet they cannot be expected to not know as they enter the job market - IT or not. Because 'citizen developers' are now also expected to develop apps.

Not just that, many of us in the older generation HAVE to learn and keep ourselves updated, just to stay relevant.

I really believe that addressing the Knowledge Vertex will not just create more aware citizens, but also more conscious ones. Its not about content on the internet like leaves in a grocery market. Its about creating channels where the right information reaches the right recipient in a format that works for them.

How do we solve for that?

#ThoughtsforTomorrow

How to write a feature / news for The Children's Post of India

If you want to write news or features for The Children's Post, this feature is for you. 

Step1: Read and Understand 

Read at least 8-10 different sources before you start to write. Note down the key figures. Make sure you cross check ALL the key figures that you are going to present and also save the source of each key figure. For instance, if you are reporting a figure on women and their welfare, the only authorised figures are the ministry of women and child development, govt of India. 

Understand all the key terms. Don't assume the meaning of ANYTHING. Read, read, read and understand. 

Step 2: Readiness check 

In your mind, explain the concept to an 8 year old child. If you have a neighbour or a sibling, nothing like it. Otherwise, practise in your own mind, or with friends or parents. Make sure you talk to someone who does NOT know the topic before hand. 

If you are able to explain the topic to them and answer their questions, you are now ready to write a feature on your own. 

Step 3: Write 

Different writers have different techniques. Some just sit down and start writing/typing and get it all together. Some first prefer to structure their content, figuring out how it will flow and the word limit for each section. Then, they write the main points under each section, and then they start writing. Most of u s are somewhere in between. In general, it helps to start with 100% planning and slowly internalise it so it becomes automatic in your head. Its just like driving. When we first start driving, we do Brake-Cluch-Neutral like a checklist. But after a few months, we just do all this the minute we sit in the car. 

Step 4: Illustrate 

Find CC0 images or your own original images. Even if you are using CC0 images, pls give credit where you know the name of the photographer. Sometimes, you can do Steps 3 and 4 together. Sometimes, you can even start with a vital illustration and write the story around or based on that. 

Step 5: Put it together. 

Visualise your story - both in the paper and on the website. How will it look? Where will the image come? What should the background colour be? Combine the text and images and create a full story. 

Step 6: Check 

First, read it as a third person. Does the story hold your interest, or do you lose interest after a few lines? Is there a coherent story, or does it jump from point to point? How does the story make you feel? Do you put it down with a smile or a sense of wonder? Well done, then! 

Sometimes, we pick up some phrases from the internet unintentionally, or because they just say it better. Even Helen Keller was accused of stealing a story once! To ensure that this does not happen to you, take some of the interesting figures of speech, clauses, phrases etc. that you have used and google them or use a plagiarism checker. If there is a match, change that part. 

DO NOT depend on Grammarly or any other grammar check software. The idea of writing for TCP is to help improve your vocabulary and grammar. Read books by S Upendran and GMAT guides. The idea is to help you write flawlessly. Further, these apps are not as accurate as they need to be for TCP. 

Step 7: Review 

Have someone else read your submission. Ask them to check for grammar, facts, correct usage of words, structure, and interest - everything! 

If all is well, send it to us. 

We LOVE hearing from you. 

Important Tips For You 

• DO NOT expect perfection from yourself. 

            Not the first time, and not the hundredth time. And not the thousandth time. We will all make                 mistakes, we will all learn. 

• Originality before excellence

            Please remember - we really don't want the wittiest thing, or the best thing. We want YOU.                     Write in your own original voice. No one else can do that. 

• We are strict about copying or not giving credit 

            Like, crazy strict. We will stop publishing anything by you after the third strike. And if there is a             strike, we will not publish anything by you for a month. Same thing for avoiding credit or taking             images from other publications or from people without taking their express written permission. 

All the Best! 

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?

 

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. 

We don't fix "the system" , we fix the person

If you have grown up with modern management theory, you are probably obsessed with "systems" - those magical things that ensure everyone has the same experience with an organisation.

Travel Management systems ensure that everyone travels according to their eligibility (read: Their place in the pecking order). Requisition systems ensure that everyone at the same level has similar access to corporate resources, and so on.

What happens when a person plays the system? Immediately, additional safeguards are put into place to ensure that the said breach does not happen again.

Iterations of this ensure that the system becomes progressively more rigid, harder to use, and so on. Until, of course, the system becomes a data entry mechanism and things continue pretty much the way they do on the ground.



Many Western employers find this exception seeking behaviour of Indian employees quite frustrating. It is as if we were born with a more than healthy disdain for following rules.



How do Indians manage uniform access and systems approach? 

We don't. For us, each individual is unique. One's access to resources is determined by their personal equity. Not by their place in the pecking order.

The Indian business system inherently recognises the power-authority equation, and combines both when determining the access level of an individual. Unlike the systems based approach, where only authority is recognised and power, though acknowledged, is not official recognised.

What happens when a person plays the system? 

In the Indian system, we don't fix the system. We fix the person. The person is called in to understand what happened, and why. After that, a suitable retribution is awarded, either publicly or privately, but such that everyone knows what happens to those who try to play the system.
And thus, everyone knows what to not do in an organisation.

Because the talent pool was limited and closely knit, what happened to one employee made it to the grapevine quickly enough. It acted as a deterrent. There was no need to "idiot proof" the system. We "tampering-proofed" individuals.

And that, I think, is a diametrically opposite view to correction management than the "Make our systems tighter" approach.

So, dear Indians and Westerners who wonder why Indians don't follow rules, please understand that our traditional systems give us privilege based on our power + authority. We inherently don't understand this One-Size-Fits-All method. This is also true of most high context cultures, where collectivism is so high that it is possible to easily bring errant individuals to compliance. Where each individual is under the spotlight so that the overall pattern appears perfect.

Your thoughts?