A question I hear frequently from Forrester clients: “Which WCM is the best for our organization?” My nearly universal response: “Tell me your priorities.”
Rarely is there one “best WCM” that meets all of a firm’s objectives for web content management and digital experience, so let’s dispel that myth right now. Instead, it’s a trade-off where your specific requirements should influence your investigation, direct you to a shortlist, and help you make an informed choice.
The WCM Wave Report (and the accompanying Excel with detailed product capabilities) is a powerful tool to help enterprise buyers compare solutions. It’s helpful only if you have some idea of the problems you’re trying to solve and the strategic opportunities you need to focus on.
Priorities matter. Or, more accurately, your priorities matter. Your priorities are different than those of the company across the street. It’s a big and confusing market, too. Although we cover 10 WCM solutions in the Wave, there are many additional viable solutions.
Revolutions take two forms. The most familiar kind is the noisy, conspicuous, disjunctive event that marks a clean break from the past. Yesterday, George III was our monarch. Today, he's not. The other kind of revolution is a more gradual and subtle event, when multiple forces pointing in the same direction push people into a new world. The shock of Pearl Harbor, the power vacuum left by a devastated Europe and Japan, a reinvigorated economy, and an aggressive superpower adversary made Americans feel, for the first time, that they needed to be far more deeply involved in international affairs than ever before. Without any formal declaration, Americans became internationalists after 1945.
Something like that second kind of revolution has happened with software requirements. Over the past decade or so, organizations grew increasingly worried about the problems that took root in bad requirements. The problems took many forms (portfolios filled with applications no one was using, users unhappy with the software that complicated their lives more than helped them, ideas that no one vetted carefully, etc.) and arose from just as many sources.
All of these discontents pointed in a common direction: Take requirements more seriously. In Forrester's Q1 2011 Application Development And Delivery Organization Structure Online Survey, "improvements of requirements" appeared at the top of the list of initiatives that would improve software development the most.
A new business model is emerging, and it depends heavily on software development. Many companies are dropping many of the traditional barriers between product development and customers. Without investing in software development, these efforts, no matter how well-intentioned, will have a better chance of failing than succeeding.
The simplest term I can concoct for this business model is "the transparent company." There are other defining characteristics of this corporate strategy, such as confidence in the ability to execute, and a very different sort of relationship with customers. However, as companies have been decidedly opaque to their customers, any transparency is a striking detail in itself. Hence the term "transparent company."
Wave Hello To The Engineer Fixing Your Bug
Here's an example of what I mean. I don't have to be a customer of Atlassian to know what issues Atlassian's engineers will fix in the next release of their wiki product, Confluence. That information is publicly available at this link. Diving into an issue at random — I chose "Database deadlock during initialisation of plugins in sql server" because it sounded fairly dire — I can see which engineer is working on this issue, Don Willis. I can even see the daily activity stream for Don Willis as he works on this issue and other projects.
It's a real pleasure for me to be able to bring you some insights that emerged from the Forrester Leadership Board's Application Development & Delivery Councilduring 2010. My colleague Julia Spencer, an Advisor to the council, has written up these insights, which I have pasted in below, but we are inviting you to enter the discussion as well. Thanks, Julia, for bringing us this wisdom and for helping us get a peek inside this exclusive community of application delivery leaders:
From Julia Spencer:
During 2010, the Forrester Leadership Boards’ (FLB) Application Development & Delivery Council (AD&D Council) tackled many issues, including that of defining and managing requirements for more-effective application delivery. As a Council Advisor, I receive many questions about requirements, such as “How do you define a quality requirement?” I’d like to share some best practices revealed during our Member Meetings in Las Vegas, Nevada, and Lisbon, Portugal, and our highly interactive CouncilTel (FLB group discussion) on software requirements.
I’d love your feedback: Which best practices have worked for you? What is missing from the list?
First: What are requirements, and why do they matter?
I have learned that the word “requirements” means different things to different people, and some struggle to define the word altogether.
During a briefing earlier this week, Jama Software's CEO Eric Winquist showed us a slide separating the repository of a requirements management system from the collaboration that happens around requirements. I really liked the slide because it nailed an important point about both the requirements process and the tools that try to support it.
Ever had one of those "So what?" conversations about requirements? The one in which someone looks at your carefully crafted bit of product requirement genius and says, "So what am I supposed to do with it?" If not, you probably haven't been a PM, so you should stop reading now. If so, you've experienced first-hand that requirements are not just a big Lego box full of information, from which people will easily construct something meaningful. Or, to use a different metaphor, the requirements repository serves the function of a dictionary, describing the things that matter in the universe of technology that we can build. No matter how big, precise, current, or clear the individual bits of information may be, they don't automatically add up to something that someone could use.
The first generation requirements tools were, in essence, dictionaries. Like the Oxford English Dictionary, an important measure of its success was completeness. Since the human brain couldn't retain and organize this information effectively, and Microsoft Office proved to be incapable of handling information complexity, then teams embraced tools like Borland (now Micro Focus) Caliber and MKS Integrity.
[Another interesting finding about the requirements tool market, from research by Yours Truly and Mary Gerush. For other observations about this very interesting market, click here and here.]
As organizations improve their requirements practices, and as the requirements tool vendors adapt in response, the front end of the requirements process is getting a disproportionate amount of attention. Many requirements defects start early, with the information that you feed into the requirements-generating machine. For example, if you don't have a clue how criminal investigators work, you're going to make basic mistakes in feature prioritization and design when you build a case management system for them.
And it's not just the information that has fallen under suspicion. A lot of people are equally worried about the other raw material, ideas, that you feed into this machinery. Here are a few commonly cited concerns:
The just-published overview of the requirements tool market is, at bottom, a story of unrecognized success. The requirements tool market has grown rapidly along several measures, including the number of vendors, the scale of adoption, and (the primary focus of the overview) the number of business problems that these tools are designed to address. From a small niche in the software market, requirements tools have grown and evolved, sometimes merging with other applications, to the point where it's hard to talk about them as "requirements tools" in the strictest sense of the term.
When colleague Mary Gerush and I dove into the primary research, we were immediately struck by the number of vendors that have crowded into a space that, to be honest, was not too long ago treated as a bit obscure and unexciting. The longer we looked at the market, the more little vendors appeared in the landscape. We'd heard of long-standing specialty vendors like Ryma, Blueprint, and iRise, but names like TraceCloud and AcuNote were new to us. The big vendors, too, have seen opportunities in this space, sometimes buying (for example, IBM's acquisition of Telelogic), sometimes building (such as Microsoft's Sketchflow tool).
Something was happening in this market, and at least a piece of the explanation was clear from the moment we started talking to vendors and users. Very few of these applications were exactly like the first generation of requirements tools, such as MKS Integrity and Borland (now Micro Focus) Caliber, and most of the newer tools bore little resemblance to each other. Although they share the title "requirements tool," they don't deal with the same aspects of requirements.
The Australian product management consultancy brainmates just published the results of a survey on a very interesting topic, social media usage among PMs. The short list of questions get right to the heart of the matter: Do you expect to be using social media more?
The brainmates survey indicates that PMs are ready to embrace, or bracing themselves for, social media as an increasingly useful tool for product marketing, product feedback, and collaboration. In contrast, PMs do not expect to be increasing their use of social media for monitoring "to find references to their products or services and any references related to their market, customer segments or competitors." Interesting, especially given how much electronic ink that social medianiks have spilled about using Twitter, Facebook, et al. to see ourselves (or our brand) as others see us.
In the tech industry, the "tell me a story" approach to product requirements – personas, user stories, use cases, visualizations, etc. – has made a bigger impact than many people may realize. Not only has this new type of content resolved many problems that existed with requirements, but it has led to a brand new way of looking at requirements. By thinking of requirements as stories, it's easier to figure out what kinds of requirements we need, and why we need them.
A tale of two mini-series
The fundamental question when writing any kind of story is, "What are you trying to convey?" I was thinking of exactly that question while I was watching the HBO mini-series The Pacific. I probably wasn't the only person to expect The Pacific to be the same kind of story as Band Of Brothers, just transplanted from the European to the Pacific theater of operations. I was wrong.
As it turns out, the new series has a very different kind of story to tell. Band Of Brothers depicted the experience of combat, in (literally) gory detail. While The Pacific does have more than enough battle scenes, it also tries to show military life beyond the battlefield. For example, one episode focused on the painful romantic choices that young people stationed in faraway lands have to make. Another episode depicted something rarely seen in war movies, the psychiatric casualties of war. Far more than Band Of Brothers, The Pacific shows more of the atrocious things that young men under brutal, terrifying conditions are capable of doing.