In the age of digital transformation rapid implementation of In the age of web development and digital transformation, rapid implementation of business cases is the key to success. The fastest to market often has a huge advantage. Unfortunately for most entrepreneurs and managers, this pressing priority has to be achieved within the often tight constraints of a finite budget. If the preference is to work with a web development team based in Munich or Germany that can put additional pressure on budget.
As one of Munich and even Germany’s most experienced web development agencies (we were founded back in 1999) Krusche & Company has been helping our partners navigate the past the potential mistakes and inefficiencies that many less fortunate companies encounter when managing digital transformation and new web development projects that involve an agile software development team. With Munich-based management but a nearshored agile development team, we are lucky enough to be able to offer companies a hugely experienced, German-engineered solution to web development needs while staying budget-friendly.
As you can imagine, that killer combo means we have built up a huge experience resource while helping companies avoid the time and budget pitfalls organisations so often fallen into with an outsourced agile software development team. I’d like to impart a little of that experience here in the hope that it might help you clearly define and avoid the most common mistakes made with web development projects.
How should you, as an IT project manager or product owner, define your web development requirements and make an informed choice of agile development team partner, whether in Munich, Germany or anywhere else?
In an agile world where web development project requirements are frequently changed as business realities evolve, technical implementation must be equally quickly adapted. Despite these conditions for success in the contemporary dynamic digital business environment, managers invariably press their product owners with the dreaded question of “how much will it cost?”
Understanding the cost of any web development solution, even built to the agile philosophy of requirements evolving as the market dictates, is of course integral to being able to take good business decisions.
When you request a web development solution of a technical team, whether inhouse or an external partner, you can expect to be met with the simple response of “give me the requirements”. The typical mistake here is that after a long and costly two-week estimation session you are back to the rigid, pre-agile waterfall approach.
Depressingly, less than a third of IT projects were completed on time and on budget during the last year. According to a McKinsey study in collaboration with the University of Oxford, over half of web development projects, built according to the agile project management philosophy or otherwise, exceed budget. And not by a little. The average is by an eye-watering 45%. That’s the AVERAGE! Which means a significant chunk of web development projects come in a way over 45% beyond budget.
At K&C, we deal with requests from a huge variety of companies on a daily basis. From big established enterprises with thousands of employees to seed funded start-ups and everything you could possible imagine in-between. They usually have a clear vision for what they want a web development project to achieve but unclear requirements. And of course, both the deadline and budget are typically tighter than my first pair of lederhosen would be on me today! But any business decision needs to take costs into account, as well as estimated time to implementation and the overall risks of the web development project.
Fortunately, most web development projects are not as creative or ground breaking as the IT experts behind them often think. When done properly, web development looks more like traditional crafts that rely on experience and skill to spot and execute unique combinations of the same old well-practised techniques. By following proven methods, we know with some certainty how to implement a feature and how much effort it will take.
On that basis, we have developed an integrated sales and project management process that our agile software development team follows. We call this process “Controlled Agile”.
It allows for the return of quick answers to the organisation that is our client, while staying agile. For example, we received a request a couple of weeks ago for a web development project. Let’s give our client the pseudonym Bastian. We stick to strict GDPR-compliant principles too, both when it comes to agile web development and storytelling to communicate a message!
Bastian is in the engineering sector and sells very specific supply chain items. He wants to set up a digital marketplace where these items can be showcased by dealers. Similar to an AliExpress but for engineering supplies most of us have never heard of!
So let’s see how we approach Bastian’s web development project in a way which makes sure he neither overshoots his deadline or budget. As manager of a web development project, this will provide you with a strong framework against which to make an informed judgement of how likely your chosen agile software development team are to deliver your project to your expectations.
Throughout the course of our intro chat (it turns out Bastian’s a lovely guy and very communicative) he reveals that his previous experiences with vendors of agile web development teams have been mixed to say the least. For example, he had a great idea for an app. Bastian’s appears to be quite the entrepreneur! His preference was for a fixed price to be given as he was investing his own private resources and admitted to an unhealthy addiction to food and shelter that he was unwilling to compromise. You see the kind of unreasonable clients we have to deal with here!?
He was communicating with one vendor who offered him a particularly tempting fixed price web to build the app according to the requirements he had outlined. Done deal! Unfortunately, when the completed app was finally presented to him, it was, you’ve probably already guessed, a bit of a disappointment.
The completed app just did not make any sense from the customer perspective. One of responses to Bastian’s criticisms was “You didn’t tell us you need a password reminder function”. The change request (CR) will cost another three days. You get the idea.
Well, what would you expect if someone offered to paint you a picture for $5…? Don’t expect the economics that shape the market for the cost of web development to work to a different set of rules to the rest of the world. No one sensible chooses the cheapest tattoo artist available when they decide they want to permanently design their own body. And yet, inexplicably, too many otherwise intelligent business and IT managers somehow think that things will work out differently when hiring a software development team. Despite the fact that a bad decision could end up costing their organisation a fortune in both rectifying the mistake and opportunity cost through the delay in being able to go to market.
Bastian thought he’d learned his lesson. Next time he decided he would hire an agile software development team. He’d done his research and learned about the advantages of the agile approach and building a web development project in stages, starting with an MVP that can quickly be deployed and then refined based on user experience and an evolving market.
In the agile approach the budget is not fully defined at the beginning, as requirements are adapted throughout the learning curve of the web development project. So Bastian and his web developer (not K&C), this time based in Munich, Germany, agreed on sprints and daily calls to discuss the progress. And again times goes by. Eventually, his budget was exceeded to such an extent that he had to abandon the project.
By now Bastian, having learned from his previous mistakes and an open minded guy, was still convinced he would find the right agile software development team but was already a little sceptical by the time we explained our “Controlled Agile” approach to him. Especially as he had secured some funding for his new, bigger idea ‑ the digital marketplace for specialist engineering supplies. He had a responsibility to his investors to get his choice of web development partner right this time.
Any investment decision needs to be based on time and effort required for implementation.
Any business plan needs a starting point and that should be defining the variables you know with relative certainty. Bastian’s starting point was that he knows the market for the engineering supply products he wants to sell, he knows how much money is on the table in this sector and that securing even a tiny fraction of that makes for a watertight business case. He also has enough industry and digital marketing experience to have a very educated guess at what his cost per client acquisition and average sales value are likely to be.
What he doesn’t know is how much it will cost to build the digital marketplace according to the requirements he has. Will his own contribution combined with his seed investment be enough? How long will it take the agile software development team to build out the project as per his initial requirements?
In addition, any digital product owner needs to understand what is more important: rapid entry to the market and a small number of users or can a significant volume of users be expected from the very beginning? Do we show the product to family and friends for feedback, or do we go directly to the entire market and get its feedback?
Implementation strategy is a key part of any business plan, and in the age of Digital Transformation this means that often web development implementation and infrastructure strategy are combined.
For any mission-critical project, regardless of if it is for a start-up or an established industry player, understanding of the cost, required resources and time planning are essential to the decision-making process.
In order to find the right implementation strategy and prepare a solid foundation for implementation our agile software development team needs to understand the direction the business wants to go in.
This is achieved through a workshop session where we will ask all stakeholders to describe their vision for the final product and what end user problems or inefficiencies they are going to solve. By taking this customer or user centric approach we make sure that only MVP (Minimum Viable Product) relevant features are implemented in the first iteration to avoid any unnecessary investment in web development that might subsequently have to be re-done if the market dictates a different approach to meeting the user needs is, in fact, necessary.
A solid foundation for implementation can be built by understanding the vision and the business case.
‘High level’ web development features can often lead directly to the requirement for a raft of more standard features, or epics. For example, user login requires a standard set of features for proper GDPR conformity implementation. Fortunately, our agile web development team is experienced and able to immediately build out a clear picture of standard features required around more unique specialist features. In most cases we will already have these features coded, having used them in other projects, and are able to copy/paste them in where required.
Businesses or organisations that lack extensive experience in building out web development products often fail to appreciate just how specific they have to be in their detailing of requirements. It’s our job to, within reason, fill in those gaps at the beginning. But whether from Munich, Germany or anywhere else in the worl, too many web development agencies take the approach of executing purely based on the requirements provided by the client.
Imagine if you went to buy a car and told the salesman the colour, engine size and other requirements you have. He recommends you a few models on that basis, tells you their price and you opt for the Volkswagen Passat. But it turns out a key isn’t included in the price quoted. “But you didn’t tell me you would need a key!” Too often web development companies that should be partners in the project fail to help their customers define a meaningful business package which will result in an end product fit for purpose.
Based on these experiences, our approach, and one you would be advised to demand from any agile software development team, is to first prepare wireframes with our customers. These wireframes define the whole application and a detailed set of the technical requirements that will be needed for a fully-functional end product that will meet our client’s needs. This is key to ensuring a high-end customer experience.
When helping our client define their requirements our agile software development team focus on customer experience. Customer experience is more than user experience. While the former just shows that the feature is fun and easy to use, customer experience places this within the framework of the product owner’s end goals. So a customer experience-centric web development process involves consideration of leading the user towards actions which are good for the business, like pressing the “Buy” button.
In Bastian’s mind, his requirements were very simple. When we met at our Munich office and had convinced him of the merits of our ‘controlled agile’ approach to web development, he delivered his requirements with a concise “Build me a marketplace.”
He was falling back into the habits that had cost him so dearly in the past. However, we weren’t about to let him get away with it this time! So, time to take the wireframe approach that has stood us and our clients in such good stead over the years!
We discussed that in the current environment of EU law, building a marketplace necessarily involves GDPR conformity implementation around user authentication and payment provider integration with strong KYC (“Know your customer”) functionality. And Google’s new focus on mobile means a responsive design is a must if Bastian hopes to rank his digital marketplace for relevant search terms.
However, harnessing his detailed understanding of his customers, we were able to design a very efficient process that meant his customers could find their required products with just a few clicks at most and often with one. This streamlined ‘one click’ ecommerce web development design will later give him a key advantage against any competitors on the market.
Bastian looks enthused about his future application’s prospects. But, as the saying goes ‘once bitten, twice shy’ and he urges us: “How much?”
At this point, we still have to resist putting a number on it, controlled agile or not. “We still need to define the specifications list your requirements will involve in more detail”, answers our agile software development team’s project lead.
Business users think in customer values. By sticking to best practice, an MVP can be designed to ensure a top customer experiences.
There is no point to sticking to best practice for the feature definition of a web development project without also taking the same approach to architectural design.
Every business is unique but the technical requirements for the web development projects they need are often very similar. On the face of it, there is a huge difference between a marketplace selling legal consultancy services and one for virtual computer game products. However, in terms of the list of technical specifications required, both projects are actually very similar.
Fortunately, in most cases this kind of web development application can be implemented using architectural patterns based on the same established best practice. A search is still a search, regardless if it is on a marketplace, online store or collaboration tool. The same goes for forms, tables, menus and other items. They might, however, have varying complexity. 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’s web development architecture to be created in a way which will easily scale and deploy in any environment, either in-house or external.
Bastian has quite ambitious goals. He knows that in the contemporary digital economy, his application must be available 24/7 and able to cope with any peaks in demand without crashing. So he agrees with our agile software development team that the web development requirements must involve an 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 enhancement?
By understanding which technological components we are going to build out in addition to those we already have from our work on previous projects, we can now make an accurate initial cost estimation for the web development work our team will have. In our ‘lesson learned knowledge database’ we save all historical data of implementation efforts during previous projects and expert estimations. That database means huge budget advantages for lucky K&C clients!
We simply list the different implementation components like search, form, multimedia gallery needed and detail the implementation effort and resource they require.
Then we add the resource that will be required for support activities like devops, quality assurance and project management.
By doing this we can very quickly arrive at an uncannily accurate initial estimation — typically within 30 minutes.
So Bastian understands that the web development work that will result in his full marketplace application will cost a total of €90K. But by removing features which are not essential to the MVP he can launch to market, he can keep within his budget of €45K.
The project can start.
By referring to architectural implementation patterns, business features can be estimated in a short time frame. No time-consuming and costly research is required to estimate the budget. Typically, these estimations have a variation risk of just +- 15%. The budget is defined and business decisions around web development projects can be made.
Now we embark upon agile software development with continuously integrated budget monitoring.
Additionally, our agile software development team employs an 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 made by a different team to that which made the initial estimation. In this way, there is a second opinion on the estimation of the resources required.
As an extra bonus, the management understands the view of the product owner and of the agile software development team. In the event of any major discrepancies, the reason for variation must be isolated and resolved. A little like an academic grading system for test papers!
In our example, the product owner is surprised that the team estimates a feature requiring significantly more effort than in the original estimation. The reason for the discrepancy turns out to be that the team lacks developers with significant experience in the skills required for the implementation of the chosen payment system. So the decision is made two swap in a developer from another K&C agile development team who has the relevant expertise. This means the original estimation can be kept.
By comparing initial estimations and estimations of refined user stories we can find valuable insights. Here are some factors that can cause major discrepancies: frequent change of requirements resulting in new skills needed and possibly lacking in the team, choice of architecture, or the web development project has been ‘over-architectured’.
Throughout the course of an agile web development project, regular lining up of the original estimate and the actual resources required to implement each element of the requirements should be a habit at the conclusion of each sprint. Instead of artificial ‘story points’ which are often difficult for the client to understand, we compare the real resource spent developer days and the costs per hour. These are a good indicator of the skill level of the team.
Bastian is surprised that the actual spend is beginning to outpace the expected budget. On further analysis we highlight that not all features needed for the MVP have been identified.
However, the positive is that we now have a very clear idea of what will be required over the rest of the project.
We now understand precisely when and at what cost the project is going to be completed.
Within a couple of short weeks, the product can go live! And that is the Krushe & Company agile approach to costing and executing web development projects large and small. And why we make sure our partners’ digital projects fall comfortably into the less than a third of those that become a reality inside both budget and deadline.