Last year I was working on an ERP solution for a manufacturing firm, covering non-production modules (typically sales centric ones like Product Configurator, Order Management and Pricing). At the very start of the project, I had extensive discussion with client about their business, what products they manufacture, how they receive orders, what process they follow from the time they receive orders to the time they ship products, how do they handle accounting, and so on. Soon we entered more detailed discussion about their products. I asked him to share photos and videos of their products, explain each and every parts and assemblies, what kind of options are available for various products, what goes on in their shop floors..... quite a few things that didn't apparently have any relevance with sales related functions.
The client patiently answered all my questions, sharing many documents, operating procedures, spreadsheets in the process. I prepared a context document consolidating everything about their product in quite detailed manner, full of pictures and illustrations. When I sent to him this 27-pager asking to review if everything is correct and complete, following discussion ensued -
What would you do with that document? Why don't we start talking about configurator module? It is the highest priority for us.
Well, all this information will be used to define the product configurator
You can find whatever information you need for configurator in the spreadsheet I shared with you.....
Sorry, let me interrupt you.... who maintains that spreadsheet?
The engineering department
How do they know which option goes with what product, which option is available, which is not available?
We train every engineer extensively when the join us, they just know it
But the configurator won't... it is a software, it is not human... I need to understand what knowledge the engineering department applies in maintaining the spreadsheet and translate it in software terms...
Ok, just walk me through the document... I can't read every line of it...
Fair enough... let's do that.
In a few weeks when we gave him a proof of concept for the configurator to review, rules-based and intelligent, following discussion ensued -
We never discussed the configurator...we have only discussed Order Management of late... how did you create this configurator?
Whatever we needed to create it was there in the context document for products that we reviewed earlier
Interesting...
Yeah....
What I am arriving at with this story is we frequently undermine the importance of understanding the context and the domain, more so documenting it. We tend to jump into project requirements without understanding the background, the domain, industry practices, organizational processes, organizational structure. We tend to think if we are developing only the Order Management module, why waste time understanding processes of all the departments. Even if you don't undermine this activity, your client, project managers and team members may feel you are wasting time.
So what could have happened if I didn't take the time to understand client's products in great detail?
Here is the requirements document for configurator... I have laid out the screens, validations, functionalities, business logic.. I just need some rules.. how the options depend on each other? Can you tell me what those rules are?
What rules?
Option X - is it available for all product variants?
No, it is not... check that spreadsheet, it has full list of which products have this option available
Yes, that is fine... but we need to figure out some patterns, it is difficult to do that from the spreadsheet, can you help with it
You can apply filters...we do that all the time whenever there are customer enquiries... that's how we do it
Ok, let me try that... it looks like this option is available whenever the option Y is available and the model is M or N
No that is not true... if you change the filters, you will see there are few products where Y is not available but X is...
I see...
What is going wrong here? Many things... I am running into loop. I will derive some sense from reverse engineering a spreadsheet, but after many long and frustrating iterations. I derive a rule, only to find later it is not entirely correct. So where would I end up - a thousand rules instead of a hundred - reverse engineered from a spreadsheet instead of identifying meaningful dependencies. Less accurate, difficult to maintain and a troubleshooting nightmare!
Apart from not undermining the importance of context analysis, what else did I do right? I asked client every detail of his product which he gladly explained with a sense of pride, instead of asking him to explain rules for product configuration which is difficult for him to correlate.
That is the power of Context - in this case it helped me create a simple and logical solution, in other cases it can create different wonders! I didn't have to write requirement specification, the solution could be derived directly from a fairly detailed context document. I saved many hours in conducting knowledge transfer to team members.
Sure enough, the client never questioned me when I sent him context documents for other modules, but he did make me walk him through the document every time :)
I guess various people will have different opinions on this matter and hundreds of experiences to share! Please do share your comments.
