We design strategies to get us to a position of advantage. Our AS-IS situation has some problems that we’d like to solve in our TO-BE design.

In the case of “greenfield” projects, this concept is clear. We have a problem and the strategy is designed around distilling and building a solution.

With operational products (or legacy software) the problem is not that well-defined. The product is doing what it’s supposed to do after all. People use it every single day. The problems we see are secondary. We feel it’s “unstable” or “expensive to change”. Sometimes we only have a sneaky suspicion that the system is “high risk”.

Software developers have a hard time explaining what needs to be done to fix a problem they can’t define. They’ll often throw their hands in the air and demand the Big Redesign In The Sky. Managers have difficulties defending a budget to address vague things like “technical debt” or “not very future proof”. They’ll get frustrated about the smokescreens and the lack of clear steps.

We don’t end up with badly maintained software because our teams don’t care about them. We end up with legacy applications because we can’t define what needs to be done to fix them. There is no plan. No timeframe. No ROI.

So, instead of pumping a lot of money in the black box of “rewriting”, we opt to patch or hack visible problems bug by bug. The result is often very expensive.

If we want to get out of this stranglehold, we’ll need to come up with a strategy. In a lot of cases, the TO-BE situation is pretty clear. It’s where we are now, minus the risk, plus a few features.

The thing we are struggling to define is the AS-IS situation.

Before we come up with a plan.
Before we define a project.
Before we assemble a team.

We need to answer the tough question in detail: Where are we at right now?