Loading Form...
Thank you
Jul 1, 2009 | 9 minute read
written by Linda Bustos
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 Success1. Align with business objectives2. Know relevant best practices3. Perform competitive analysis4. Define functional requirements in detail5. Prioritize and time phase requirements6. Document use cases7. Diagram workflow design8. Apply creative design9. Test and adjust requirements - again and again10. Keep requirements updated Always
1. Align with Business Objectives
Specifying why you're actually making these changes is important in knowing what's going to drive these requirements.
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
Don't just do things because they're cool or other people are using them.
3. Perform Competitive Analysis
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.
4. Define Functional Requirements in Detail
Make sure you're covering all your bases...
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
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).
Case Study: Spencer’s GiftsMust Have:Content management system: promotion flexibility, template changes, manage graphics, shipping optionsMerchandising tools - categoriesAuto merchandisingNavigation/taxonomySite search integrationSEO – unique meta/title tagsAnalytics integration and page taggingCart / checkout functionality - persistent cartLoyalty ProgramIntegrate with order managementParent/child sku relationshipsSecurity and PCI complianceShould Have:Personalized product recommendationsProduct ratings and reviewsDynamic imaging (zoom, alternate views)AJAX capableSite optimization, A/B and Multivariate TestingNice to Have:Alternate paymentsImproved contentWish list, gift registry, gift guidesProduct comparisonMicro sitesMobileInternationalBlog
Case Study: Spencer’s Gifts
Must Have:
Should Have:
Nice to Have:
6. Document Use Cases
7. Diagram Workflows
8. Apply Creative Design
Lo-Fi Wireframe:
Hi-Fi Wireframe:
9. Test and Adjust Requirements…again and again
10. Keep Requirements Updated…always
Requirements are never set in stone, they're always living and breathing.
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.