How to Crowd-Source Requirements Gathering

In the Wisdom of Crowds, James Surowiecki observed leaders run the risk of being all tactics and no strategy unless they make sure that your day to day activity adds up to something bigger.

 

“Successful campaigns,” he writes, “may depend as much on the fast aggregation of information from the field as on preexisting top-down strategy.”

 

This is a sentiment many Web managers can relate to. In fact, one of the most frustrating parts of managing a large Web enterprise is coming up with a process to collect and prioritize ideas to fix bugs or make improvements. Ideas for improvements and bug fixes fly in from dozens of directions each day.

 

In the language of Web 2.0, the data is “crowd sourced.” Some of these ideas are golden nuggets while others are less necessary, bad ideas altogether or something that would make sense only if the budget were unlimited. How do you decide? Too often decision-making is done by the seat of your pants, or the proverbial “floating craps game”.

 

Imagine you are in the middle of a Web team with the responsibility of pulling together the priorities for the next release cycle.

 

The person who monitors feedback collects ideas from real users about things they find frustrating or things that are broken on your system and throws them over to the development team leader.

 

The requirements leader is trying to budget and schedule new spirals for adding new functionality into the system.

 

The engineers are bored with little fixes that keep piling up, and would rather chew on the big fat release coming down the road next year where they can show off their skill.

 

The content managers have pet peeves that they keep announcing as problems in every team meeting you host.

 

This merry-go-round of endless change and frustration is far too typical – but it is not as hopeless as it seems.

 

In a perfect world, every Web manager would embrace all ideas for improvement. In the real world, you do what you can, given the allotted time and resources.

 

This presentation shows how several creative concepts and frameworks were mashed up to create something new. The result is a workable system to rank and prioritize a focused Web development plan with a meaningful release schedule.

 

The Value Ladder: One Rung at a Time

 

The first concept is the value ladder. Because the field of usability is so far-reaching, it often leaves Web managers feeling overwhelmed and not
knowing where to begin. The “ladder” is a visual representation of what the user gains when Web managers focus on solid usability and packaging of the content they oversee and manage.

 

For the “awareness” and “satisfaction” rungs, at a fundamental level the question is: does it work? Moving from “awareness” to “satisfaction” levels comes before you gain “confidence” and promote “trust”. The idea of a sequence is important to a ladder construct. To get past the initial steps in the ladder you should do the basics well for your target audience -- the masses. The “loyalty” and “adoption” levels are where new functionality for your power users comes into play. Most of the time, this was about interactive features and functionality on the site.

 

Awareness. To move our users up the first step in the ladder, from “discouraged” to “aware”, you must make sure users have access to the content. For content that means three things: speed and reliability of the framework must be high, information must be accessible to qualified users and we must adhere to Section 508 guidelines for accessibility.

 

Satisfaction. The question that best elicits satisfaction from users is, “Does it work?” When it doesn’t, users need to be able to recover from errors easily and quickly. There are a number of things Web publishers can do to build satisfaction with content: deal with broken links and watch those error pages; optimize content for your search and index results; don’t hide your help desk phone number and keep that FAQ page current; assure the Web manager contact info is published so an escalation window is available.

 

Confidence. Is the Web site in question intuitive and learnable? When you publish content so that it has consistent navigation, packaging, appearance and behavior the answer is yes. This evolves to a punch-list of best practices that cover: navigation and link behavior; ease of use; readability; packaging and forms. When you have consistency and standards across your site for all of these elements you build confidence.

 

Trust. You gain trust when you deliver what you promise and are transparent in your operations. For example, if forms on your pages ask for personal information you should embed a link to the privacy act policy nearby these fields. In addition to privacy rules, Web publishers can garner integrity for their site when they manage the following content streams: Populate the “about us” programs on their pages; Show content is current and adopt a review schedule for your pages; Become authoritative, avoid duplication and use related links; Follow guidelines for good graphic display.

In 2002, Darren Peacock, of the National Museum of Australia presented a concept of a hierarchy of user needs was discussed that has many of the same ideas. This framework informed my thinking as I tweaked the value ladder for content publishing into a workable priority setting system for developers for one major site I consulted on.

 

Every idea that was collected – deficiency reports and change requests from users, content managers, team members and leaders – already went on a spreadsheet. The developer team had limited bandwidth and as we met regularly to negotiate what ideas merited their time and attention, decisions seemed arbitrary and less than strategic.

 

The Magic of the Excel Sort Button

 

By introducing a meld of Peacock’s diagnostic system with my value ladder approach, a workable approach emerged. My solution allowed the development team to rank each idea for improving the site or fixing a bug against a hierarchy of user value criteria. The value impact started with does it work, and moved to can I find it.

 

Then concepts of consistency, trust, interaction and adoption were introduced. By weighting the most fundamental items at the start of the ladder - does it work and can I find it – an automatic thumb on the scale was achieved. With the magic of the Excel sort button, a punch list of priorities emerged that put the users interests at the head of the line.

 

The final step toward a clear strategy aligned with user needs emerged to inform the development schedule was tackling the mystery of determining a “level of effort”.

 

Poker, Pet Rocks and a Trump Card

 

This LOE analysis is vital to the bottom line of any budget driven organization. Here, an idea that will elevate your game is to institutionalize a match of Planning Poker.

 

This activity involves assembling a multi-disciplinary team, giving them cards from a Planning Poker deck and asking them to independently estimate how long a certain project or task will take. By involving everyone on the team in arriving at this estimate, engagement levels remain high. Also, those not directly involved with each task learn from their peers about the true level of effort involved in a task. This builds appreciation for the “invisible” work that individuals may not get credit for when it is outside the view of a colleague. When team members expose their cards, a consensus can emerge about how long a task will take. When estimates are wildly different, it can initiate helpful discussions and problem-solving about different approaches to the same result.

 

The level of effort discussion can also expose activities that are “quick wins” and build an incentive into the process to knock them off instead of letting them fester. As David Allen has observed in his productivity advice book “Getting Things Done,” mastering your work flow means deciding what needs action and then do it – delegate it - or defer it. Allen says “If an action takes less than two minutes it should be done the moment it is defined.”

 

By knocking off the “low hanging fruit” and building an incentive into your workflow and scheduling to reward these small victories you can reap confidence with those who contribute ideas to your system. My system accomplishes this by giving key leaders on your team a “pet rock” that they can put into play at any scheduling meeting. If your quick win idea falls below the line on what is scheduled for the next release, you can pull out your “pet rock” and ask for it to be upgraded to the next cycle. It can relieve your tension and anxiety in seeing something you see as important ignored, which is a boost to morale.

 

Finally, all teams ultimately are answerable to someone in the hierarchy of the organization, who may demand a voice in the process. On a bad day, this voice can throw the entire plan off center because everything must be reorganized to meet their demands. To factor in this voice, you would benefit from making it an official part of your process. Be transparent about how you are making decisions, and deliver regular updates on what’s being done. Then give the boss a “trump” card, which allows them to take anything on the list and squeeze it in the current release cycle. The secret here is that you train your boss to first recognize that ideas must be captured and put on the list as step one. Over time, the “out of thin air” changes in direction may ease and a participatory and transparent workflow will triumph.

 

Conclusion

 

When you “crowd source” your Web development schedule you can either drown in the data and demands, or gain important efficiencies and team spirit. By adopting a ranking system for your fix-it list that focuses on the user, engaging the whole team in the level of effort discussion and rewarding quick wins the payoff is sweet.

 

The health of your whole team’s eco-system improves because your workflow provides a transparent, satisfying and engaging process for everyone involved.