This 4-part series provides a useful primer on how to approach technology and manage its integration into a business, with the aim of avoiding unexpected costs and issues.
Consumption and Tech Debt
Consumption
Any development project you initiate will have to be ‘consumed’ – meaning that you’ll need to be able to incorporate the results of any project into your organisation.
You and your team need to be able to plan, implement, use, and evaluate the effectiveness of the project. Doing so will ensure that the investment of time and resources is worth it in terms of the return on investment.
Are you and your team prepared to embark on this project? Do you have the support, approval, and eagerness of all the necessary people? Even if it’s just yourself; have you thought through the desired outcomes?
Integrating the development project and the delivered site, app or system into a business requires anticipating scenarios that may include an influx of customers, potential impacts on customer service, or the time needed to manage the new system. Having contingency plans in place can help ensure successful integration.
Research from Gartner has consistently shown that a large majority of IT projects fail, with 75% failing in 2017, 87% of data science projects never making it into production in 2019, and only 20% of analytic insights delivering business outcomes by 2022.
Some initial considerations
- Outcome: Start with the desired outcome: What business objectives are you trying to achieve?
- Technical: Consider technical expertise: Do you have the necessary knowledge and resources to build the product, or do you need to outsource?
- Budget: Determine budget requirements: Based on your scope of work, how much money will be needed? Get multiple quotes for comparison. If you are in a startup, consider raising capital and seeking advice from experts.
- Functional: Identify all functional components: What steps must be taken in order to reach your desired outcome?
- Evaluate: Evaluate user experience: Is the product easy to use? Are there any potential issues that could arise during use?
- Future: Think about scalability: How easy is it to build upon this version of the product in the future?
Your development plan should take into account the return on investment from a business perspective, as well as architecture, design, development, code management, testing, documentation, infrastructure, people and process requirements. Additionally, it should factor in the cost of service and time associated with technical debt.
If you want to ensure success, start by reducing tech debt. This will help prevent potential issues from arising and ensure that everything goes according to plan.
Tech Debt
Understanding how to manage a project is a process of looking inward and considering the cost of decisions. By turning this focus outward, you and your team can decide when and where technical debt should be placed in a project.
Ward Cunningham, one of the 17 authors of the Agile Manifesto and creator of the Wiki, is credited with coining the concept of Technical Debt.
Tech Debt is an implied cost of taking shortcuts in the development process instead of investing the time and effort to create a more robust solution. It also refers to revisiting code and making improvements as usage and experience with the codebase increases.
“With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.” – Ward Cunningham
In that case, tech debt does not refer to debacles. They are simply debacles. Tech debt is a more considered and manageable concept as part of development.
Tech debt can lead to missed deadlines, cost overruns, or even project failure if it is not managed properly. As a project progresses, tech debt can accumulate and become more difficult to address. Consequently, the amount of work required to complete the project increases beyond what was initially planned for, leading to delays and potentially blowing out the budget.
This may include introducing new features to an existing codebase, shifting development team members, changing suppliers, resolving issues or patching security vulnerabilities.
By not addressing this tech debt, the delivery of features and functionality is hindered. This can lead to increased costs in terms of personnel and potential bugs that may be introduced. It can also result in inaccurate estimations which could give competitors an edge in taking over a product or brand’s niche. All of these factors could contribute to increased team stress.
Releasing code into the live environment can be a risky endeavour. If changes lead to unexpected outages or failures, it could result in financial losses, ill will and even legal repercussions.
Product managers or business owners may be aware of the consequences of carrying technical debt, even if they don’t refer to it as such. The issue is that they often underestimate the costs associated with taking on large amounts of tech debt – which could be a long-term financial burden or require a large amount of time and resources to pay off in the short-term.
Tech debt must be managed properly in order to avoid costly delays, cost overruns, or even project failure.
In the next article, we’ll explore different platform options and discuss when you might choose to incorporate them into your project – like picking the right tool for the job.