The 8 Questions to Ask Your IT Staff Before Approving the Next Tech-Project
Hint: They are mostly non-technical.
As a leader in an IT-organization, you have been in this situation before:
You are being approached by your IT staff to spend time and resources on new technology – Maybe it’s ‘the next big thing’ or ‘something we should have done from the start’ or ‘necessary, so we can continue developing efficiently’, and it is also ‘helping our customers’, of course.
But how to judge if it’s really worth the effort? Maybe you don’t have a tech background, or it’s been some time since you worked on the ground – In any case, it’s hard to judge.
Drilling into the technical details of the proposal is a trap – Tech is getting more and more complicated, and your IT-staff has the knowledge for the assessment of tech aspects. So take them seriously – But also ensure you can make a holistic decision by asking questions which cover the non-tech aspects. This also helps them to think not only about the tech, but also other implications along the road.
Here we go:
The questions
Q1: Which business areas are affected by the new tech?
This is an important question to start with to get a better understanding of business implications. If one of the major business areas is affected, you might want to be conscious.
In case it’s just a minor business area or even one which is declining or in phase-out, tech investments might simply not pay-off.
If your team doesn’t know which business areas are affected, you should directly take action to make this clear throughout your organization. This could be as simple as mapping between tech components and business areas (or applications), but could also be realized with the definition of value streams. In any case, it should always be clear where and how IT created value.
Q2: What do we currently have in place to solve the problem at hand, and what are the upsides of the new tech from a customer perspective?
Having new tech is nice, but it should have a business impact as well. Maybe its speed of delivery, security, or robustness against failures? If there is no clear value-proposition here, the project should be scrapped. New tech should never be introduced just for the sake of it being new, you truly need a business-case.
In order to understand that, you obviously need to know what the current tech solution looks like – Otherwise, how can one judge the potential improvements?
Q3: Which alternatives did you consider ?
Today’s tech landscape is very diverse, so there are always multiple technical solutions for every given problem out there. Looking and comparing alternatives needs to be part of the selection process.
In addition, by looking at the alternatives that were discarded you can understand the priorities of the team making the proposal (“Why did they choose this piece of technology instead of the other one?”) and see if you agree.
Being new is not enough. As Schopenhauer said: „New things are rarely good because good things are only new for a short time.“
Q4: Can you compare the complexity of the problem you are solving to the complexity of problems usually solved with this technology?
This is what I call the ‘Kubernetes-Trap‘. Kubernetes is a deployment environment that was designed to support 1000+ containers with high reliability. It is highly customizable, but also complex. Very complex. If you just need to run a couple of containers, it is very likely not worth the effort to introduce such a solution.
Still, many teams use it because it is en vogue. They are much slower than they would have been with a simpler technology, but don’t benefit from the power of Kubernetes as their setup is not that complex.
So, before you introduce any new tech, ask your team about complexity, and especially for what level of complexity the new tech is designed.
Q5: How many people need to be trained / educated to use the new technology? What is the expected learning curve?
Team members that want to introduce new technology are usually ‚tech-savvy‘, meaning they can embrace and get value out of the new tech easily.
However, to unlock the full potential, eventually everybody working with a piece of technology needs to understand how it works and how it can be used. This training or education efforts need to be planned and taken into account when looking at overall costs.
Risk is part of every new endeavor. Be ready and have a plan B if things go wrong.
Q6 : What is our risk mitigation / rollback plan in case the new tech does not meet our expectations?
Things can go wrong, and the introduction of new tech is no exception – Maybe it is too difficult to operate, not reliable enough or does not meet another expectation.
It’s important to define up-front if any cancellation criteria exist, and to plan for failure.
It usually makes sense to create a proof of concept that shows the value of the new technology, but in an isolated environment without affecting the business.
You can also consider running new tech in parallel with the existing solution, so it can be compared easily. In any case, you don’t want to end up in a position where you have to force-forward because the new tech is already integrated so tightly that you cannot revert it.
Q7: Why do we want to do the project now (and not in 12 months, for example) ?
A new (tech) project is always a priority call against other development activities.
So, it is important to understand if there is a specific need to conduct the project now, or if it can be done in the future. (or better: Is there any cost or risk associated with doing it later).
Q8: How happy are you with the last five tech projects?
Tech people tend to see tech changes through rose-colored glasses. It’s always fun to do something new, and it likely improved something somewhere.
Research indicates that this is just good old human nature: When deciding about complex problems, people actually prefer the unknown (i.e., the new technology) to something whose weaknesses they know all too well (i.e., the status-quo technology). This is nicely explained in Marianne Bellotti’s book „Kill It With Fire“ (the relevant Chapter is available for free) or in the original research paper by Bier and Connell.
So, in the beginning, also the last five tech projects likely looked promising. But, in hindsight, were they really worth the effort, were the costs as anticipated? By motivating your team to truly evaluate the latest tech projects – again, also from a business perspective – they might look at their current proposal from a different viewpoint and potentially revise.
Conclusion
Good decision-making with regard to new tech proposals is a complex and interestingly mostly non-technical challenge. It is a critical success factor of true technical leadership. Asking the right questions right away is key. The result is typically not a simple approval or rejection but an evolution of the original idea. Even the strongest proposals tend to improve under a sound evaluation.
