A recent inquiry from a potential client spurred me to dig up a few notes and sundry draft copies of Technology Roadmaps (TRM) from my past; sorting the haphazard disarray of completed Visio drawings and hand drawn notes into piles was encouragement enough to jot down these few words for your viewing pleasure.

[Note: This is by no means a complete guide to TRM development. If you are interested in full processes, Amazon has a great selection of books on Technology Roadmapping.]

Notes from the not-so-far-side:

• The only TRM worth having is the one you’re willing to throw away.
• Your TRM must be part of your budgeting process.
• Stuff gets cheaper, technology comes and goes, laws change.
• Your business can change too.

A few Corrollary statements — just because:

• Your business requirements determine your destination, not your roadmap.
• Your TRM is a living breathing document, as such, if not properly nurtured, it will die; gasping for air and malnourished.
• Technology changes (hopefully for the better.)
• You will get hit with legal, financial, or other obligations that can influence your TRM. Accept it.

Uhhh… What’s a Technology Roadmap?

Well, it goes something like this… A Technology Roadmap matches your business needs with an appropriate technology solution to help resolve or meet those needs. A Technology Roadmap is a planning and communication tool, used to provide a guideline and help visualize and communicate your short and long range plans regarding technology. A Technology Roadmap should not only show your technology requirements, but should be able to provide insight into your staffing and training requirements as well.

Check out the attached image for a very simple example:

“Sooo… is that what a TRM is supposed to look like?”

Oh, Heck no!

Err… Well, maybe, if you like the format enough. After all, the example follows the K.I.S.S. principle. A TRM does not need to be complex. In fact, the simpler the better; not only does executive management need to understand the point… you, dear TRM author, should plan to be hit by a bus, thus leaving some other innocent soul to complete your work. (hmm.. now where are my notes on business continuance planning?)

Here, have a peek at some other Technology Roadmaps. Some of these aren’t roadmaps, they’re a virtual atlas! Even google maps would have trouble with these, sheesh!

Okay, so sarcasm aside — let’s boil it down into simpler terms and a short and sweet process:

In general, a Technology Roadmap should tell you the following:

1. What problem you’re solving and why
2. Who’s going to solve it
3. When they’re going to solve it
4. Using what technology solutions
5. How much it’s going to cost (estimated)

There will still be a few things remaining to work through, such as:

• What products you will use
• Where, and how the implementation will take place
• Exact cost

“Get to the point already!”

Ooookay.

Building your TRM in three easy steps:

1. Identify your business issues and business goals.
2. Decide on a time-line for implementation
3. Map out the technology solutions and milestones/decision points.
4. Execute; Review and update as required.

“Hey, I thought you said THREE!”

Erm. Technically #4 is not a “step.” Moving on…

Breaking down the process

You’ll find many TRM guides loaded with phrases such as “Buy in” and “Executive sponsorship.” I would hope that in most cases you are building your Roadmap to satisfy the business need for such a thing, so I’m going to skip the politics and get to the point — building the tool itself.

Identifying your business needs and business objectives (let’s call them “needs” henceforth) may seem to be the least difficult part of the process, actually it could quite easily be the most painful portion. I recommend a combination of interviewing staff, and workgroup meetings to extract the information you need. Rule out any issues you can solve with process changes, then Sort, Combine, Eliminate and Discard others as necessary.

As a general rule of thumb, you’ll find that many needs are closely related. For instance Sales may wish to have a web based product catalog and ordering system; Finance wants an online invoicing system; and Marketing may desire a centralized location for press releases. By Identifying and prioritizing your business objectives and combining or unifying technology concepts, you will be distilling your technology initiatives into a single solution. A word of caution here, don’t over simplify. Where multiple smaller requirements may need to be combined and satisfied, some larger requirements may need to be broken down into smaller more palatable components.

Once you’ve defined your issues and objectives, start laying out the time-line (I like to use stickies on a whiteboard for this part.) If you have certain goals that need to be accomplished due to business requirements (release dates, important calendar dates, etc.), prioritize them over others. This is quite literally a time where the company must evaluate the importance of one goal over another, and should not be performed in a vacuum. Corporate politics aside, it is important that all stakeholders partake and validate or correct any assumptions.

Smaller or less important tasks that can be performed in parallel should be noted as such and prioritized in a separate time-line.

You will have to revisit these time-lines quite often in the process, especially once you’ve moved on to budgeting. Some projects may need to be de-prioritized due to cost and market conditions, others could be prioritized based on various things such as vendor “end of quarter” discounting, and other incentives that are available.

Now, we move on to mapping the dang thing out. For each need, let’s identify a technology solution — if you are unaware of a solution, set it aside as a research project for later, you may need to more clearly define the problem and desired solution. Remember the non-step-4? Review and update! It’s okay to come back to any step as necessary.

Again, multiple needs may have a single technology solution. As another example: A professional services company may have a desire for a work tracking and request system, the Finance department may require an automated invoicing system, while Field Services may need to track time, expenses and travel. Combining these needs into a single system can save money, eliminate duplicate data entry, reduce errors, and potentially solve other needs in the future.

Which bring us to another point to consider: When evaluating a technology solution for one need, try to consider all the needs at the same time; Are you creating new needs as a result of your decision?

Remember, at this point, you are not identifying specific point products to solve problems. You are merely identifying technology solutions. Be sure to call out the technology; avoiding specific vendors and products will allow the company more flexibility when it comes time to research and implement a solution, as it avoids preconceptions and misconceptions: “Hey, why did we go with Exchange, the TRM says Zimbra!”

Some simple advice when it does come time to research and implement: Keep your end goal in mind when choosing products, try to choose the same type and manufacturer of products. If you are a windows company, it’s probably best if you use products that work on windows, since you already have the talent in house to maintain such systems. Open source, while “free,” comes at a price — you will lose critical support when you need it most, unless you are willing to pay a premium for services.

Unless you have a compelling reason to use multiple vendors, don’t. Remember it’s always nice to have a “single throat to choke” rather than multiple vendors pointing fingers at each other. I realize this is a long standing debate (”placing all your eggs in one basket”) so a decent work around to a multi-vendor approach to minimize finger pointing is to have a single reseller for your technology. Let them handle the unruly bunch of manufacturers, it’s part of the “value” most resellers provide. If you buy Cisco, stick with Cisco, if you buy Juniper, stick with Juniper where possible.

… but I digress.

Ok, You’ve defined your technology options, and your time-line. Now put it on paper and figure out when actual technology decisions need to be made within the time-line. Go ahead and schedule the review and planning sessions. Now you have an itinerary for your Roadmap that determines when you should be making decisions and having group meetings about the next steps. Share the Roadmap with the company, and solicit feedback for the next planning session.

Each review and planning session should help you to identify budgetary concerns, personnel and staffing recommendations, and of course other dependencies (such as network bandwidth, hosting, licensing, capacity issues, and so on.)

Now execute.

And there you have it. The most basic of Technology Roadmaps.

Seriously folks, it doesn’t have to be complex, it just needs to be done:

Quickie summary:

1. discussed it
2. document it
3. share it
4. follow it
5. update it

So, put that GPS away, and start small. Until next time, happy travels, have a safe trip, and be sure to check your Roadmap frequently to ensure you’re not getting lost along the way!

[Update May 19, 2009]

Other Reading:

California Board of Equalization: The 2020 Plan, Roadmap to the Future [pdf]

Discussion of the BOE plan at the CIO Academy (Feb 2009):

Strategic Planning: Exploring a New Model [pdf]

This entry was posted on Wednesday, April 29th, 2009 at 11:40 am and is filed under IT Management, IT General, Articles, LinkedIn.