P.G.Daly's Intranet Talk
A Software Rollout Roadmap

By P.G.Daly

Printer Friendly Version

Having recently experienced my first software rollout on a large scale (in this case it was division-wide), I came to the conclusion that there are several categories of tasks that need to be addressed in any software rollout. So, whether you are rolling out client software for a business application, a web authoring tool, or a document management system, the following roadmap should help you out.

Essentially there are things that your customers care about, things that IS cares about, and a few gray areas that you both care about at some level. The important key to communicating and working with your customers is to tell them about the things that impact them and that they care about rather than overwhelm them with irrelevant (from their perspective) details. Truly, your customers don't care much about the bang up job you did on the back end migration. They only care that you completed this step bringing the project closer to the milestones that impact them.

After plowing through several projects plans, consolidating, and generalizing, I arrived at the following top-level tasks that need to be considered in any software rollout project. Since detailed tasks in each of these categories naturally overlap, I present them in no specific order.

Requirements Gathering
Every project whether it's software rollout, application development, or infrastructure must encompass this phase. Even though IS people can occasionally lose sight of the following core belief, it still holds true. Technology is an enabler for the business. Therefore, the customer is king and their requirements drive the project. The most effective way to gather requirements involves actively including customers at various levels within the organization hierarchy. After all, what is important to the vice president in a particular tool is not the same functionality that matters to an administrative assistant. Educate your users as part of the requirements gathering process, and ensure they review the actual requirement documentation for their areas. This will help to ensure that everyone is on the same page before you build or deploy the tool.

Design Documentation
I can never say it enough. Well-written and thorough documentation is critical and is what will save you and your team from being up a creek without a paddle some day in the future. Whether you write it yourself or hire a talented technical writer, make sure you take the time to do it right. A verbose Word document listing a pile of system configurations is not an effective design document. Consider a little plain English and a workable format when you start typing away. A little time spent organizing this up front will pay many dividends along the road.

Procedures
Procedures are an often-overlooked area in the same class as documentation. Yes, I agree some people can get procedure happy and lose the battle of form over function. However, clear procedures both for customers to follow once the tool is rolled out as well as procedures to define how your rollout team functions during the project are crucial to drive consistent and acceptable behavior.

System Administration
Who will be responsible for system administration responsibilities? Will basic responsibilities be decentralized with the users? Will a central support team or the project team handle these tasks once the rollout is complete? Assigning "power users" in the customer base to handle basic administration tasks is often preferable in order to free up IS resources and empower the customers to take ownership.

Environment Setup
Depending on the tool and the scenario, environment setup and configuration can be a small task or a behemoth of a task. If you are dealing with a standalone client only based tool, you should have limited environment configuration responsibilities (assuming you have a standard desktop model in your company of course). If you are dealing with something more complex like rolling out a client application for a document management system and you are also upgrading the backend system as well, the environment configuration requirements can be significant. Although necessary, these tasks can be hopelessly tedious and brain numbing to your rollout team speaking from personal experience; so, be sure to split these amongst your team members.

Testing
The project's world will not spin freely on its axis without a good dose of Quality Assurance Testing. Although no amount of testing will protect you 100% from things that go bump in the night, a thorough amount of testing by both the technical team and customers is necessary for a successful rollout. Whether it's an internally developed application or a 3rd party piece of software, no doubt there will be bugs and unadvertised "features". Pound on the tool as much as you can and use a combination of automated testing tools, regression testing, and good old-fashioned user testing. Resolve as many issues as you can up front by either fixing the problem and/or creating a known issues list depending on your degree of control over the resolution.

Vendor/Consultant Relations
Oftentimes you are rolling out a 3rd party software product. Therefore, your relationship with the vendor is crucial to getting issues resolved and receiving the support you need in order to work with and deploy their product(s). Sometimes, in addition to managing the vendor relationship, you must also manage consultant relationships. Whether you are dealing with a consultant for team augmentation, training resources, or some other facet of your plan, effective relationships are a must.

Communication
In my opinion communication is the most overlooked ugly stepchild in many projects. Unfortunately, it often comes as an afterthought. The time is now to wake up, smell the coffee, and realize that communication not only within your team but also with your customers is one of the primary keys to success. Plan your communications as you would any critical path technical task. It is that important. This does not mean to overload your customers with communications (that is analogous to and begs the same result as crying wolf). Instead, you must deliver concise, effective, and timely communications. Keep it short, keep it simple, and tell them only what they need to know. Whichever pneumonic or school of thought you want to follow is fine, just do it and do it well.

Rollout
You need to consider how you want to rollout the tool. Determine whether you plan on conducting pilot rollouts, phased rollouts, or a combination of the two. When I refer to a pilot rollout, I am referring to a focus group type scenario. You rollout the software to a select group of people, have them work with the tool, and then gather feedback to determine if the product is ready to consider deploying on a wider scale. In the pilot rollout your focus is on the tool and its usability, functionality, etc. With a phased rollout, you deploy the software to one or more groups to determine if the deployment plan and tool is working as expected. You may start with a small group (perhaps using IS as a guinea pig in case the plan falls flat) and then expand to larger groups before deploying to your entire customer base. In a phased rollout you are focusing your test less on the product itself (though you want to obtain feedback and possible trouble spots) and more on your deployment plan.

Support
Who will support the new tool? Will it be the project team or will it be the regular desktop and help desk organization? It is important to make it clear to the customer that they need to direct their support requests to the correct group from the start. Otherwise, it will be hard to change their behavior later. Make it easy for customers to get support and make sure the support staff will handle requests correctly and consistently. If it is a totally new tool to your organization, consider training the support staff so they can benefit from the lessons you have learned during your evaluation and testing process.

Training
If it's new, they must be trained. Any new software whether it is an upgrade or an entirely new tool requires that you provide a certain degree of training to users. Keep in mind that users have different styles of learning and try to offer training that speaks to these different styles. Some users like to learn on their own using CBT, web based training, videos, or printed materials while others will only feel comfortable if taught by an instructor. Consider partnering with internal or external resources that specialize in training and development. These professionals know the ins and outs of instructing users and how to most effectively present training information.

It all sounds so simple, doesn't it? The reality of it is that each of these categories of rollout tasks can take on a life of their own once you drill down into the details. However, if you at least start with a broad roadmap for success it makes the project ahead more manageable.

Once you've successfully rolled out your software, the journey does not end. Do not forget to address the following:

Measuring Success
How do you know if your rollout was successful? Do you consider successful installation the barometer? Customer usage? A hard dollar cost reduction? Sometimes you not only have to evaluate success based on tangible measures but also behavior modification. Although how you measure success will depend on your situation, make sure you allocate some time and thought to this topic. In this way you can provide feedback to your customers as well as measure your performance against stated objectives (after all, you're hoping your bang up job on this project gets you noticed by the boss and results in a raise or promotion, right?).

Follow Up with Customers
Follow up with customers to ensure their requirements were met. Whether you choose to do focus groups, surveys, or face-to-face meetings, get your customers' feedback. This will not only help you to measure success but also take appropriate action regarding support of and future releases of the software.

As always, comments, complaints, and suggestions are welcome at paulag@enter.net.

Printer Friendly Version

More Intranet Talk

P.G.Daly's Intranet Talk: A PDF Primer (Part II): Last time ( A PDF Primer Part I)I told you all about why you would want to use PDFs in the course of your work. I know you’ve been waiting for the how…. so without any ado, let’s cut to the chase and create some PDFs!
P.G.Daly's Intranet Talk: A PDF Primer (Part I): What I learned in my last job is that many people aren’t sure when is the best time to use a PDF versus an HTML file versus some native application file for given web content. In addition, people aren’t always sure how to create them and some people wouldn’t know how to view them if the tech support staff didn’t already configure their computer properly so it “just happened” in the background. In this two article series, I plan to give you some rules of thumb for when to use PDFs versus other types of files as well as a quick primer of the different ways available to create PDFs and when to use what.
P.G. Daly's Intranet Talk: Your Webmaster Calls it Quits. Are You Prepared?: Your Webmaster delivers the news that she is leaving for new challenges. Are you prepared? Do you have any clue whatsoever what she does? Have you had any cross training with other Web talent in your organization? For that matter, do you even have other web talent in your organization?
P.G. Daly Intranet Talk: Basic Intranet Guidelines and Standards: P.G. Daly found getting the decentralized businesses in her company to accept intranet standards akin to herding cats, but less enjoyable. In response to never ending inquiries about what skills are required to author web pages, get access to do so, training, and the like, she revamped her standards and guidelines. Given the environment at her company, the limited authority afforded intranet professionals, and the need to lay down the law at least on certain issues, she created a basic framework by which content authors must work. The following article takes a glimpse at the guidelines she setup.
P.G. Daly's Intranet Talk: Using the Intranet to Improve Internal Sales Communications: Can you imagine a sales force roaming the countryside selling products without access to up to date customer information? Well, then you can imagine P.G. Daly's reaction when one division explained to her that a third party vendor maintained all the customer data for their division and that the only way salespeople could get this information was to phone the third party vendor, have them run a report, and then have it sent via fax or mail. Certainly not the most efficient or cost-effective process on the planet. Why not use the Intranet?
P.G. Daly's Intranet Talk: Giving the Intranet a Facelift: After much ado and a very long wait, I recently gave my Intranet a new look and feel. Originally, the project was supposed to encompass a number of process and procedural changes as well, but these got sidelined in light of a number of political and resource roadblocks. Nevertheless, I decided there were enough improvements to be had with just updating the look, feel, and navigation of the Intranet, so I forged ahead.
P.G. Daly's Intranet Talk: A Sure-Fire Way to Drive Traffic to the Intranet: After her last column, people asked P.G. Daly about other big success stories from her intranet, so she thought she'd share another "real big one" with you. One of the most sure-fire ways of driving traffic to your site is putting something employees absolutely need on the site and making that the only way they can get it. Sound simple? It can be (at least sometimes).
P.G. Daly's Intranet Talk: Using the Intranet to Improve Internal Sales Communications: About a year ago, one division of P.G Daly's company came to her with the problem of disseminating weekly sales reports. The problem was that they had about 60 sales people across 2 different sales forces (product lines) that had to submit sales reports to the corporate office on a weekly basis. These reports needed to be distributed to an audience of 40 or more people from regional sales managers to upper management. The process in place was to have everyone e-mail their weekly report (in a Microsoft Word Format that had a common template) to an Administrative Assistant who would photocopy and assemble packets that got sent through the regular inter-office mail. Needless to say, this occupied a good piece of this assistant's time the beginning of each week and wasn't the most timely distribution of information. This article shows how P.G. Daly and the company's Intranet came to the rescue.
Intranet Talk: Thoughts on Intranet Directory Structures: Recently, a number of people have asked P.G Daly questions about directory structure for Intranets. Namely, what is the best way to structure folders and files for my site? This question is valid both in the macro sense of an entire Intranet as well as for each individual author creating their own little piece of the pie. So, she got to thinking about how effectively she set things up on her company's Intranet many moons ago. What does she recommend as good practices? What would she suggest avoiding?
Intranet Talk - The Intranet Users Have Spoken Part III: Designing and Conducting the Survey: Many readers want to know how P.G. Daly designed and administered her intranet usage survey. Rather than answering a number of e-mails privately, she thought it would be best to share these details on the survey experience with everyone, so as to help readers implement their own intranet survey and put this knowledge to good use.
Intranet Talk: What Happens When the Intranet Users Have Spoken? Part II: In her last column, P.G. Daly shared with you the key conclusions from her recent Intranet survey. This time, she'd like to address the answers to the important questions of -- What do users want to see? What would encourage them to use the Intranet more often? And, most critical, what recommendations and actions does she have planned to address some of the biggest issues?
P.G. Daly's Intranet Talk: What Happens When the Intranet Users Have Spoken?: After over 18 months since the intranet was "officially rolled out", it was time to formally ask users if they were using the intranet or not and to find out what they found useful or useless as well as determine what would get them to use it more. Here's how I asked went about sending out and intranet survey and the type of feedback I recieved in return.
P.G. Daly's Intranet Talk: The Technical Skills Required of an E-Business Organization: Your Company just formed an E-Business. What technical skills does this organization need to be successful? Even if most of the large technical projects are outsourced, surely the group needs a core of technical skills to do some development and maintenance in-house, and even more importantly, to understand what systems are being implemented by these vendors and how it all fits together.
P.G. Daly's Intranet Talk: The Intranet Top-Down Sell or Grassroots Effort?: Unless you are in a high-tech company, or just plain got lucky, there is a reasonable chance that upper management is not quite as active in their support as you might like. So you're building the success of your intranet one "worker bee" at a time with some degree of grassroots effort at play. Can you truly grow an intranet organization-wide one person at a time? Maybe not quite that slowly, but you can increase usage and usefulness one niche at a time.
P.G. Daly's Intranet Talk: How Others Create and Manage Intranet Content: P.G. Daly's recent articles on creating and managing intranet content ("Creating and Managing Content" and "Authoring Tool Standards: Critical? or Form Over Function?") generated an overwhelming response from readers. In this column, She shares some of the most helpful comments and insights.
_P.G. Daly's Intranet Talk "What is the Technical IQ of your Company? The life of your Intranet Could Depend on it." _: No matter how flashy the design, advanced the technology, or just plain cool your intranet is, the question still remains: are people using it? Although all companies have users on both ends of the PC savvy scale, overall, how would you rate your company's Technology IQ?
P.G. Daly's Intranet Talk: "Authoring Tool Standards Critical? Or Form Over Function?": What about new authors or PC savvy folks in an MIS Department that want to publish content? Should they be forced into the "old" standards or allowed to branch out and try a new approach?
P.G. Daly's Intranet Talk: "Creating and Managing Content": Content is king for an intranet. Yet if content is so important, and users desire it, why is it so difficult to create and maintain large amounts of information on a company-wide scale?
P.G. Daly's Intranet Talk: Organizational Structure and Its Impact on an Intranet?: As Intranet professionals, we tend to think most about technology (if we are techies), design (if we are designers or artists) or functionality (if we deal with the business users). But how often do we consider the basic organizational dynamics of our company?
P.G. Daly's Intranet Talk: "Build It And They Will Come?": "Build It, And They Will Come". It may have worked for Kevin Costner in the movie "Field of Dreams", but chances are this philosophy alone won't work for your company's Intranet.

P.G.Daly's Intranet Talk
A Software Rollout Roadmap

Whitepapers and eBooks

Webcasts

Downloads and eKits

Tutorials and Demos

P.G.Daly's Intranet Talk A Software Rollout Roadmap

Whitepapers and eBooks

Webcasts

Downloads and eKits

Tutorials and Demos

P.G.Daly's Intranet Talk
A Software Rollout Roadmap