There is never enough time to build the solution the customer thinks they want #HoskWisdom
Don’t ask a developer if a requirement needs code. Don’t ask users what enhancements they would like and don’t ask a barber if you need a haircut.
A developer told me he worked on a project that delivered on time and the customer loved it. I have worked on many projects and few delivered on time (obviously not my fault :-)), so I was curious to learn more.
On this project they kept telling the users they couldn’t have what they asked for and they were just getting out of the box. The team mantra was.
“You get whatever out of the box can do and no more”
The outcome of this stance (supported by the leadership of the customer).
- User stories were straightforward and didn’t need lots of rewriting.
- Development was mostly configuration with some no code customisations.
- Testing went through with few bugs.
- The project delivered on time and on budget.
The user got the system and loved it. After using it for a month, they came back with a few improvements and enhancements. This project was a Field Service project, but I saw a portal project delivered in 3 months from start to go live which used a similar approach.
Imagine the time saved by sticking to and trying the out of the box solution before suggesting enhancements. It seems obvious, but the common problem on projects is scope growing, expanding the complexity of the solution and testing.
This compounds the usually optimistic estimates of a project and reduces the time you have to test and fix bugs. Problems found at the later stage of a project are deadly because there is no time to reduce scope and then go live gets pushed back.
The order of customisations
The general order of creating customisations is
- Out of the box.
- No code customisation (workflow, Power Automate)
- More powerful no code — (Logic app, PowerApps)
- Code (Plugins, Azure Function)
The reason for starting with out of the box because of the cost of maintenance. Every customisation you create has to be maintained, tested, debugged, deployed, upgraded and understood from that point of creation. Code allows you to create more complex customisations but has a higher maintenance cost and fewer resources can do that.
The benefit of using out of the box is Microsoft takes the burden of testing, upgrading and maintaining.
Charlie Munger often says that “to a man with a hammer, everything looks like a nail.”
To someone who can write code, all problems can look like a plugin, many Dynamics developers enjoy writing code more than creating no code solutions. To reduce the complexity and maintenance of your solution, stick as close to out of the box as you can.
Users and wishlists
I have seen examples of users coming up with growing list of requirements that would be nice to have and might make their jobs easier. It’s easy to capture a requirement but then it must be created, tested and moved through all the environments until you get to production, where its then supported.
Every requirement comes at a cost and the most significant is time.
The more requirements you add, the more time to deliver and the more complex the solution becomes. The more customisations which are linked the greater the complexity in understanding the solution.
Find what customisations they need, build those and let the users test the system. This delivers functionality into production and not wasting time on functionality not required. After using the system the users can highlight the pain points and areas where the new system would benefit from enhancements.
You create customisations where you need them, not where the users think they need them. For every requirement, question if it’s really needed? Show the out of the box solution and get users to test it. It’s difficult to push back on requirements but every requirement you add the more likely the project will not be on time.
- Question every requirement, take only what’s needed.
- Show out of the box solutions and persuade them to try them.
- Code should the last choice.
- Persuade users to test the solution before enhancing it.
The fewer customisations and code you create, the quicker you will get through testing and deliver to production. Get feedback from users to find out where they really need to enhance the system through them using it.
Most users don’t know what they want, until you show them what they asked for and they know it’s not that. So ask them to try out of the box and then know what they want.
Everyone on a project wants it to be successful and on time, be focused and disciplined.