For good tech management, keeping a sharp eye on the dos and don’ts of handling software projects is essential. In over 30 years of involvement in tech projects and business, I have seen a lot of projects going well. But even more, going south. So, let’s review the typical risks to avoid and approaches to embrace in tech management.
When I did a postdoc information analysis in the 1980s, the core observation was that many IT projects failed miserably because of a complete lack of proper information analysis. Today, this observation is still as valid as ever.
Great information analysis requires a solid analysis of business requirements and continuous communication between the business, given its shifting needs and priorities, and the tech teams that produce solutions. Though the responsibility of good and constant requirement analysis is primarily a business responsibility, it needs embedding in the tech teams as well. Avoid situations where people point fingers and don’t take responsibility or claim sufficient ownership.
Great information analysis starts with understanding the business case and the derived business requirements. It continues with functional analysis, process and data flow insights, the development of a future-proof data model, user interface designs, and a technical architecture. All are to be discussed and proofed by the business owners before the work is started. Demos and prototypes can help to clarify functional and technical requirements.
New CTOs in startups or new tech management in corporates, like to “change everything” by developping their own “new system”. With dramatic big bang effects on the survival of respective startups or performance of respective organizations. Especially, SAP migrations are notorious for the big bang approach advised and followed. It means a key operational system is entirely replaced by a new system on a specific date. In the case of SAP, it’s typically about enterprise resource planning (ERP) systems, the beating heart of many commercial businesses. In the case of a global tech trader, this approach typically led to the loss of 30% of the revenues in the 12 months following a “successful” migration. Dramatic.
Why is this? Despite all requirement analysis, it always turns out that undocumented functionalities of the old system are overlooked. Missing these, often results in utter disaster. Warehouse management systems not being able to receive orders from the ERP system. Corrupted invoice processes. Just to name a few. It’s, of course, food for consultants. Because the moment the shit hits the fan, the management of the business panics. And consequently, there are no limits anymore to the budgets made available to resolve the shit. The disaster can be so big that it kills the victimized business or business line. This is, of course, a situation that management should try to avoid at all costs.
Although many external IT consultants will continue to say that a big bang is the only possible approach in case business systems are entangled, this is not true. Better replace big monolithic solutions in smaller steps by services or in even smaller steps by gradually migrating to a micro-services architecture (MSA). In the case of migrations of business-critical systems, the smaller the steps, the better it is. And, often faster and more efficient.
The core of the IT productivity paradox is that many investments in tech don’t lead to productivity gains as expected. Unsurprisingly, scholars have observed over and over that there is often no clear relationship between IT budgets and productivity gains. Still, there are many examples of successful applications, and tech businesses wouldn’t have been possible without proper investments and serious budgets.
Because of this paradox, it’s always good to start small in case of new ideas. A few developers can create a minimum viable product (MVP): an app, a product, a system, a service, or a site. One great developer can typically produce a better MVP than a big team of lower-level professionals. And faster as well. Therefore, selecting the right people for a project or tech business is critical. Utterly critical in the early stages, and still very important in going concern situations.
Many successful tech businesses have started with a shoestring budget. Using open-source frameworks, low-cost hosting options, and sourcing experienced freelancers from popular outsourcing countries. By focusing on an MVP, bringing it to live quickly, and doing iterations with short time intervals, great things can be realized in months rather than years. In this way, entrepreneurs and business owners quickly learn if there is a market fit for their ideas. The setup is still nimble enough to allow for pivots or abandoning the project to switch attention to other ideas.
Building a resilient business implies reducing dependencies. Dependencies on management, staff, suppliers, clients, countries, and the technologies used. Bad consultants will tell you to standardize on their platform. Or it is more efficient to outsource all IT jobs to a single provider. Or centralize everything in one tech department or platform. This monopolism creates a very dangerous dependency, which inevitably leads to laziness, abuse of power, inflexibility, and red tape situations that kill innovation and, eventually, put a business at risk.
For example, Amazon Cloud (AWS) was invented by an entirely separate team (from the Amazon core team) that focused on solving a fundamental tech flexibility issue. Everyone knows the success story. A good balance between core teams with more bureaucratic processes that run critical systems and other teams that focus on innovation is necessary. It is often the only way to secure the business’s future. In the same way, it is crucial not to work with just one external consultant, not just one hosting or cloud provider, and not just one tech stack. You need at least two legs to walk on. Only such an approach keeps the organization flexible. Speeds up the learning process and shortens the innovation cycle.
It’s tempting to hold on to redundant legacy code. Because it runs efficiently, it is a kind of tiresome cleaner’s job to phase it out. But, keeping all redundant legacy systems running, often with completely overlapping functionalities with newer systems, eventually leads to an efficiency nightmare. It will gradually tie all available tech resources to maintenance, leaving less and less room for desperately needed innovation. Boundlessly increasing tech budgets to keep everything running, plus building new platforms, is never a sustainable approach.
It’s important to properly plan and focus on phasing out redundant or obsolete legacy platforms. Not only with it free up IT resources. It will also stimulate innovation. The other systems and services in the ecosystem need upgrades to take over all functions of the old platform. As a rule of thumb, it is good tech management to allocate 30% of the tech budget to “maintenance”: phasing out or reworking old code.
Tech people are like ordinary people: they love and follow fashions. It can be about preferring Python over PhP or C# over JavaScript, or the other way around. Or about how cool it is to use Amazon Cloud (AWS) or Google Cloud, instead of more classic hosting providers. Sometimes it is good to follow a fashion. Because when developers dropped Perl for PhP, it became increasingly hard to still find Perl developers. But often it is risky to follow a fashion.
A developer might embrace a new development framework that is not mainstream yet, and risks to become a dead end over time. Another risk is that certain promoted tools or solutions are not fit for purpose for all required jobs. Developers tend to be a bit religious about the tools and environments they worked with or have created themselves. Cloud solutions can be sometimes 3-4 times more expensive than traditional hosting solutions and using these might effectively kill a business case. It is a job for management to critically balance risks, and to look at alternatives at every turn of the road. This can’t be fully delegated to tech staff given their inherent biases.
It is already long ago that waterfall methods were advocated for system development. Following multi-step procedures from requirement analysis to functional analysis and technical design to system development, led to projects with too long timelines. The major risk was that these projects fail because the initial requirements had changed at the time of delivery. Many other approaches tried to fix this, like rapid prototyping, agile, scrum, extreme development, lean development, dynamic system development, feature-driven, etc. Each of these have advantages or drawbacks.
Based on decades of system development experience, my conclusion is that it is important to be very pragmatic, and not religious about any development method. Try always to chop projects in small steps that lead to quick results: the creation of a minimal viable product or service, the update of a critical feature in an existing system, the development of a micro service replacing similar functionalities in multiple systems in an ecosystem, etc. Client or user documentation is important, sprint reports and sufficient inline documentation. But avoid too much overhead in documentation.
There are developers who intuitively create marvelous things. But there are tons of developers who produce nothing of value for a client or business if allowed to do whatever they like. If a business wants to succeed in meeting its objectives, it has to be in full control of its software development processes. Especially in case of critical infrastructure, it should never be left to a supplier or internal tech team to decide what product features or developments are prioritized over others.
Fully aligning business objectives with service road maps is critical. It helps to avoid wasting resources and unnecessary frustrations.
Quite often inexperienced tech management forgets to secure the full transfer of intellectual property rights (IPR) when hiring outsourcing companies, freelancers or their own staff. To avoid customer-lockins, IPR ownership is essential. It guarantees all the flexibility that you will need in the future: to insource and resource software development, to license or sub-license the code or services to third parties, or to sell the IPR separately. Especially, if you run a tech business, it is essential to own your code. For investors in such a tech business, IPR ownership is a critical due diligence item.
There was a time that hours and materials was the standard way to source scarce IT talent. These were the golden years of IT consultancy. Because of 60 to 80% of IT projects failing, projects taking twice as long with twice the number of support issues, IT budgets spiraled out of control. This led to the introduction of fixed time, fixed budget contracts, and in the last decade Software-As-A-Service (SaaS) and the rise of cloud services. To push risks back to IT suppliers or at least negotiate balanced risk contracts. The effect is that modern tech management has more tools to make IT budgets predictable and to flexibly scale costs down to restore profit margins.
Read further: News, Icecat, technology
Founder and CEO of Icecat NV. Investor. Ph.D.
Your email address will not be published. Required fields are marked *
Comment *
Name *
Email *
Website
Δ
