In the age of digital transformation rapid implementation of business cases is key to success. The fastest one is very often the winner. Unfortunately for most entrepreneurs and managers there is a limiting factor, which is called the budget.
So even in an agile world where requirements are frequently changed and the technical implementation is adapted to a quickly changing business realities, the most important question managers ask their product owners: “How much will it cost?”
A good business decision can be made only when you know how much a solution costs.
The standard answer of your technical team will probably be “Give me the requirements”, and after a long and costly two-weeks estimation session you are back to the classical waterfall approach. Unfortunately, less than a third of IT projects were completed on time and on budget during the last year. According to McKinsey study done in collaboration with the University of Oxford, over half of IT projects exceed budget on average by 45%.
At K&C we are faced with many such requests both from established big companies and start-ups who have a clear vision but unclear requirements. And of course both the timeline and the budget are limited. But any business decision needs to take costs into account, as well as estimated time for implementation and the overall risks of the IT project.
Fortunately most IT projects are not that creative as many IT experts think. When done properly, it looks more like handcraft. Using proven methods you have some certainty how to implement a feature and how much effort it will take.
So we have developed an integrated sales and project management process. We call this process “Controlled Agile”.
It allows to quickly give answers to the business while staying agile. For example, we received a request a couple of weeks ago. For anonymity reasons let’s call him Bastian. He is working in the engineering business selling very specific supply items. His idea is to set up a marketplace where this items can be presented by dealers.
His previous experiences with software vendors were very mixed. For example, he had a great idea for an app. He preferred to have a fixed price, as he had to use his private money and this was more than limited. He came in contact with one vendor who offered him a very tempting price. Time goes by as he finally got to see the app. But it was a disappointment. The whole app just did not make any sense from the customer perspective. One of excuses was “You didn’t tell us you need a password reminder function”. And this so called change request (CR) will cost another three days. And so on.
Next time Bastian wanted to try the agile approach. In the agile approach the budget is not known in the beginning, as requirements were adapted to the learning curve of the project. So they agreed on sprints and daily calls to discuss the progress. And again times goes by. And eventually budget was exceeded so much that he had to abandon the project.
So Bastian was pretty sceptical when we explained him our “Controlled Agile” approach.
Any investment decision needs to based on time and effort required for implementation.
The starting point is: Bastian knows the market, he knows how much money can be made, how much to spend for marketing etc. But he doesn’t know how much will it cost to implement? Will his own savings be enough? Does he need an investor? How long would it take to implement? When is the break even?
In addition to that the IT product owner needs to understand what is more important: the fast entry to the market with a small number of users or can a peak of users be expected from the very beginning. Do we show the solution to users among family and friends, or do we go directly to the entire market?
Implementation strategy is an important part of any business plan, and in the age of Digital Transformation this means that very often the IT implementation and infrastructure strategy are combined.
For any mission-critical project, no matter if approached by a startup or an established player, the understanding of the cost, required resources and time planning is a essential for decision-making.
In order to find the right implementation strategy and outline the proper solid foundation for implementation we need to understand the direction the business wants to go into.
In a workshop session we will ask all stakeholders about their vision and which problems of their customers they are going to solve. By taking this customer centric approach we make sure that only MVP (Minimum Viable Product) relevant features are implemented to avoid unnecessary investments.
The solid basis for implementation can be prepared by understanding the vision and the business case.
These high level features are leading very often directly to bunch of standard features, or epics. For example, user login requires a standard set of features for a proper GDPR conformity implementation. Fortunately, we always maintain our best practises so we know very often from the start which features are required for a fully working application.
Most business users have difficulties with that. It’s the same when you buy a car. The customer will probably tell you the colour and size of the engine but will very likely forget to tell you that he also needs a key. Too often IT companies tend not help their customers in defining a whole meaningful business package.
Based on these experiences we prepare the wireframes with our customers to define the whole application. This is important to ensure a high customer experience.
Customer experience is more than user experience. While user experience just shows that the feature is fun and easy to use, the right customer experience leads to some actions which are good for the business, like pressing the “Buy” button.
For Bastian it was very simple at the beginning: “Build me a marketplace.” We discussed that this means a GDPR conformity implementation of the user authentication, a payment provider integration with a KYC functionality (“Know your customer”) and a responsive design. With his specific knowledge about his customers we were able to design a very efficient process so that customers could find their required products with just a few clicks. And this will later give him advantage against the competitors on the market.
Bastian looks satisfied about his future application, but still he is urging us: “How much ?”
“Just a couple of more thoughts we have to do”, we were answering.
Business users think in values for their customers. With best practices a MVP can be designed to ensure high customer experiences.
As we use best practices for feature definition, we can also rely on best practices for the architectural design.
Every business is unique but the technical basis is very often similar. From the business perspective it makes a big difference if we implement a marketplace for selling legal consultancy services or for virtual computer game goods. On the technical side both projects are very similar.
Fortunately, in most cases those applications can be implemented using architectural patterns which are based on best practices. A search is still a search, no matter if it is on a marketplace, online store or a collaboration tool. Same goes for forms, tables, menus and other items. They might have different complexity, though. A form in a marketplace might include galleries, videos and more, while other forms can be simply text-based.
At K&C we have established a knowledge base repository which documents our architectural best practices. In a technical workshop session we map the requested epics to these patterns by asking the right questions.
For some applications a simple CMS optimized for high performance and optimized for SEO is most suitable. For other applications you might need a complex approval system for content creation.
In most cases we propose a “cloud-ready design” which allows the application to easily scale and deploy in any environment, either in-house or external.
Bastian has quite ambitious goals. He knows that application these days must be available 24/7 available covering any peaks in demand. So we agree to start with external cloud solution.
The business case also defines the framework for the implementation. Is a simple solution enough or should it provide the foundation for future enhancements ?
By understanding which technological components we are going to use as well as our experience from previous projects we can make the initial estimation. In our lesson learned knowledge database we also save all historical data of implementation efforts during previous projects and expert estimations.
We simply list the different implementation components like search, form, multimedia gallery needed and multiply it by their implementation effort.
Then we add the effort for supporting activities like devops, quality assurance and project management.
By doing this we can very quickly do an initial estimation -- typically in 30 minutes.
So Bastian understands that his application will cost in total €90K, but by removing features which are not needed for the MVP he can stay in his budget of €45K. He uses this information to ensure his investment and to convince investors. As some money is missing his grandma is happy to support him.
The project can start.
By referring to architectural implementation patterns the business features can be estimated in a short time frame. No time-consuming and costly investigations are required to estimate the budget. Typically these estimations have a risk of just +- 15%. The budget is known and business decisions can be made.
Now we start agile development spiced up with budget monitoring.
In addition to that, we are using iteration-based approach for faster delivery. At the beginning of each iteration we estimate user stories that have to be implemented. These estimates should be done by the team which did not make the initial estimation. This way, the team can feel free to judge the effort required.
As an extra bonus the management understands the view of the product owner and of the team. In case of big discrependancies the reason must be found and resolved.
In our example the product owner is surprised that the team estimates a feature requiring much more significant effort than in the original estimation. He understands that skills required for the payment implementation are missing. By adding a developer who had relevant expertise we could return to the original estimation.
By comparing initial estimations and estimations of refined user stories we can find valuable insights. Here are some reasons that can cause big discrepancies: frequent change of requirements resulting in new skills needed and possibly lacking in the team, choice of architecture, or it is has been over-architectured.
The comparison between the original estimation and the actual effort should become a regular habit after each sprint. Instead of artificial story points which are difficult to understand for business we check the real effort spent in man days and the costs per hour which normally is a good indicator of the skill level of the team.
Bastian is surprised that the spent effort became higher than the expected budget. By making an analysis we understand that not all features needed for the MVP have been identified.
We are not flying in the dark anymore but understand if we are still on track.
This allows to understand when and for which cost the project is going to be completed.
Bastian is happy that he has full understanding of the progress of the project and what the costs will be. He prioritizes the features so he will stay within the budget. He has all numbers needed which he can show to his investors and to his grandma.
The product can go live.