There’s a lot of talk right now about a video featuring Elon Musk and his five-rules for successful product engineering. In the video, he talks about the ways he has found to improve any new requirement for his SpaceX rockets, and how his team makes sure they only build things they really need to. You can watch that video to get all the details (and a few great behind the scenes stories as well), but his five rules can be summarized as follows:
- Make the requirements less dumb.
- Try to delete the part or the process.
- Simplify or optimize the part or the process.
- Accelerate cycle time.
- Automate
In other words, have someone other than the requirement’s author look closely at it and have them vet the idea. Push the requirement’s owner to think through what the system would like without their part or new process. Remove it if it seems like we can get along without it. If we still think we need it, simplify it or optimize the idea until it’s the smallest, simplest, fastest representation of that thing it can be. Only once you’ve done all of this, should you then look for ways to work on creating the thing faster. Lastly, you can automate it.
By the way, he also mentions that at his companies, new ideas have to be tied to a person (by name), not just to a department. That way, anyone can go back to the original owner of the idea to confirm whether it’s still needed, and whether the solution they come up with makes sense.
His point here, I think, is that we often times start from a later stage in that thinking and jump to optimizing and automating processes before we’ve completeted those critical first steps. For instance, it’s much better for the team as a whole to remove the idea entirely in step #2, than to spend any time optimizing or automating a process which isn’t absolutely needed.
When we help a client implement NetSuite, we often go through a process that flows something like this:
- We’re talking to the client about something we need to work on together.
- They mention something new that they want to see happen in NetSuite.
- The consultants start talking about how they might meet the requirement.
- They start thinking about whether they should create a SuiteFlow or maybe a SuiteScript.
But this is wrong, as Elon’s rules should make clear. We need to focus much more on the requirement first. Talk to the client about why they think they need it. Ask questions about how often this situation occurs now, in their current ERP system. Many times, a client might make it sound like the answer is “frequently” but with a little pressure, you might learn that it’s only ever happened once or twice in the past. Clients who learn how powerful NetSuite’s automations are tend to start looking for things they can automate, without being disciplined about whether an automation is really needed.
A better approach would be something like this:
-
We’re talking to the client about something we need to work on together.
-
They mention something new that they want to see happen in NetSuite.
-
The consultants ask questions:
- First, to make sure they understand the client’s intention in bringing up the requirement. (Many times I’ve heard a client throw out an idea, and a consultant start adressing it as a real requirement, but the client didn’t really mean it as such)
- Then to find out how often this happens in the current business / ERP system.
- Lastly, how they handle the situation today. (Many times, you’ll learn they fix the problem manually and they’re actually OK with continuing to do so)
-
The consultants can then suggest manual steps the users could follow to handle this situation, including any steps they would take within NetSuite.
-
The consultants walk the users through that manual process, showing them how it would be done first-hand in NetSuite.
-
The users are tasked with thinking about the manual process and deciding whether they could live with it or not.
Only if the users say they cannot perform the manual process every time this situation arises should we move on to looking for some other way to meet their new requirement. Of course, if the answer to the “how often” question was 50 times per month, that’s a lot and we should quickly move on from a fully manual process to something more automated. We should always stay open, however, to the idea that part of the process might be manual and the rest automated. We don’t have to jump from 100% manual to 100% automated every time a client raises a new requirement.
If NetSuite consultants follow this process, we can get our clients live faster and with fewer complexities which might cause them issues in the long run. Just remember the most important skills a consultant should have are listening to what your clients are really saying, and knowing the right questions to ask in any situation.
How do you handle requirement gathering with your clients? Let me know if you have any ideas or tips to share with the NetSuite community and I’ll post them here as updates. Use the contact page to get in touch.
(Credit for the image used here goes to Frankie Lopez at Unsplash. Thanks!)