Roadmapping

At the beginning of each non-trivial project there is a lot of uncertainty, and typically language engineering projects are not-trivial at all.

How can you be confident this project will solve your problem?

Is a transpiler what you need in this case?

Should you go for a compiler or an interpreter?

Is there any runtime library you should consider?

Any particular dialect of your language you need to parse?

What factors will make the editor successful in your specific context?

Are you overlooking something that will bite you later, after you invested months and a significant amount of money in this?

Are the consultants working with you understanding what you really need?

By deciding to work with specialists you can avoid many pitfalls. Consultants like us, who work in a very specific niche, know the ins and outs of the involved technologies. However we do not know all the specifities of your context. Chances are, neither do you.

Is it a good business decision to get a quick “free estimate” and jump into the project?

Uncertainty is not good for business. We have to accept some of it but we should try to reduce as much as possible. To do that we suggest go through roadmapping.

Long story short:

roadmapping is a small engagement to figure out what you need, how you should get there, and examine the risks which could prevent you from getting there.

Is it like taking a look at the map and find the best path ahead before starting to run in the direction which seems more inspiring at the moment

Understanding your problem and identifying the right solution can provide a significant amount of value.

Learn more about roadmapping

• What is the problem with jumping to a proposal?We describe some problems we have experienced and some we learned about when all parties wanted to push ahead to quickly put together a proposal.
  We guess some of these will look familiar to you
• How can roadmapping helps with that?How can we avoid the problems with proposals quickly put together, without enough thinking? How can roadmapping solve these issues and align interests?
• What are the advantages of roadmapping?Why should you be interested in this? What you will get out of this?
• When you should use roadmapping and when you should NOT?Roadmapping provides a great value in some contexts, while it is not the right solution in others. You should check if it is a good investment or not in your specific case. We chan share with you some thoughts on this, based on our experience
• How does roadmapping work?What is the process? What I would get and by when?
• How can we get started?If you want to work with us on roadmapping this is how we can proceed

What is wrong with the way most projects are started?

Most consultants are really just looking for ways to say yes to you.

Well, we can understand them, they need your business.

The problem is that winning your business may become their first concern, taking priority over offering you the service you need.

So what happens very frequently?

You ask for an estimate, and they are happy to throw a number to you. Maybe they even advertise “free estimates” on their website. They rush to put a proposal under your nose, waiting impatiently for you to sign it.

It is then than the problem started.

Because there was no time to check their understanding of your situation and your needs. There was no time to reflect on ways to solve the problem. The best way to win your business was to emphatically nod at every suggestion of yours. This is not necessarily what was best for your business. The fact is that when you pay your consultants on an hourly base they will be very happy to start doing something. They are paid for working on a solution, not for obtaining one. And if it takes longer… seems they will just get more of your money.

In the meantime you take your decisions, start your planning, based your strategies… on a number someone put together as quickly as they can.

After the project started things get discovered and estimates fly out of the window. Chances are they are working on time & material, as they could not trust their own estimates, so the price starts rising. You decided this project was a good business decision when you expected it to cost X. Now it is costing 2X. Still a good decision? Maybe not so much.

You can kiss goodbye to the plans you have created based on the timeline they gave you, and now you have to run adapting the plan as you go. Confidence is eroded and the negative feelings about the project come up.

Is this inevitable?

No, but it is easy to end up in this situation, because consultants do not want investing time in understanding your project, at a time in which they are not sure at all they will get the contract. They want just you to buy a solution from them, and then they will make it up as they go. It is the quicker path to your wallet and everyone seems to operate like this anyway.

Considering this, does getting a “free quote” sound like a good business decision?

The alternative: diagnosing before executing

If you are going to invest any significant amount of energies and money in a project it makes sense to ensure you have a clear picture in mind of where you need to go and how to get there.

Before embarking in any non-trivial project you should have:

1. Clarity about the reason for the project and how it solves a business problem you have
   • Why you want to migrate to a new platform?
   • Why you need a new language?
   • What skills you will need?
   • What advantages you expect to get?
2. Understand what value can come up from this project. This should help you understanding which investments makes sense and which do not
   • Once we have built this language for you will you be able to react to changes more quickly?
   • Once we migrate away from the mainframe, will your computations cost less? How much?
   • Once we build this editor are your developers going to be more productive?
   • Once we build this parser what does it enable for you?
3. An analysis of major risks: what can go wrong in this project? What steps can we take now to prevent it?
   • If we write the transpiler, don’t we need also a to write a runtime library to emulate a piece of the old platform?
   • What differences in number representations there are in the source and the target platform? Are they relevant?
   • What notations are your user familiar with? Will they be at ease with the DSL we will develop?
   • What can prevent you from bringing the maintenance in house? How can we reduce that risk?
4. A well defined path forward, connecting your current situation to where you want to be at the end of the project
   • What you need to do first?
   • What are the resources you need to provide us to deliver the project?
   • How will we test this work in your environment?

Once you have that you can take an informed business decision. You can be reassured you did what was possible at this stage to reduce risks.

In other words you studied the map, prepared the backpack with all you are going to need, and took the compass before jumping into your journey.

Things can possibly happen during your journey but you are not running cluelessly into the quicksand. You will be prepared.

Why to diagnose before executing?

The worst kind of waste is spending time and energies working in a direction which is not useful to reach your goals.

You can use all of your skills, put in hard work and still ending up nowhere, unless you are working on something which will move the needle.

There is a reason if many professionals first have a diagnosis phase and only then proceed with administering the therapy.

Let’s recall the last time you entered the office of a medical doctor. The MD wanted probably to hear what was your problem and reflect (even briefly) on this before suggesting a course of action. Correct?

Imagine sending him an email suggesting he performs a surgery on your right kidney and have him answering “yes, sure, I will book the surgery room right away!”.

Not likely to happen, right?

The same thing happens also when you go to the mechanic. You describe your symptoms and support the professional in figuring out the scope of your problem and how it can be solved.

You do not have the mechanic just replacing the pieces you suggest, without checking the car to ensure the cause of the problem is clear.

That would be unprofessional, wouldn’t it?

If it makes sense to do that for a car, should not have at least the same level of care before jumping into solutions for a sophisticate language engineering project, which can have a significant impact on your business?

What advantages does roadmapping give to you

You should expect to get this at the end of roadmapping:

• Identify projects you should not do
• …or the confirmation that this project makes perfect sense
• A comprehensive understanding of your needs
• A clear direction forward, to get you where you need to do
• An analysis of risks you may face during the project
• A mitigation strategy to handle those risks
• Trust on the solution, it can be important to build internal support
• Reduced risk, we know what it is ahead of us
• All our best ideas, as they emerged by reflecting on this

At the end of the roadmapping you will have a clear picture and all the elements to decide how to move forward.

You will have also the liberty to give the resulting report to your internal team, or to find others to implement this for you.

What a roadmapping does not give to you

It is also important to understand what roadmapping will not give you:

• Prototypes: roadmapping is not about writing code
• Lock-in: you will not tied to us, you will get the information you need to delegate the implementation to someone else, if you wish so
• A detailed design of the solution
• A solution to install next week
• A long process: roadmapping should not be a significant invest of money or time

Why roadmapping is good also for us too

You should rightfully focus on the advantages roadmapping has for you.

However, the fact is is also a good way to work for us ensures our interests are aligned, which is good for everyone involved. We believe in working with our clients as partner and one great way to do so is aligning our interests. Roadmapping helps with that.

First of all, it gives us a possibility to work together, so we can understand if this is mutually beneficial. It is good to that before possibly starting a larger engagement.

It helps us understanding which clients are serious about succeeding. We want to work with them, not with everyone with a pulse and a budget because making clients successful is very good for our business. Successful clients come back for more or tell others about what we do. This is how we get clients and we want to keep getting them.

The last thing the client wants is to spend a bunch of money to work on the wrong thing—but it happens all the time. We want clients to be happy because it is painful to work with unhappy client.

It give us time to think together with the client, and reflect on their business. The more we understand them, the best we can take decisions in their interest during the implementation.

When it makes sense to invest in roadmapping and when does not

Cases in which roadmapping is a good fit

• When the consequences of doing this project wrong could make difficult to reach your goals
• When the value of the time your employees are going to invest is significant
• When you have some urgency and you cannot afford a detour before obtaining a solution
• When this is not a routine proejct
• When you are not buying an off-the-shelf product or service, which is implemented all the time in the same way
• When you cannot afford surprises later
• When you need confirmation about the way to go

Cases in which roadmapping is NOT a good fit

• When the project is very limited in scope. As a rule of thumb, if the project is worth less than 5K to you, then the risk of getting a sub-optimal solution is acceptable
• When you have experience with very similar projects. Just rely on your experience to avoid main mistakes and get the general direction
• When your requirements are already detailed and you have a very clear idea already of how to solve this problem

Process: how does it work

This is what will happen once you buy the roadmapping from us:

Preliminary steps

If you need it we can offer our standard mutual NDA. If our standard mutual NDA does not work for you we can offer a solution. For that see details in the terms and conditions below.

Collecting the initial information

To start the process and ensure we will deliver to you a diagnostic intake document, together with instructions, and examples.

The documentation will explain all you need to know to decide who should answer to which questions

We will offer support for identifying the right persons to provide the answers and we will help you solve any doubts regarding the questions. You will be able to contact us by email with a guaranteed response time of one business day.

When you are done you will deliver the answers to us. You will have 14 days to provide the answers to us. If you can provide them more quickly, good, we will give our recommendations sooner.

Going deep

We will start by revising your answers internally. We will have at least two team members going through them and point out everything that needs clarifications. We will do that within 7 days of receiving your material.

We may ask for additional material, in order to provide the best assessment of your situation we can. If this is the case you will get 7 days to collect the material.

We will schedule together a working session meeting to discuss all needed clarifications and dive deeper in everything we need to investigate further. We will work with you to identify who should be part of this meeting. This meeting could last up to 2 hours, so we will block a 2 hours slot, but it could finish earlier. No need to waste your time if we can get what we need more quickly.

We will record the meeting and share the recording with you.

Study the situation

We will study your answers, and investigate possible risks and possible approaches.

We will then prepare a concise document with our recommendations and deliver it to you. This document will be delivered at the latest 7 days after the meeting.

Final steps

We will remain available for anwering questions in the following 30 days

We will contact you and ask you for feedback, so that we can improve the service we offer and possibly provide more value to you.

Terms and conditions

• The price is  1.500 Euro. Which is admittedly very low for the value you are getting out of this. We are pricing roadmapping this low because we want you to understand what level of service we can offer you in the field of Language Engineering
• If our standard mutual NDA does not work for you and your lawyers insist on using a different one, we could talk about that but that will have an impact on the price
• If you provide only partial answers we will proceed with what you have delivered us. If you fail to provide answers at all we will issue a refund, with the exception of a 35% sum that will be kept to compensate the time invested
• Do you have a purchasing department and discuss special contract needs? Yes, we can discuss this but we will not be able to offer you the same price

How do we get started?

There are two possibilities to buy the roadmapping service: paying by credit card or by wire-transfer.
In both cases the price is 1.500 Euro.