It was 1997 and the World Wide Web was catching on. I was a magazine editor in charge of a medical technology publication with a readership scattered across Latin America. Miller Freeman, our publishing house, was building simple home pages for the bigger magazines, but my tiny niche was not a priority.

There was no explicit rule about websites, however, so many of my colleagues and I were having fun exploring HTML on our own. I quickly became obsessed and, despite my boss’ insistence that the Internet was a low priority, had soon built a website, forum and the world’s first (as far as I know) online bilingual radiology glossary. Though—shockingly—my effort was passed over for recognition by the Nobel committee, the website lived on for another decade as I became editor in chief of Software Development magazine. There, we continued to evolve our Web presence, albeit under stricter IT guidelines.

The Web and Java were special cases of technology that were not only revolutionary, but also accessible to the masses. Could the iPhone or social media applications be today’s equivalent? Even if they are, in 2010, there is a daunting ecosystem of software, hardware, platforms, vertical domains and methodologies to choose from. While technology land grabs still occur, most organizations don’t face such dazzling options when it comes to making a major change. And employees are practically inured to novelty, now that it occurs 24/7. In the face of these challenges, how do you bring your team up to speed quickly, smoothly and cheaply?

Let them play with it: Autonomous motivation
Fostering change organically is an explicit strategy for some companies. Google is famous for letting its employees spend 20% of their time exploring technology or working on projects of their own design. The science of workplace motivation seems to support such an approach, too; some studies have found that creative solutions to problems actually decrease under external pressure such as deadlines, bonuses or major prizes. But allowing employees to simply explore often makes managers nervous.

“I worked for IBM Research in the 80s, and we were supposed to take some part of our time off for exploration,” said Salt Lake City-based software development author and methodologist Alistair Cockburn. “As far as I know, I was the only one who actually did it. My boss was totally terrified because 20% was being siphoned off into non-productive activity.

“You hear rumors of how Google works, but how they say they work and how they really work are two different things. The problem with this approach is how many people are really doing it and how much management nervousness they absorb in the process.”

For a more predictable result, Cockburn recommended giving developers a certain amount of free time to explore a specific technology, such as developing iPhone apps. The goal is for the effort to be distributed across your organization. “Have everybody go take two days a week, every Thursday and Friday, for the next month, and program whatever they want for an iPhone app. At the end of the month, you have a bunch of people talking about it—everyone is on the same topic,” he said.

If the budget is a concern, try making the exercise profitable to begin with. David Leigh-Fellows, Silicon Valley-based principal consultant at ThoughtWorks, described a client that required every new project in order to reapply for more funding at the end of three months. “But you had to have built a new variation on the business case. This mentality forced people to think, ‘How do we get into the market? This is what we’ve built and tested, we think it will give us this revenue, and we’re ready to launch.’ It worked beautifully.”

It’s also wise to scatter the seeds of new technology widely. This mitigates the flight risk of letting, say, your top two architects become experts in an in-demand technology. With cultivation, change can root deeply in teams that are a cross-section of the company, not just elite cliques or rogue forces.

Stronger than trickle-down
While some concepts spread easily via self-organizing efforts (agile methodologies such as Scrum (at least among developers), or exciting technology with high perceived value), other changes are DOA without a strong leadership mandate and effective training.

Getting a company ramped up on a new platform such as Microsoft SharePoint, for example, is often fraught with difficulty, according to Laura Rogers, senior SharePoint consultant with SharePoint911. “In many situations, a company’s IT department has already ‘rolled out’ SharePoint by simply propping up a server farm. But in lot of cases, they don’t take it any farther than that, and wonder why no one is using SharePoint.”

People need to know how SharePoint applies to them, which is often simply a matter of showing them the document collaboration or search capabilities, she said.

Governance is also a major factor, starting with, in some cases, a mandate that everyone is required to use SharePoint, not file shares, for all document collaboration. “A good formula is to deem one or two individuals from each major department in the company as site managers/power users,” said Rogers. “Give them thorough training on how to manage their own sites.”

General site users can be started off with simple training on document collaboration and search, but, she cautioned, “Be sure not to overwhelm the people at this level.” Once the general population has used the basic functionalities and is accustomed to performing simple tasks, the next phase is to identify specific business processes that can be made more efficient with SharePoint.

“Simply put, you can’t usually just ‘turn on’ SharePoint and expect 100% adoption,” said Rogers. “It’s going to depend on training, governance and nudging the users toward using SharePoint for all of their business processes. You’ll see the light bulbs turning on over their heads more and more.”

Good governance is also required for policy changes around security, according to Gary McGraw, author of “Software Security: Building Security In.” “How do you make a huge development shop adopt a new thing, like what Microsoft did with their Trustworthy Computing initiative and Bill Gates’ memo in 2001? The answer is more political than technological.”

Step one is to get a leader to form a software security group that will work directly with developers on the security initiative. “In every single one of the 39 companies we studied for our Building Security in Maturity Model, all of them have a software security group,” said McGraw. “You have to have a senior executive in charge. There has to be a mission to make it happen. It’s not guerrilla, like agile methods; I have never seen that work for software security.”

Step two is to put power in the hands of the security team such that it actually has the authority to stop a release if necessary. Authority, however, will be unsustainable without the data to support it.

Marking the milestones of progress
Clarity of mission coupled with measurement is key. “If you govern in a blind way without measuring anything, you end up playing favorites and politics,” said McGraw. “You need science and real metrics. Getting back to your agile and Scrum, if you wanted people to adopt that stuff, the best thing is to get people to demonstrate that it matters from a business perspective.”

As with a diet or exercise program, defining and celebrating milestones of progress can be powerful motivators. Rogers said that once new SharePoint users understand the concepts of document libraries, columns and Web parts, they begin to use more types of lists like calendars, tasks and custom lists.

“Then they start asking questions about how to create more efficiencies in their departments. When they call you, the SharePoint implementer, with questions and ideas, that is definitely considered progress,” she said.

Another easy way to measure progress is to look at server performance: “IT can take a look at the performance impact and the amount of space that is being taken up on the SharePoint server,” Rogers said. Similarly, a team beginning to use agile methods might measure cycle time (the elapsed time from requirement or change request to deployment) at the beginning of its journey and periodically revisit the metric to see if it has improved.

Headed for a bumpy road, or a cliff?
Any change will hit obstacles, of course. Besides overcoming inertia and measuring progress as it unfolds, it’s crucial to implement the change correctly from the outset and train teams effectively in the new system, technology or process.

In the case of SharePoint, “One easy obstacle that should be taken care of by IT is to make sure that the hardware is up to par, and the server disk space is at an appropriate level,” said Rogers.

“Problems in this area can lead to a negative perception of SharePoint by the end users. People will not feel comfortable keeping their files in it if the server is unreliable. A lot of times, once the negative attitudes exist, it takes quite a while to reverse that thinking.”

Another obstacle is the fear of change. If employees have been storing their files in folders or following the waterfall software development process for 20 years, they may not want to learn a new way of doing daily tasks or iteratively discovering software requirements. “Keep it simple with this type of user. Show them basic functionalities and explain how this is a better way of collaborating,” Rogers advised.

Where buy-in is important, it may take more than just a verbal reassurance that change is an improvement. Luke Hohmann, author of “Beyond Software Architecture: Creating and Sustaining Winning Solutions,” has created a number of games that are perfectly suited for such situations.

“I’d recommend ’20/20 Vision’ to get clear on the reasons why the change is being promoted or implemented, ‘Speedboat’ to get clear on the issues with current state, ‘Product Box’ to get a shared understanding of the desired future state, and ‘Remember the Future’ to assist in helping the teams create a shared alignment for all of what they need to accomplish,” he said. Have the group draw a speedboat, which represents a system, technology or process. Next, individuals label and discuss anchors that are slowing the boat down. This helps separate trivial concerns from major issues in a socially safe way.

Training for success
Whether it begins organically or via executive fiat, failure to launch is all too common when everyone assumes expertise in the new process or technology will come naturally. Outside trainers and consultants are usually well worth the cost, ensuring that change is both long-lasting and effective.

“After your first poke at this thing with a stick, you’re looking at how you bring this into the company,” said Cockburn. “So you take your best person and put them on a team with a mix of people to build an app with the new technology. You’re doing risk reduction on step one, then starting to transfer the knowledge into the company on step two. The way to skip step one, which people were doing in 1990s, is you get an external consultant to lead the project.”

Assuming you’ve chosen the consultant well, this could be an excellent way to get teams up to speed with a new paradigm, such as the dynamic programming language and platform Ruby on Rails.

Training can be troublesome if not done correctly. Rogers described two extremes that she sees: vague, non-specific instruction and encyclopedic brain dumps. In the first case, “Users are trained, but without any specific demos or examples, so they have a hard time picturing how the technology applies to them and how they would go forth and use it on a daily basis.” In the latter, “Users go through training overload. They are required to sit through a full day of ‘beginner’ training. This is too much information at once. They become overwhelmed.”

However, when there is no training at all, Rogers said, site managers who lack a full understanding of the platform but have “owner” permissions on a site can do things that break the site. “This is not only a negative experience for the site owner and site users, but also for the IT department who then must fix what was broken,” she said.

Set your course
Change hurts, but there’s good pain and there’s the kind that makes you ball up into a fetal position. When the world is changing all around, you may not need to do anything to get your team on board, as was the case back when I and millions of others became self-taught webmasters.

Everything else is a little like training for a marathon: The end result will be anything but pleasant without a sound plan and consistent practice. So, read a few books, call a few consultants or trainers, prepare for the obstacles, define your milestones—and make that change.

Alexandra Weber Morales is a technical writer and contributing editor to SD Times.