These are simply a decision that is or will be made at a crossroads. Whatever the decision, the roll back or change to a different option is expensive, difficult, time consuming. This may be a foundational decision that do not make any difference to a large number of stakeholders, or it may be a decision that is made by a stakeholder that forces the technical teams to go in a specific direction. Further, the realisation that this was the correct, or wrong decision will not be immediately apparent; it may take months, or even years before it is known.

How to Identify a potential ITD?

Questions to Identify a Potential ITD:

1. Does this decision also make a number of other decisions?
   • Will this choice dictate other decisions, such as:
     • Package Manager to Use: Will this lock us into a specific package management system (e.g., npm, pip, Maven, NuGet)?
     • Platform Dependency: Are we committing to a particular platform (e.g., AWS, Azure, Google Cloud)?
     • Development Tools: Will this decision constrain us to certain development environments or tools?
2. Will the deployment of this tool/system take considerable planning and training?
   • Complexity of Implementation: How complex is the deployment process? Will it require significant effort and resources to implement?
   • Training Needs: How much training will be needed for team members to effectively use this new tool/system?
   • Transition Period: Is there a transition period during which both old and new systems will need to coexist?
3. Long-Term Impact:
   • How long will the effects of this decision last? Will it shape the future direction of the project or organization for years to come?
   • What are the potential long-term benefits and risks associated with this decision?
4. Cost and Resources:
   • What is the financial cost of implementing this decision?
   • How much time and human resources will be required for implementation and maintenance?
5. Reversibility:
   • How difficult or costly would it be to reverse or change this decision if it proves to be incorrect?
   • Are there any lock-in clauses or dependencies that make switching to an alternative difficult?
6. Risk Management:
   • Mitigation Feasibility: Are the potential risks associated with this decision manageable? Are the mitigations practical, or are they infeasible and prohibitively expensive?
   • Impact Analysis: What are the potential negative consequences if this decision turns out to be wrong? How severe would these impacts be on the project or organization?
   • Contingency Planning: Is there a viable plan in place to address potential failures or issues arising from this decision?

Examples

Identity Access Management System:

• Made by the technical team.
• Deeply embedded into the system, making transitions expensive and complicated.
• Incorrect decisions can significantly constrain the system but usually remain transparent to end-users.

User, Tenancy, and Access Control Hierarchy:

• Made collaboratively by non-technical stakeholders and the technical team.
• Core to application access controls.
• Rework can be incredibly complex as it impacts multiple system areas.

Enterprise Resource Planner (ERP):

• Incorrect decisions can halt company operations, and transitions are even more costly.
• Involves most organisational stakeholders.
• Expensive and affects all aspects of the business.

Cloud Service Provider:

• Involves both technical and non-technical stakeholders.
• The choice of cloud service provider impacts scalability, performance, and cost-efficiency.
• Changing providers later can be challenging due to data transfer complexities, differing service architectures, and potential vendor lock-in.

Programming Language or Framework:

• Primarily a technical team decision.
• Determines the development speed, system performance, and future maintenance.
• Shifting to a different language or framework can require substantial redevelopment efforts, retraining of staff, and can introduce bugs or inconsistencies.

Database Management System (DBMS):

• Made by the technical team.
• The chosen DBMS affects data storage, retrieval, and overall performance of the system.
• Transitioning to a different DBMS can be costly and complex, involving data migration, potential downtime, and compatibility issues with existing applications

What is not an ITD?

But it is easy to get confused or bogged down and start to see everything as an ITD that needs to be risk managed and thought about in great detail. There are some examples of things that are no ITDs as the switching costs are incredibly low.

Questions to Identify Non-ITDs:

1. Does this decision primarily affect individual preferences or workflow?
   • Will this choice be mainly about personal or team preferences, such as:
     • Text Editor/IDE Selection: Is this about choosing a preferred text editor or integrated development environment?
     • Communication Tool: Is it a decision about using Slack vs. Microsoft Teams?
2. Will the deployment of this tool/system be relatively straightforward?
   • Ease of Implementation: Can this tool be deployed quickly and easily without extensive planning or resource allocation?
   • Minimal Training Requirements: Does this decision require little to no training for team members to adapt?
3. Short-Term Impact:
   • Is the impact of this decision likely to be limited in duration and scope?
   • Can it be easily adjusted or reversed if needed?
4. Cost and Resources:
   • Is the financial cost of implementing this decision relatively low?
   • Will it require minimal time and human resources for implementation and maintenance?
5. Reversibility:
   • How easy or inexpensive is it to change this decision if it proves to be incorrect?
   • Are there any constraints or dependencies that make switching to an alternative simple and low-risk?

Examples

Choosing a Text Editor or IDE:

• Often, developers have preferences for certain text editors (like VSCode, Sublime Text, etc.) or Integrated Development Environments (IDEs).
• While productivity can be influenced by the choice, switching between these tools usually doesn’t involve significant costs or impact on the overall system or stakeholders.

Selecting a Code Repository Hosting Service:

• Decisions between services like GitHub, GitLab, or Bitbucket are important for version control and collaboration.
• However, migrating repositories from one service to another is generally straightforward and doesn’t typically result in significant disruptions.

Browser Selection for Testing or Enterprise Usage:

• Deciding which browsers to prioritize for testing might seem critical, especially with varying levels of compatibility.
• In reality, this decision can often be adjusted relatively easily based on user feedback and analytics without deep system changes.
• Enterprise of a browser can usually be swapped quickly, without end users noticing too much.

Selecting Office Suite Software:

• Decisions between office suite tools like Microsoft Office, Google Workspace, or LibreOffice are important for productivity.
• However, transitioning between these suites can be managed with good planning, and generally doesn’t involve significant system-wide disruptions or costs.

Implementing a Help Desk Ticketing System:

• Choices like Zendesk, Freshdesk, or JIRA Service Management are crucial for customer support.
• Switching systems can be done with data export/import features and does not fundamentally change the core operations of the business.

Choosing a Content Management System (CMS):

• Deciding between platforms like WordPress, Joomla, or Drupal is significant for website management.
• Migrating content between CMS platforms can be done relatively smoothly with tools and plugins, and doesn’t usually have deep technical implications for the entire system.