Floating Orange
Design. Write. Learn.

What I Learned This Week

What I (Re-)Learned From My Last ECommerce Project

At the end of each big project I manage, I like to sit down and think about the things I could have done differently that might have made a positive impact, or could make my next project even more successful. My last eCommerce project taught me a lot. It wasn’t my first (and I hope not my last!), but it was chock-full of lessons I will take to heart on my next project. Since I always write these things down, I thought I might as well share them.

Continual Planning

Dwight D. Eisenhower said it best when he said, “Plans are nothing. Planning is everything.” The benefit of project management doesn’t come from plans; it comes from collaborative planning activities. Too often, especially when it comes to infrastructure, you assume a plan or a design will remain static. But the truth is that they never do! Planning is really just a form of managing risk.

What I’ve learned is that to be really agile, you’ve got to plan, plan, plan. And then, plan again. The point is that it’s the activity of mapping out a path together that matters. The same is true with your environments. As a team, you have to continually review what you have in place and ask real questions. Is this the best use of our resources? Is there another way to do this? How will this meet our needs tomorrow, or in a week, or after the next release? Remember, just when you think you have it right is when something will go wrong. Don’t stop planning!

Don’t Underestimate the Complexity

A lot of people hear “eCommerce” and they thing it’s just selling stuff on the web. It is, but as it turns out, there’s a lot that goes into selling stuff on the web. Everyone expects the normal levels of interface to other internal systems. But eCommerce is so complicated, and evolving so quickly, that you usually have to engage outside experts for services. This means you probably need to think about your Partners, Interfaces and API strategy in a way that considers all the following:

1.     Payment handling

a.     Credit Cards

b.     PLCC

c.      PayPal, and other online payment services

d.     PCI Compliance

e.     Fraud detection

f.      Returns, refunds and credits

2.     Promotions

3.     Coupons

4.     Order Fulfillment and tracking

5.     Inventory control

6.     User Experience

7.     Content Management

8.     Email Campaigns

9.     Security

10. Loyalty Programs

11. Analytics

12. Tagging

13. SEO

And that’s not an exhaustive list. If you’re omni-channel, the complexity is only multiplied. Take, for instance, partnering with an external vendor to provide a mobile version of your desktop eCommerce experience. What is that vendor’s approach for recreating each of the pages on your site? Will they scrape the screens or get data from an API? What does this mean for your CMS? How much content will your marketing team have control over? What is the lead-time for changes and how will you coordinate those changes with changes to other channels?

A Component Map is a useful tool to help get a grasp on the complexity of your eCommerce solution. A good Component Map will break out, for each of your channels, the tools, APIs, solutions, partners, stakeholders and approaches being taken for each piece of your eCommerce solution. Keep in mind that it should be treated as a common reference and a living document. As such, everyone will reference (and update) it often, so keep it under control.

Product Roadmap

Most people I’ve spoken with view a product roadmap as a Marketing tool. I’ve learned that a Product Roadmap is actually a great tool for everyone, especially the infrastructure team, and it informs your Component Map.

The fact is that an eCommerce solution is tied directly to the Marketing Plan; it is the highest source of business requirements for your eCommerce site. It makes sense, then, to take each of your channels, or products, and align them to the Marketing Plan by creating a Product Roadmap for each.

Because it’s laid out like a Gantt Chart, a Product Roadmap is a great way for the entire team to visualize and think about what technology needs to be in place and when. This is true for external partners, Infrastructure, back-end systems and Quality Assurance. In fact, Product Roadmaps are best when used in a feedback loop to communicate back to the business what it’s really going to take to deliver to that roadmap and how each of the products, or channels are going to be impacted.

Scale the Infrastructure

How many environments are needed for an eCommerce solution? Minimally, you want four environments available for an eCommerce website: an environment for developers to work in (DEV), an environment for the QA team to conduct functional testing (QA), an environment to stage everything before migrating to production (STG), and a production environment (PROD). This works if you have a stable release cycle, maybe something that fits nicely into a comfortable waterfall approach, static stakeholder requirements, no need to validate seasonal loads on your servers, and a back-end fulfillment team that cooperates with your e-Comm release schedule.  Sound realistic?

I didn’t think so, either.

More likely, you’re dealing with multiple, overlapping releases and external partners (mobile web, tagging and analytics, campaign management, loyalty, etc.) who each want a stable and unchanging environment where they can begin their development after you’ve fully completed and tested yours. Add into the mix the evolution of business requirements that comes from the analysis of daily sales performance metrics, real-time learning from implemented solutions and the generation of new ideas and “what-if” scenarios that are so necessary to being competitive, and suddenly four environments seems laughable. Did I mention production support at all?

You get the idea. The answer to how many environments are needed for an eCommerce solution is neither simple nor the same for every organization. And although there are no templates or pat answers, there are a few things you can do to minimize the pain. From my experience, whether your servers are internal or hosted, being able to scale and quickly add environments ends up being more and more critical to project success. And this takes me back to the lessons I described earlier about planning as an ongoing activity and using a Product Roadmap in conjunction with a Component Map to inform your infrastructure needs.

RFI on Vendor Capabilities

How many times have you gotten to the eleventh hour on a mission critical project only to find out your external partner’s solution doesn’t quite meet all the requirements that your internal business partner was expecting? Yeah, remember that time?

I’ve been reminded by this last project of an easy and sensible fix for setting, and remembering, these expectations early in the project. When you create a Request for Information (RFI), make sure to include the business in the process of compiling your list of required capabilities, and make sure your business stakeholders weight those capabilities by aligning them to strategic KPIs (see Product Roadmap above).

Chances are that most solution providers can, to a greater or lesser extent, provide most of the capabilities you want. When the business weights what they want, a weighted list of capabilities informs you where to look a little deeper when you get to the demonstration part of the selection process.

Send the complete RFI questionnaire to at least three solution providers, but no more than six. I find three to be a nice sweet spot that requires a little more upfront homework on my part to cull the service providers down. The upfront investment in time is worth it because more than three service providers makes the process more weighty than it needs to be. Remember that you can always do it again with a different group if you don’t like the responses you get. The point is to document what the business wants – force the discipline of aligning requirements to capabilities to ROI. You’ll be a lot more like to get the right external partner in the end.

Keep External Partners Close

I wish I had a dollar for every time I heard a manager tell me that you shouldn’t include external partners in internal project planning meetings, and then later wonder why those external partners failed to deliver to expectations. In my mind, when you fail to keep a partner completely informed and they fail, it’s your fault, not theirs.

Look, when it comes to project success, everyone is a stakeholder, and there can be no secrets. If you cannot trust an external partner to be involved every step of the way, why did you select them in the first place? You should have an NDA in place, so the issue can’t possibly be confidentiality. And since your external partner is the expert for whatever you hired them for, why wouldn’t you want their expert input every step of the way? Keep external partners close.

I think most people would agree that, handled incorrectly, meetings are the single biggest waste of time in a project.  We all need to minimize their frequency while maximizing their benefit to everyone. I have found that instead of holding separate meetings with the “internal” team, and each of the external partners, consolidating those meetings is a more lean and transparent approach. When external partners are treated with respect, transparency and humility, they are responsive and helpful, just like real partners should be.

Ban Executives From Team Meetings

I write this with tongue in cheek; as if executives could be banned from meetings. But with all honesty, I will write that, with a few happy exceptions, my experience has been that when executives join team meetings, the effectiveness of the team sinks dramatically because the team’s cadence gets interrupted. From what I have witnessed, this seems to come from an insecure need that some executives have to dive into details that the team either already understands, or should really be taken offline. In either case, there are better venues than a recurring team meeting.

Project managers and product owners should insulate and protect teams from executives so that the team can get the work done, which is easier said than done. Leaders should empower teams and trust people to do their jobs, which take no small amount of faith and courage, I’ll grant. But that’s why you’re a leader: you have courage and faith in your people, right? So, grill the project manager or product owner for details on progress or technology if you need details, but let the team do its thing.

Conclusion

Every eCommerce project is different, just as every project is different. But they all have a few things in common. They are all comprised of complex bits of technology that need to play together nicely for a successful user experience. Every eCommerce project requires constant attention and adjustment. They need transparent, honest communication for all stakeholders. They all need attention to detail.

I don’t believe there is one solution, approach or methodology that fits every project all the time. But I do think that like agile thinking, project management is ultimately a state of mind where you have to be constantly planning and adjusting and reminding yourself that to get better you have to be open to learning.