Jonasz Staszek

We’ve all been there. We know that there is a problem somewhere in resource allocation. We have also already established that we need a decision support tool (read more about the decision support paradigms here). Then, we come to the phase of scoping our optimization project. To that end, we need to figure out what exactly is the problem? Which decisions do we wish to automate? Who makes them today? What criteria do they use?

These questions are of paramount importance. Scoping an optimization project is an exercise to do at the beginning of the project. Otherwise, you risk spending loads of time and money on solving the wrong problem.

In her great talk at CP2020, Andrea Rendl of Satalia gives the following tips for a successful scoping of an optimization project right.

1. Include the right people.

For a successful project, you need to deploy a wide variety of talent. This includes both in-house team members and external experts.

First of all, you will need to have domain experts and end-users on board. These persons will be in charge of describing the context, as well as explaining the decision problem.

Secondly, it is good to have software and optimization specialists on your side. These people are usually external experts. Their job is to ensure that the planned system fits into the existing IT ecosystem. They are also the ones to say what is possible and what is not.

Finally, the team would need a decision-maker, usually a management board member. Their job is to set the direction, resolve conflicts, and make sure the project goes in the right direction.

2. Acknowledge different priorities

As we saw in point 1, there are numerous groups involved in the project. As a result, there are also numerous preferences and priorities, which usually do not align.

To avoid future trouble, make sure all the people and their priorities are heard. Once they are laid out, identify the ones which contradict each other.

For example, it might be possible that while end-users would like to have numerous solutions to choose from, the team leader insists on having one only.

It is then the right time to involve the decision-maker in the team to prioritize priorities. They need to acknowledge the conflicts and make sure that the selected direction aligns well with the company’s strategic goals.

3. Agree on terminology

The client often has their own “domain language”. Some of the terms used by the team members could have different meanings, depending on who uses them. In turn, this may lead to confusion or misconceptions.

All the team members should be aware of these language pitfalls. Andrea Rendl gives a great tip on avoiding these problems. She suggests coming up with a glossary of problematic terms and then making sure all team members learn the language of the other stakeholders.

4. Acknowledge modelling limitations

George EP Box once said: “All models are wrong, but some are useful”. This is indeed true for scoping decision-making models.

All the stakeholders need to realize that we can at most come up with a limited representation of reality. Some situations or contexts may be difficult or even impossible to include. Think of a situation when employee A may not be staffed together with employee B for “personal reasons”. Perhaps one conflict of this kind could be included. But imagine mapping all relationships in an organization with several hundred employees!

5. Debunk legacy features

A legacy feature is a feature that is not (or no longer) necessary, but the end-user or domain expert believes it is.

You should try to understand the reasoning behind every constraint or objective supplied. This is best achieved by asking “why?” sufficiently many times.

Remember what Grace Hopper (also known as the mother of compilers) once said: “The most dangerous phrase in the language is: But we’ve always done it that way”.

Once you surface such a legacy feature, bring it to the attention of the team. It could well happen that letting it go will unlock many new possibilities.

6. Be alert for potential sabotage

This is a serious one. Some people in the organization may feel threatened by the decision support tool you develop. They may have good reasons to do so, e.g. fear of losing their job. As a result, they will do everything in their force to sabotage the project.

The most popular acts of sabotage include providing inaccurate information – be it constraints, objectives, or deadlines. It could also happen that someone will provide you with a skewed benchmark on the performance of your solution.

These acts are quite rare, and – knowing your organization and its culture- you will be able to accurately assess their likelihood. Nevertheless, you should stay alert.

7. Apply good communication practices

We all want to communicate well, even though it usually takes a lot of effort to do so.

First of all, to ensure that you do not miss anything, you should listen actively to all the stakeholders. You should consider making this your habit (if it is not).

With this settled, you should provide everyone with the room to speak.

This works best if the environment is safe and relaxed. A social event will help reduce the tension and improve the atmosphere.

Finally, don’t forget to take notes!

8. Plan for several scoping iterations

Let’s face it – you will probably not get it right the first time. Even if you try your best in the first round, you will likely need to return to the drawing board.

Don’t rush it. It is normal that it takes several attempts to arrive at the right scope.

9. Share initial solutions as early as possible

One of the proverbs of the optimization community is: “Fail early”.

If you have an initial solution, share it with the end user or domain expert. Obtain their feedback as early as possible.

A solution will always be more tangible to them than a description of a decision model. For example, they will be able to see the consequences of their requirements.

More likely than not, end-users or domain experts will reflect on their input and revise it (at least partially).

This will help everyone – you will know where to go next, and the end-users and domain experts will feel involved and co-responsible for shaping the final decision support tool. Thanks to this, the implementation of the tool will be easier.

Conclusion

Scoping an optimization problem is a great challenge. Fortunately, you are not the first one to face this challenge. I hope that the tips above will help you ultimately get the problem right.

Stay tuned for future posts!