A CIO Basic: A Real Road Map
By Darren Cockrel, CIO, Coyote Logistics
Darren Cockrel, CIO, Coyote Logistics
The concept of a technology roadmap is easy to understand. You write down what you’re doing, why it matters, and when it will be done. I’d be surprised if any IT shop more than a year old doesn’t have a roadmap or some sort of eighteen-month vision laid out in an attractive document. The trick is keeping that roadmap relevant and visible.
A roadmap serves many interests. It is essentially the place where IT strategy connects with a company’s vision. It may also be the place where people look to plan labor, define a feature to sell, or establish a market advantage over a rival. Whether you are in IT or lead IT, the roadmap is going to help you focus and define success for your department.
So, what goes into a great roadmap? I have found four areas most common:
1. Company vision: New features need to be built, bought, integrated, or otherwise produced in the technical stack to enable the company vision. Since these are often grander efforts based on anticipated need, these projects tend to be the longer and more disruptive to the status quo.
2. Customer demand: Ideally, you can build this for one customer and many of your other customers will want it. You will probably discover imperceptible value and fortify customer relationships if you can tailor your solutions for specific use. The caution here is that a feature that is too specific may be impractical for reuse.
3. Core technology: Internal improvements and maintenance never look that exciting, but poor stability or scalability will pull down momentum company-wide. While this work deserves a seat at the table, be sure that internal improvements are realistic and justifiable. This way you will know you’re creating value before “replacing and rewriting” when you could be “repairing and advancing.”
4. Fast track for smaller efforts: Keep a pipeline open for small enhancements. I prefer to slot these as quarterly “batches,” and sort out what gets resourced through timely reviews. You will look back and realize that many of these small fixes generated big benefits. But watch out for a few common pitfalls:
a. If a large project somehow falls into this channel on your roadmap, it will bottleneck plenty of other small projects and undermine the reason you have this channel in the first place. Try to keep the work sized into your smallest work cycle, such as a two-week sprint.
b. Manage con- flict with your other roadmap areas. This channel will be more “now” focused and may have work in it with a shorter lifespan, or work that will extend the time it takes to phase out another technology product.
c. Lastly, you may notice that a larger project is being piecemealed together through small enhancements. This probably happened because the project definition/approval process was too cumbersome or the project really isn’t aligned with company direction. If you ensure that each project stand on its own rather than having multiple phases, this sort of piecemeal process won’t work.
Any roadmap is situational based on the business it serves, so see this as a starting point. You may need other breakouts around products, research and development, market differentiation, or whatever your company needs to advance itself.
Once your process is proven and healthy, stay focused on ways to make the roadmap visual, consumable, and interesting. Place those mind-numbing project details behind a beautiful summary so the data is there if anyone wants to know more. Define and communicate what a success looks like based on this road map. Then communicate it however works best— if it isn’t consumable, it will lose relevance quickly. Once work starts to leak around this roadmap, you’ll slip into the common IT chaos that plagues so many organizations.
Whether you are in IT or lead IT, the road map is going to help you focus and define success for your department
However, if you decide to present the roadmap, keep it audience focused and keep it tight. To generalize, most people talk too much and offer data that doesn’t support their presentation. I believe that the greatest skill to develop as a technology professional at any level is brevity. Success follows leaders who are able to communicate the key parts of an idea while making the message something people will actually read.
After this planning, presenting, possible politicking, and aligning, you better be able to deliver. Having the strong bones to manage scope and lead the delivery organization is critical. Roadmaps will go out the window if you slip on critical commitments or if you can’t maintain stable operations. Strong basics are also the focus here. Hire terrific people, keep the projects small, iterate where possible, and look for flexibility in the delivery dates. And once in a while, do the unimaginable and finish early.