The technical and non-technical nature of assessment

Suppose you need to migrate from an old API to a new API that offer similar capabilities. Something like this:

public interface OldAPI {
  public TheReturnType doSomething();
  ...
}

public interface NewAPI {
  public ASlightlyDifferentReturnType doKindOfTheSameThingButDifferently();
  ...
}

The only requirement is that when the next version of your application ships, there should be no trace of the OldAPI. How do you approach this task?

Straightforward. You take the API clients one by one and migrate them to the new API. Of course, if the changes are 100% backward compatible, you can even automate the process. But, even if it's not automate-able, it is still a straightforward technical problem.

Now suppose that the API is used in 100 different places, and that each place requires some 15 minutes to change. The problem is slightly different as now, given that you cannot do everything in one batch, you have to plan effort and track the progress.

But, what happens when the 100 places are spread over 10 different projects? You now need to involve all the teams working on the respective projects, keep track of their effort and ensure that when the new version of the overall application ships there will be no trace of the OldAPI. To achieve your goal, you need all projects to pull in the same direction pretty much at the same time.

All of a sudden the problem becomes an organizational one, and it requires a solution that goes beyond the technical issue and touches the process and the structure of the organization. This is the nature of assessment.