Let me begin by illustrating how change can come rapidly to even the most mature systems.
At Twiga, one of the Tech team’s critical areas of responsibilities is the DMS. This system is an internal propriety system that helps us manage each and every aspect of the value chain.
For a very long time, the business has been focused on Fresh Foods and Vegetables (FFV). For the system, it meant we could use Kilograms (Kgs) as the Stock Keeping Unit (SKU). The idea was, you buy from the farmer in Kgs, you store and ripen in Kgs and finally sell in, you guessed it! Kgs.
The concept of Kgs as a standard unit of measurement worked so well for so many years, you could see the signs of the idea in virtually every report.
Well recently, the business decided to add Fast Moving Consumer Goods (FMCGs) to its offering. FMCG include the likes of Flour, Cooking Oil, Sweets, etc.
The problem with FMCGs is, of course, the concept of Kgs doesn’t map very well. How many Kgs is a packet of sweets for example? Does anybody buy their tea leaves in Kgs?
So we now have an interesting situation, flour would be bought in bales, stored in pallets and sold in packets.
As you can imagine, there was a lot of pressure to bring the system up to speed. Every day we were not selling was a day the company lost revenue.
Eventually we did solve the problem and adapted the system. The key takeaway here is you should anticipate change not just in requirements, but in concepts the business is built on top of.
Here I will point out some of the tips you can use to manage significant changes better.
See requirements gathering as a continuous negotiation.
Tech teams have a reputation of being inflexible. Who can blame us, we are good at delivering on what we promised and its hard to understand why others see it fit to change their minds on a whim.
Yet to go past “meets requirements” to “exceedingly valuable,” we must see tech, not as an external party who checks of items in a scope document, but as an integral partner who shapes the work to be done.
If you do take on this mindset, you don’t wait for the client to simply tell you what they want, you dig deeper and see the problematic situations they face. You try to understand how they came up with their requirements and then see if you can help them refine it so that it better solves their problems.
In this process, you must understand you are dealing with a human being not a machine, some of their needs they may not be able to express. Remember, you are the one with the years of technical training and experience. Still, they must feel respected and listened to, they probably have even more expertise in a different line of work.
In all this, remember to treat your client as a colleague and maybe even a friend. This relationship is what will keep things going in the tough times.
Give the pessimistic date
“All Models Are Wrong, Some Are Useful”
George E. Box
Standard industry knowledge states you should give a range of dates for delivery. For example, we will get this done sometime between 10th Sept and 1st Oct. That’s some good advice if people were able to grasp what you mean entirely. In my experience, what happens is they tend to forget the later date and then push you for not meeting the more aggressive deadline!
Certainty, even when dead wrong is incredibly valued in business settings.
I think a better way is to just give the pessimistic date. This works even better if you already plan your work in sprints. Then you can say this is planned for 4 sprints from now.
A useful rule of thumb would be to plan your work as usual but allow a full day for the team to work on changes every 10-day working period.
The confidence trap
For most teams, especially internal teams. The person giving instructions occupies a higher position in the totem pole. For the most part, it means when they look into their past, all they see is their success and how they have been right while others were wrong.
There is nothing wrong with this mindset, confidence is another highly valued trait for business leaders. Unfortunately, what it means for you is they will likely have a solid sense of what they want to achieve and will actively resist being persuaded otherwise. They will tell you what they want, how they want it done and how long it should take. Conveniently forgetting their expertise doesn’t neatly translate into tech.
For this kind of situation, there really is no clear answer. The best thing to do is to massage the client’s ego as much as possible while actively involving them in the development process. You will come to find there is a lot of value in engaging a committed and smart professional in your thinking.
How do you handle large changes in your own organization? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex
