Managing Chaos. Lisa Welchman
Читать онлайн книгу.
that people like me who knew only enough HTML and UNIX to be dangerous were let loose on the live production servers of major corporate websites to do whatever we wanted. At Cisco, we invented a lot. We laughed a lot. We accidently erased content a lot. (I remember accidently replacing the Cisco.com homepage with the Japanese Cisco.com homepage once.) The Web team tried almost any idea because there were no rules. The norm was to make it up as you went along. And we did. It was fun, and it couldn’t have happened any other way.
FIGURE 1.2 The original Cisco site in 1996.
But, in the years I was at Cisco, I noticed something. Cisco Systems was the epitome of all things Internet and Web. It wasn’t just that it sold routers, hubs, and switches. It wasn’t just that Cisco installed a high-speed Internet connection in its employees’ homes. Cisco as a company was serious about using the Web as a business tool. In 1996, Cisco had all its technical documentation online, downloadable software images, a robust intranet, and a rapidly growing B-to-B ecommerce model. But, despite all of this cutting-edge use of the World Wide Web, Cisco still had a lot of problems managing its own website.
There were internal debates over homepage real estate by various business units. There was an ever-present debate about who (the marketing team or the technology team) ought to be selecting and implementing key website technologies like search engine software and other, then newer, technologies such as Web content management systems and portal software. At almost every meeting about the website, more than half the time was spent not actually determining what type of functionality needed to be implemented, but on who got to decide what functionality would be implemented.
Competing factions would show up at meetings with different website designs, information architectures, and technologies, and the debate would go on and on. People would get angry. Managers would fight. Office politics raged. But after all the drama, the solution usually ended up being that no decisions were made. We left the room only to come back for rounds two, three, and four once tempers had cooled off. What that meant in practical terms was that often multiple competing technologies were deployed and multiple website designs implemented—each area implementing its own vision over the part of the site that it “owned.” The result was a graphically diverse, incongruent website with a confused information architecture.
And I was part of the problem. I was part of the marketing team that felt that we owned the whole site—because websites are communications vehicles first and foremost, right? The evil nemesis on the other side of our debates was usually the IT team, who was constantly pointing out that the website was first and foremost a technology. I wasn’t thinking about governance per se back then. But, being tasked with leading the team to select the first content management system for Cisco Connection Online, I was frequently caught straddling the line between marketing and technology. I was beginning to see that both teams had valuable contributions to make, not only in the selection process but also in the overall running of the site. Still the battles raged on.
Eventually, the cross-departmental content-management product-selection team we had assembled narrowed our candidates down to a single vendor. All the stakeholders (marketing, IT, hands-on Web folks, managers, and senior managers) assembled in a conference room. We’d written a requirements document, installed and tested the software for months over a number of use cases, negotiated pricing, and pretty much driven the vendor crazy. It was time to make the decision. Both the vendor’s implementation team and the software had passed all of our tests and the price was right, but still the people around the table were reluctant to make the commitment to buy the software.
There we were: the right people around the table, the right solution in front of us, and we still couldn’t make a decision. That’s when I began to understand what was really going on. It wasn’t that we couldn’t make a decision because we weren’t sure about what the right solution was; we couldn’t make a decision because no one really knew whose job it was to say “yes” or “no.” I also began to realize that the uncertainty didn’t stop at CMS software selection, because no one knew whose job it was to decide anything about the website: content, design, information architecture, applications, and on and on. And, without that clarity about decision-making, the extended digital team at Cisco could argue about the website pretty much in perpetuity.
The Cisco Web team had a governance problem.
In a moment I’m still proud of, I stepped forward and broke the stalemate by assuming the authority that had never been formally placed. I said, “Let’s do it. We’ll be at greater risk continuing to manage our content the way we do now than if we implement this CMS.” Thus, we moved forward.
I liked that feeling of breaking stalemates and helping Web teams move forward, and I wanted to spend more time with my four-year-old son. So I left Cisco in 1999 to become a consultant. By then, the scope of Cisco Connection was off the charts (over 10M Web pages, 200,000 registered website users, and 400 content developers worldwide). I figured if Cisco with all its Web smarts found it hard to manage its website and Web team, other companies with the same problems probably would need help as well.
They did.
Fast-forward to today. My son is in university (see Figure 1.3), and on a typical day, I pick up the phone, and it’s a call from an organization that is having trouble managing its Web presence. Maybe it’s a large, global company with over 200 websites in many different languages. Or maybe they aren’t really sure how many sites they have or who is managing them. Perhaps their main site was hacked several times last year, and some of their customer personal information has been compromised. Maybe it’s a national government trying to figure out how to govern its national Web presence. Or it could be a university with a lot of headstrong PhDs who want to do their own thing online and a student body that expects an integrated user experience from their university.
FIGURE 1.3 It’s 18 years later, and he’s on his way to university.
Usually, our conversation starts with the clients telling me how they’re going to solve their problems. I hear the same solutions all the time. Most digital and Web managers try to design their way out of a low-quality, high-risk digital presence with a website graphical interface redesign, a new information architecture, a technology replatform, or a content strategy—and everything will be better. Often, it is better for a few months or a few quarters, and then the digital system begins to degrade again. Maybe a few rogue websites have popped up, or the core digital team finds out that there are a bunch of poorly implemented social accounts. This scenario happens over and over again because organizations haven’t addressed the underlying governance issues for their digital presence.
Along with fixing websites or applications and strategizing about content, organizations need to undertake a design effort to determine the most effective way to make decisions and work together to sustain their digital face. They need a digital governance framework. But, often, when I tell organizations that (another) redesign or CMS probably isn’t going to fix their problem and that they need to take the time to address their governance concerns, I often get all kinds of pushback:
“We work in silos. That’s our culture. We don’t govern anything!”
“We need to be agile and innovative. Governance just slows things down.”
“We don’t have time to design a digital governance framework.
We’ve got too many real problems with our website.”
In the face of a 15- or 20-year-old technically incongruent, content-bloated, low-quality website, here’s my challenge:
• Isn’t it better to take