Ever wonder if timespans has any practical usefulness? Here is how I used timespans to clear up a communication problem in a global IT architecture group for an international bank.
Awhile back I worked with a group of enterprise architects (EA) at an international bank with major operations in all the inhabited continents. The group, although “headquartered” in the US, had members in each of the bank’s regions.
This group had been trying to develop a Architectural Strategy. In that, they had some elements that were predetermined by the relationship they had with the outsource company that was handling IT support. They decided together that their Architectural Strategy would include:
- Technology Refresh Plans (TRP) which were part of the budget, done annually, and handled by the IT management company that had the outsource contract
- Current State Architecture (CSA) which would detail what was currently in-place
- Future State Architecture (FSA) of where the bank should be heading to achieve its business goals in the future
- Long-Range IT Plans (LRITP) that would help the bank achieve certain parts of its goals from “plateau” to “plateau”. These were semi-stable points that would achieve the goals of the Future State in small chunks.
But they couldn’t come to an agreement as to what any of these terms meant.
I was tasked with writing all of this stuff up. Try as I might, I couldn’t make heads or tails of it.
Until I realised that timespan theory could unlock the whole problem. All I did was start asking each architect, individually, what “long-term plan” meant to them and how far out he or she thought the future state was.
It turned out that they were disagreeing because they were all talking about different things. Some of them thought that the future state was 2 years out. Some thought it was 3 years out. A handful said 4-5.
In worklevels theory, this supposedly homogeneous group was actually at least two different strata. Those who looked at the future state as being 2 years out were probably Level 3. Those who saw it as being 3-5 years out were variously capable within Level 4. And one of them was probably capable at low level 5.
These people had enough problems coming to agreement without adding worklevels to the mix. By explicitly stating that the Future State Architecture was always five years out, I took the ambiguity out of the process. Many of them can’t handle the uncertainty of a goal that far out, and some of them could. I also defined different levels of the long-range plans, attaching time horizons to each one. Those that were closer in time could be taken on by Level 3 staff. Those farther out would have to be handled by Level 4.
I hoped that they would be able to sort themselves out. Unlikely, but until they had these times attached to the terms they were unable to move forward at all.
There it is: you can do reduce a lot of confusion at work by simply asking “How far out do you mean?” People have the same problem with “Strategic” and “Tactical” that this group had with “Long-Term” and “Short-Term”. You can reduce the confusion there, too, simply by asking about the time horizon.
Here’s the PowerPoint presentation I did up to put my definitions into action. When you use animation, you really can control the debate by controlling the definitions.
Calendar. Licensed through 123rf.com
Pingback: Can “Strategic” Mean Differrent Things to Software Architects? « Hez Sez