Requirements Diligence: The cornerstone to ecommerce project success

This post is a recap of the webinar Requirements Diligence: The Cornerstone to eCommerce Project Success, presented by Bernardine Wu of FitForCommerce, dubbed the "eHarmony of ecommerce." FitForCommerce is a consultancy founded to help online businesses work through ecommerce strategy, requirements/RFP, vendor selection, ecommerce marketing and implementation coaching.

Why Requirements Diligence?

If you were choosing a stock or career, you'd do your homework, right? Ditto for ecommerce.

No one will argue the better you plan, the better your build, test, launch and support phases will go. And planning is really an equation of Requirements + Use Cases + Workflow + Creative Design + Timeline:

Ten Steps to Requirements Success
1. Align with business objectives
2. Know relevant best practices
3. Perform competitive analysis
4. Define functional requirements in detail
5. Prioritize and time phase requirements
6. Document use cases
7. Diagram workflow design
8. Apply creative design
9. Test and adjust requirements - again and again
10. Keep requirements updated Always

1. Align with Business Objectives

• Define success. Spell out your desired, measurable objectives.
  • Reinforce brand? Improve customer experience?
  • Reduce costs? Increase profit margins? Increase conversion rates? Increase sales?
  • Gain market share? Gain back market share?
• Know and agree (amongst stakeholders) why are you changing/re-designing/re-platforming
  • Current site is out-dated? Inflexible? Needs better features or customer experience?
  • New branding / imaging / product line strategy?
  • Adding new businesses or product lines? Going global?

Specifying why you're actually making these changes is important in knowing what's going to drive these requirements.

• Define who are you designing it for
  • Who are your customers and what do they want?
  • Why do they come back?
  • Are there different messages for different audiences? Primary and secondary?
• Align your organization to support the objectives
  • Who are the stake-holders vs. decision-makers?
  • Who is going to do the work? Who is going to review the work?
  • Do you have enough of the right expertise or resources in-house?
  • Right expertise: Technical, e-marketing, e-merchandising, creative design, IA/content design, customer support, fulfillment, etc.
  • Are external or on-demand resources available?
  • Have you allocated enough time? Are there conflicting projects or objectives?
• Assign and allocate the project team
  • Is everyone clear on roles and responsibilities, time commitments?
  • Who is the project lead and do they have the right authority and accountability?
  • Do you need to look outside your organization to fill resource gaps? (We don't always have all the talent/resources in-house).

Don't forget to "document it and socialize it." Write things down and document what you agree upon, so that everyone clearly understands expectations and deliverables.

Socializing needs to happen to get buy in from folks that have to live with it, implement it or use it. Have more discussions about it, circulate a memo/diagram, do an in-house training/webinar on it, etc.

Document and socialize each step!

2. Know Relevant Best Practices

• Research “Best Practices” at the feature/function level
  • Research the industry
  • Network with peers to find out what worked and didn’t work for them
  • Reach out to experts in the field including consultants and providers
  • Read whitepapers, research reports, forums, blogs
  • Be careful of analysis paralysis
• “Play” with other great sites
  • Shop competitor (same products OR same demographic target) and non-competitor sites
  • Experiment with leading edge and non-leading edge features

Don't just do things because they're cool or other people are using them.

• Use quantifiable market data and benchmark as much as you can
  • FitBase
  • E-tailing Group

3. Perform Competitive Analysis

• Conduct competitive analysis
  • See what you like and don’t like
  • Decide what you want to include and want to avoid
  • Check competition in your category, but also mindshare or budget competition
  • Think about what’s needed to give you a competitive edge – short-term and long-term

Budget competition: in this economy, you're not just competing against industry competitors, but against other goods and services the customer is considering. For example, apparel is competing with electronics, in a way.

• Compare specific features to non-competitors, too, to understand what your customers expect
  • What sites and features are setting a new bar?
  • What capabilities or interactions are your customers being trained to expect?
• Compare use of key features

4. Define Functional Requirements in Detail

Make sure you're covering all your bases...

• Review each and every potential feature/function
  • There are 100s of features, functions, topics that an eCommerce manager must plan and execute around
• Consider requirements' impact on all elements of running an eCommerce business including content management, promotions, back-end processing, analytics, reporting etc.
• Use surveys, feedback forms (from customers and other retailers, if possible)
• Treat everything like an investment decision
• Document your current capabilities
  • Pinpoint what features or areas of the site or content drive sales (or, conversely, trigger abandonment or service calls)
  • Don’t assume they are obvious
  • Review every page, data set, content
  • Never assume your new site will have all the features and functionality you currently have, unless you plan or confirm that it will
• Limitations or Impact Factors
  • Technical processes or limitations, such as integrations with legacy systems
  • Budget considerations
  • Organizational considerations, such as strong/weak skills

Metrics documents are good to have, it's something you can hand to your vendor or in-house team that logs your average site traffic, peak times, etc. because you have to plan business processes around these factors.

5. Prioritize and Time Phase Requirements

• Prioritization
• Know that you can’t always get what you want when you want it
  • Rate them
  • Must Have = Cannot re-launch without it / Is a critical capability
  • Should Have = Should not launch without it / Is important
  • Nice to Have = Can launch without it / Try to include / Can be phased in
  • Stack rank requirements – top 40 in order

Ranking things always forces people to put things in order, whereas rating them is less clear. If you can't stack-rank, at least put them into blocks (most important 10, next important 10 etc).

• Phasing
  • And when do you need it by?
  • What are your timelines? What drives your timelines?
  • Is project phasing an option? Is some throw-away work acceptable?

Case Study: Spencer’s Gifts

Must Have:

• Content management system: promotion flexibility, template changes, manage graphics, shipping options
• Merchandising tools - categories
• Auto merchandising
• Navigation/taxonomy
• Site search integration
• SEO – unique meta/title tags
• Analytics integration and page tagging
• Cart / checkout functionality - persistent cart
• Loyalty Program
• Integrate with order management
• Parent/child sku relationships
• Security and PCI compliance

Should Have:

• Personalized product recommendations
• Product ratings and reviews
• Dynamic imaging (zoom, alternate views)
• AJAX capable
• Site optimization, A/B and Multivariate Testing

Nice to Have:

• Alternate payments
• Improved content
• Wish list, gift registry, gift guides
• Product comparison
• Micro sites
• Mobile
• International
• Blog

6. Document Use Cases

• Uses Cases are written to clarify a specific customer experience/journey (written from user perspective - both customer and staff)
• Multiple features can be included in a single Use Case
• For each Use Case, include:
  • Objective
  • Scope
  • Requirements
  • Process & Feature Dependencies
  • Data Dependencies
  • Demonstration Scenario
  • Alternatives
  • Integrations
  • Technical Assessment & Options
  • Special Requirements
  • Risks, Issues, Constraints

7. Diagram Workflows

• Functional Component Diagram
  • Diagram that shows functional view of the eCommerce business to show inter-relation and implications to process, organization, technology, but not workflow
• Technical Component Diagram
  • Diagram that shows technical integrations and data flow between systems detailing inputs and outputs
• Site Workflows as more than a site map
  • Pages are to be used (how to get from home page to product page to cart to confirmation, for example)
  • Features/content by page
  • Storyboarding, IA, labeling, navigation
  • Key workflows like: Browse, search, guided navigation, registration, checkout

8. Apply Creative Design

• “Lo-Fi” vs “Hi-Fi” Wireframes
  • Lo-Fi covers layout – what is on a page (think inventory), relative size and position
  • Hi-Fi is where everything is to scale

Lo-Fi Wireframe:

Hi-Fi Wireframe:

• Creative Design
  • The look and feel of the site including colors, design devices
  • Create multiple options to demonstrate a “design system”
• Use Corporate Identity and Style Guide
  • If none exists, create one first, then adjust, then update it
• Usability
  • Ensuring a visitor/customer’s experience is as effortless as possible

9. Test and Adjust Requirements…again and again

• Test requirements against all use cases including “edge cases”
  • Test for wrong-course path. What should happen when errors are made?
• Field Testing
  • User/usability testing of wireframes (start with mockups)
  • Ask ‘friendlies’ (customers) to give feedback
  • Get structured feedback of creative design, but go beyond “I like/don’t like” to “This works for me because…”
• Adjust Requirements
  • When testing or other factors prove a need to adjust
  • Be careful not to react too quickly to feedback (often one user comes in and hates something or gets stuck somewhere, look for patterns, consistency)

10. Keep Requirements Updated…always

• Keep a library of requirements documents
  • Print a binder to maintain most recent version
  • Maintain version control (label documents with versions and authors)
• Create a process to update requirements when anything changes
  • Hard to do when focus is testing and going live
  • Testing Team and Requirements Team must be in sync
  • Make last step of testing (e.g. closing a ticket) include checking that requirements were updated

Requirements are never set in stone, they're always living and breathing.

Questions

From my experience in ecommerce implementations, your requirements approach is right on. However, the problems is some clients (usually smaller ones) are not sophisticated, patient or detail oriented enough to take this type of rigorous approach. They are not able to articulate requirements without seeing it first. How do you suggest one adapt the methodology to meet this type of client?

Hold the line on rigorous methodology. Start with mockups but they have to tie to requirements, even if people are visual. Use both (wireframe and workflow document and list of requirements). Doesn't have to be a creative design, but a placeholder for where the feature will live.

Can you share your experiences with delivering ecommerce sites using an agile approach as opposed to getting all requirements up front?

Agile approaches are tricky, if done properly it will work very well. If not done well, it can be worse than a waterfall approach. Defining functional requirements in great detail is still very important. The difference with Agile is that you're doing things in chunks. Define your iterations (chunks), so that you can define those requirements.
Once you create those requirements for that iteration, they're fixed. To fix them, they do need to be detailed enough. In a way, it's taking this approach and breaking them into iterations.

What role does SKU descriptive copy play in the equation? It seems that retailers treat it as an afterthought.

Yes, very often that becomes an afterthought. As you're going through your requirements, make sure you're collecting samples of whatever that feature is about. Is it about copy, other product content, ratings and reviews etc. What does the retailer do now and what does it want to do in the future. That way it becomes something you're planning for, rather than an afterthought.

What do I do if I'm already in the implementation phase, but I realize that my requirements weren't detailed enough?

That's a common question - and painful. There's no right answer other than going back and re-cast your requirements. It will save you time to do this, even if it does mean a delay in implementation. You don't have to start all over again, but it might take you longer to finish.

You may even find interdependencies pop up that you didn't think about before, and you can take advantage of adjustments that need to be made to these requirements at the same time. Better to find out before you're even deeper into the project.