DC Velocity - IdeaBook 2017

2017 dB

carrying out the project and to review any known constraints that may affect the hypothesis. These two factors will be explored in even greater depth and detail in the next phases of the project.

FEASIBILITY

In this phase, the objective is to validate or disprove the hypothesis and conclusively prove that the future state goals are achievable. This involves quantifying both the current state, or baseline, and the system’s desired future state, as well as testing the hypothesis against already known constraints.

If the hypothesis involves an adjustment of the workflow or business process model, establishing its feasibility may be as simple as developing a few process maps showing that, for instance, collapsing steps on a noncritical path can reduce cycle time. If the hypothesis relates to a complex change, however, establishing its feasibility is likely to be a rigorous undertaking requiring many hours of analysis. For example, checking the feasibility of the hypothesis “shipping costs can be reduced by 15 percent by reducing express air freight” would require collecting and analyzing data on airfreight spend, shipment volumes, and customers’ service-level expectations over time, as well as destination geo-coding, mapping, and alternate transportation flows. In this case, potentially hundreds of hours would be invested studying data to prove that costs could actually be reduced by 15 percent, and if so, what tradeoffs exist.

Either way, validating a hypothesis’s feasibility
is critical if you want to avoid overcommitting
resources to a project that ends up being a marginal
producer or cannot be implemented due to a “hard”
constraint (for example, if customers paid for all
express airfreight shipments in the previous year).

“GO/NO GO” DECISION POINT

At this point, the team decides whether or not the project should proceed. In fact, a project idea must “pass muster” several times before it moves into the full-blown project phase. We designed such decision points into the process because project managers need the flexibility to abandon the project early on if it does not meet certain feasibility requirements.

Many projects produce suboptimal results because no one individual—or even a large group—has the power to stop them. Subordinates are often unwilling to tell their superiors that a project should not be implemented. By designing in “gates” where the team needs to provide sufficient evidence in order to proceed, we take the burden off the project team and place it on the process itself. Failing to prove that sufficient evidence exists to continue a project does not constitute “failure,” and project sponsors can refocus their energy in other areas.

DUE DILIGENCE

This is the time to discover information that will be relevant to designing a solution, such as what processes, relationships, activities, and information technology (IT) systems should be involved, as well as what their interdependencies are. In many cases it requires gathering large quantities of historical transactional data from multiple systems.