Transitioning
Don’t panic! Today’s topic is not gender-realignment surgery, or what we used call sex change operations. Instead, we are going to look at what needs to be done to transition an organization from its current state to a desired future state.
It is all very well for an organization to have a strategy but, to achieve its goals and objectives, it needs to charter projects. This is because projects are change agents; they are the mechanism by which we transition to where we want to go.
Unfortunately, people tend not to like change and we certainly do not like surprises. This means that a significant part of the business analyst’s role is guiding stakeholders from where we are now to where the organization needs to go.
However, getting to this promised land often involves a lot of work that will not be apparent at the final handover. This work is described in a series of what are called “transition requirements”. To explain what these are about, allow me to provide some examples:
Take a heart transplant operation. The medical professionals decide that the best course of action for a particular patient is to replace their diseased heart with a healthy, donated heart. In terms of requirements, the patient (the stakeholder) wants a better quality of life, not to mention a longer life expectancy. Mapping these onto solution requirements means we need to get a properly functioning heart in place (be it through fixing the existing heart, or by replacing it) and we need that to be reliable, so it keeps the patient alive for many years to come.
However, in order to swap the old heart for the new, the patient must be kept alive during the surgery! Thus, we need the services of an artificial heart during the procedure and someone who knows how to plumb it into the patient and monitor blood flow during the operation. This is a transition requirement. It is not a functional, or non-functional requirement (i.e. it is not a solution requirement), but it is essential to getting us to where we want to go.
As another example, suppose we are building a new, bypass road. This crosses an existing road and the plan is to build an intersection between the two. An important stakeholder requirement is that traffic must continue to flow on the existing road during the construction of the intersection.
This usually involves the construction of a temporary road while the intersection is being built. Alternatively, temporary traffic lights could be put in place, allowing one half of the intersection to be built at a time.
No matter how we solve this problem, we will need to budget for temporary traffic light rental, or extra building material for the temporary road. In other words, these measures need to be included in the project planning from the start. From a project management perspective, this is specified as a transition requirement.
What about installing a new IT system? It is really straightforward if we are installing a new system in a green-field site. Sadly, most IT systems must replace existing systems and a requirement for organizations is that the new system must run in parallel with the old one and, when the stakeholders are satisfied that the new system is processing items in the same manner as the old one, we need to cut over to the new system seamlessly. While this may be framed as a non-functional requirement, there are situations where existing databases need to be converted to formats that the new system understands. Thus, we might need to create little conversion utilities to populate the initial database.
These utilities are not part of the finished product, so they would not come under the solution requirements heading. However, they could be documented effectively as transition requirements.
As a final example, suppose our project is to clear a site for use in a later construction project. The stakeholder wants to see a flattened piece of ground without the remains of any derelict buildings or overgrowing vegetation. They might also request a map of where utilities (electricity, gas, water, etc.) are coming into the site.
However, the clearing of the site is going to involve the use of bulldozers and skips and probably other types of heavy machinery. None of these are going to be delivered to the stakeholder at the end of the project. In other words, they are not solution requirements.
But, in order to transition the site from being full of old buildings and weeds to a flat, safe building site, we need to employ skilled operators and specialist equipment. These need to be captured as transition requirements.
While most textbooks will recommend mapping stakeholder requirements onto testable and measurable solution requirements, what happens to those requirements that do not, directly, relate to the delivered solution itself? Mapping these onto transition requirements and factoring these into the project plans from the outset avoids last minute panics and ensures we get to the desired future state seamlessly.