Introduction
Here are some scary statistics on Digital Transformation solutions. According to a Forbes article, it is estimated that about 70% of digital transformation solutions crash and burn! Among them are big names like GE, Ford, Lidl, Nike, etc.
A study by PricewaterhouseCoopers, found that only 2.5% of the companies successfully completed 100% of their projects. The sample size was 10,640 projects from 200 companies and in 30 countries and across various industries.
Well what about the 30% that does it right and the 2.5% that successfully completed their projects. What makes them different from the failed ones. Here are some indicators that can help you achieve Digital Transformation success for your organization, be it SME or a large corporation.
Here are five pointers we believe can help you steer away from a No-Code failure.
1. Quality vs Quantity
“We find comfort among those who agree with us - growth among those who don't.” ~ Frank A. Clark
Product owners and some No-Code developers fall for one’s own confirmation biases, likes and dislikes. Unless you are the key user that is going to spent the majority of time using the No-Code application, a product owner’s wishlist has to be backed by user feedback and/or insights from ground reality.
Many at times accomplishing a lot of features is comprehended as a NoCode project success while the quality of each feature, its user acceptance and frequency of its usage determines a software product's sustained success. Just as NoCode developers get trained in noCode platforms, product owners too should be trained on how to work efficiently in a NoCode project.
Trivia: When WhatsApp was acquired by Meta at 19 Billion USD, it only had 55 employees!
2. Right problem vs Wrong problem
“AI is the next big thing, we also want to include AI somewhere inside our new system”, this was one of the comments we heard last year from an organization’s decision maker.
Defining the right problem statements that you are solving with No-Code is very important. In our projects, we spent a good amount of time understanding the problem statements at hand and sometimes even helping the Client get clarity on their own problem statements.
Trying to answer “Why is it needed?” and “What does it solve?” questions is one of the techniques we use to converge to the right problem statements in our No-Code projects.
3. Shifting requirements vs Controlled scope
Does your product requirement keep changing as the No-Code development gets started? This is a sign that the ‘right problems’ are not yet defined before developing the solution.
If you feel that the problem statements are too fuzzy in the initial phase of development and cannot move forward without results, then select one or two problems statements. Keep the scope small, build & deploy functionalities in small iterations (5-10 days), collect user feedback and implement changes according to the user feedback. Once you are happy with the results, move to the next two problem statements at hand.
In case the requirements change even before the previous changes are deployed, it is a good idea to stop and reflect on the current list of problem statements.
Note: This is not the same as change in requirements after receiving user feedback.
4. Results vs Team size
Having a small, yet very dedicated team can make the difference of day and night in No-Code project deliverables. Unlike coding based development, a No-Code developer can switch between roles of a developer, an application architect or a business analyst.
An application development task that requires 5-10 dedicated team members in a full code scenario typically requires only one or two No-Code developers to build and implement the same application. If the same yardstick is used as an assurance for your No-Code project’s success, this simply ends up with a lot of additional expenses on resources.
5. Problem solvers vs Brand names
In many big ERP failure lists, there are famous ERP brands and service providers that frequently comes up. Many organizations look at the brands instead of their project implementation team. You cannot expect great results from an inexperienced team, no matter how big the brand is!
Make sure that your implementation team includes problem solvers rather than developers who simply say ‘Yes’ to all your requests.
Before moving into big commitments, do a small Proof of Concept or POC project with the actual implementation team for your project.
Brand names are helpful but remember that not so long ago those brand names too didn’t exist. Try to find the right problem solver teams rather than just brand names.
Related links:
Companies that failed Digital Transformation and what can we learn from them
Mission Failure at LIDL - But actually what was the mission?
How Nike rebounded from its ERP supply chain disaster
Real reasons why enterprise IT projects fail and how to fix it
LinkedIn post
