IT: Are we there yet?

How do we get to where we are going? How do we manage change? How do we design the systems we require? What is a common concept of both waterfall and agile development? The journey. There is always a journey involved to get us from the state we are in to the state we want to be. It is a journey that must be mapped, drawn out and planned. The process for getting there may be different, either breaking the journey down into smaller chunks, or trying to get there in one long leap. But the manner in which it must be done is consistent.

And yet it is surprising the number of times I see the journey’s being undertaken without any understanding of where they are currently starting from or how the journey is to be made. Almost certainly, this will be a journey doomed to failure. In this blog I am going to look at the key component parts of a journey to demonstrate their importance and to show the potential ramifications of ignoring them.

“In the beginning”

For a brand new system, this state would seem simple...nothing! But this is not accurate. The reason for the creation of any new system is to automate a currently manual business process. Even if it is a new process, a process exists and this process should be the start point. It will help us to define our requirements and what we have to date. Even at this point, the commonality between a brand new system and the change to an existing system is there to see. We have a start point. As explained for a new system, this will be whatever the manual process is that requires automation and this will seem like a lot of work. But the complexity is much simpler than for a change to an existing system. This requires us to have an in depth understanding of our start point. We need to define our baseline.

Unlike a new system, we will already have constraints from the existing system. We may be tied into specific third party products, a specific Operating System, Database or Programming Language. In addition, there may be further changes to the business process that must be incorporated. These changes are not mutually exclusive either, with multiple combinations possible and multiple cross impacts. Defining in very clear terms your start point is the first fundamental in the journey. I would hope that creating this baseline should be easy enough by re-using the end state from the last journey as a start point for this. The importance of this re-use of assets, hopefully stored within a Configuration Management Database (CMDB) cannot be underestimated, saving much time and effort later and providing an accurate pin to our current location. As with any journey, if we start from a point that is not accurate, then our journey will be troubled. We will come to that sudden fork in the road that shouldn’t be there and have to make sudden and rapid decisions that could make or break our efforts. Suddenly a clearly planned journey becomes a gamble and we become lost along the wrong path.

“Where do we want to be?”

Let’s assume we have our start point accurately positioned. We now need to understand where we want to be and it is at this point we must make a fundamental decision. If our destination is fixed with little or no chance in deviation, then we can plan for one long journey. This happens more rarely than many consider; after all, change is constant. Typically this will be when the journey is short, the chance of roadblocks is low and the possibility of external influence changing our journey is practically nil. If those circumstances are true, then we could make the journey by waterfall, confident that there is only one path, one destination and very little risk of disruption.

But for the vast majority of projects, the path will be long and as a result open to a lot of potential change. The original planned route may suddenly become blocked by other work. Rules may be put into place meaning we cannot take a particular path or end at a particular destination. As we make our journey, the decision on what our end point is may change. In this case, it is best to make our journey in a series of iterative steps. At the end of each step we review our end destination and decide whether the next iterative step in front of us is open or appropriate. It gives us a chance to quickly re-plan our route, avoiding major diversions or incorrect decisions of direction. Agile provides the perfect mechanism for ensuring that we make minor course corrections all the time, reducing cost and time impacts to our journey and guaranteeing the successful arrival at our final destination.

“The long and winding road”

If we are taking a long and winding road using waterfall, then the chances are we have chosen the wrong method. Waterfall journeys should be short, straight and uneventful. I have known very few projects to operate that way. As we make our journey, our skills to map the journey must be strong. We must be open-minded to every eventuality and ready to quickly change course should it be required. This requires a keen skill of anticipating possible challenges through Risk Management and being able to act on those should they occur through strong Issue and Change Management. Our planning skills will be tested to ensure that we retain the same numbers for our journey whilst maintaining the best possible heading at all times. Even at times taking the radical call of taking shortcuts to reach our destination; providing that in themselves, those shortcuts do not introduce additional high risks or issues. The end of each iterative step basically becomes our new baseline for the start of our next; until ultimately we take that final step and achieve our goal.

And so we must plan with thoughts of any journey having a start, middle and end; and understanding that the middle and end can, and do, change. Without all three, we will be doomed to wander in a land of lost projects and unfulfilled promises, always hearing that call, "Are we there yet?"

Steve W