When joining a project, it is common that one of the first things you’ll be asked to do is support the team in making choices. Sometimes that might be validating a choice that has already been made and “rubber stamping” it or it might mean you have to make a strategic choice on the client’s behalf. Often in a client / supplier relationship the client wants the supplier to lead this process because the supplier has much wider experience and they can be held to account if things go wrong.
But from a personal perspective you end up drawing up the opinions, assessing each one, making a recommendation and having to stand by that recommendation when people get nervous.
We find ourselves in this position because it is a hard choice. If it wasn’t the client would have made the choice without our input. So how do you define a hard choice:
- Where there are many alternatives
- Where there is no clear or obvious option. Each option has a trade off
- Where once a choice is made it would be costly or time consuming to undo it later
As a technologist the choices you’ll be involved in are likely to centre around architectural styles or technology selection. However, as professionals, we should be able to create a successful system regardless of the technology whether that be .NET or JAVA and it doesn’t matter if it is built from services communicating through REST interfaces or through messaging. There must be something more to it.
It is not just about what you think is the right choice, it is about making a choice that is sensible in the context and environment you are in. You need to get to know your customer and understand how they got to this point. Often understanding what was attempted in the past, and failed, will help you make a better choice now.
AcmeTech has been a Microsoft shop for years. It’s not because they think Microsoft technology is better than anything else, it’s just that it meets their needs and it is price competitive.
They have started on a large project using their regular development team but have bought in an external consultant to lead the technology side of the project. When that consultant starts they realise that an important project stakeholder is promoting the use of a particular product. It is a product that is well regarded and fits the bill, even the external consultant thinks so, but it requires the development team to integrate to it and configure it using Java. The stakeholder has looked into the license costs and created a business case that concludes that the products costs per feature is extremely low.
The development team say the product is not suitable because they don’t know how to configure it and integrate with it. They would need to rebuild all of their development and test environments to provide an effective delivery pipeline for the project. Instead they propose an alternative product that may fit the bill. This product doesn’t do all of what the Java based product provides, any gaps would have to be filled through bespoke coding, but the development team can integrate with it and configure it through .NET. The existing development and test environments can be used.
The external consultant is asked to choose between
- Asking the current team to deliver the project using the Java based product
- Replacing the development team with Java Developers and use the Java based product
- Retain the development team and recreate a solution with a less feature rich product and write more custom code in the Microsoft stack.
The underlying point here is that AcmeTech believe they will get an inferior solution if they use the existing team to build a Microsoft .NET based solution. They think the resulting solution won’t meet all of their requirements, will take longer to deliver and the project will cost more, than if they implemented the Java solution. They see a Java option solving all of their problems and to be fair it probably would. Their preference is the first option, because the lead time for bringing in a new team would be too long, not to mention the adverse effect it would have on the morale of the existing team.
However, when the external consultant looks at this they recommend the third option.
There justification is that when they look at how the client works they see an organisation that is very effective delivering Microsoft based solutions. Whilst they concede that it might take longer and cost more to deliver the project in this technology the team have a track record of accurately predicting their costs and timelines. On the other hand, the few difficult projects that AcmeTech have had, all have a similar theme: they have attempted to integrate unfamiliar technology. Therefore, the consultant concludes that AcmeTech have no Java delivery capability and therefore no way of predicting the costs or success of the proposed project. Whilst the project could solve many of AcmeTech’s problems they have no capability to deploy and operate that product.
On reading this you may have come to the same conclusion. No organisation in their right mind would choose the Java option in this case. It is obvious isn’t it.
Well yes, in my watered down example it is but in reality things are more complex. In the real world there may be many more options and variations of options. You might not have all the information or you might have conflicting information from different stakeholders. And sometimes the organisation has already made their decision, it is the irrational one that makes no sense and you are the one who has to make it real, dealing with all the flack as you go.