Agile transformation, for large IT organizations. Articles. Ideas. Thought leaders.
Interview with Madhur KathuriaMadhur Kathuria has coached nearly 300 teams for almost 75 clients across the US, Europe, South East Asia, Malaysia and Thailand. In this interview he talks about some of the cultural challenges for agile adoption. Read it here. |
Interview with Elena YatzeckElena was Chief Agilist for JP Morgan Chase Treasury Services and is now a VP of Corporate Compliance Tech. Find out how JP Morgan Chase reconciles agile with compliance and risk management demands. Read it here. |
Roadmaps Will Be Wrong But Roadmapping Is Crucial
According to Harold Russell, an organisational development and change specialist,
"I believe any significant change affecting a business requires a clear common understanding, particularly amongst senior management, as to what they want things to be like once the change has been worked through. It really is an invaluable means for everyone to stay focused on what they're driving towards. However, depending on the time-frame of the change programme, it is quite likely that the eventual outcome may need to be redefined along the way in response to changing circumstances."
Brent Barnacle, Strengths Consultant at Strengths Strategy, Inc., puts it this way:
"A road map is extremely important as it sets the agenda. Everyone needs to know where they are going and what the clear plan is to get there. Without this, it will be very difficult to get everyone on board. Sure, there will be new strategies that form along the way. But without a clear picture of the greater purpose, it will be difficult to lead."
But then Paul Coulter, a sale training consultant, points out,
"In an ideal world you may need a roadmap. My experience is that roadmaps tend to get in the way of the obvious natural path that unfolds as you use your end result as your compass. Leaders/consultants use an internal roadmap and trust that as the uncertain process of change unfolds and as hidden unknown realities appear they intuitively know what to do next. A roadmap has a tendency to miss/ignore/overlook key multi faceted troubling obvious realities. A keen perspective catches those subtleties roadmaps tend to bypass."
Indeed, roadmaps tend to miss a-lot of important things - often things that are intangible and that are difficult to articulate in terms of a roadmap. Things like, "The Director of Security and the Director of QA don't like each other, and so we will need to have the CIO run some interference, and it will likely put some of those items on a slower track." Or, "The QA Testing group needs to overhaul its purpose and function, so we need to postpone their work on next year's contracts." But issues like these are important, and they need to be accounted for in planning and execution.
Perhaps the best way to use a roadmap is as an overall timeline. If work is planned and executed based on progressively eliminating the constraining impediments, then a roadmap is a place where things can be placed on a timeline and lined up. This allows one to see when resources will be needed, such as when certain skills will need to be in place in order to prevent that area from becoming the constraining impediment once the current impediments have been removed. This means that the roadmap is not the driving plan, but is the place where one aligns the various transformation work streams. A backlog of goals can drive the work, and the roadmap is merely the map of how those things intersect.
Subscribe to:
Posts (Atom)
No comments:
Post a Comment