Defining an eCommerce Operation – Experience and Usability

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

UPDATE 10/27/10 – I posted a mind map of my eCommerce Operation on mindmeister that replaces the original map contained in this post. This includes the latest updates to my organizational thoughts on an eCommerce team.

This is my seventh and final post in the series on the topic of defining an eCommerce operation. Certainly I’ve not covered every detail or function of an eCommerce grouped tasked with operations,

eCommerce Operation
An eCommerce Operation Team Structure

maintenance, and new growth. However, this and the previous posts provide a baseline of the most important functions needed in an eCommerce model and provide guidance on the eCommerce team structure.

The area tasked with defining the customer experience and usability of the site is of utmost importance. This part of your team defines the flow of the site, the visual appearance,  and how customers interact with it. The important thing to remember is that to the customer, they are not interacting with your site. They are interacting with your brand. Your eCommerce site is an extension of your brand. It can find, make, keep, and lose customers based on the experience they have with your site.

The experience and usability of the site can be molded in four key areas of release management.  They are prototypes, mockups, use cases, and process maps. They fit logically together and in sequence to guide the designer and implementors in the final output.


The prototype is used to show the concept of a software program or release. The eCommerce team could use a basic functional piece of software, a sequenced set of pictures, a storyboard of hand drawings, or any other type of visual output to display their prototype. The idea is to gain acceptance of the software concept and to create discussion about it to help mold and shape the final output. I know many traditionalists will argue that a true prototype must be a functional piece of software. I do believe this is valuable, and one form of a prototype, but today with today’s tools we have the ability to link static pages together without necessarily making them functional. Remember, the key purpose of this step is to communicate an idea or concept to stakeholders.

In some cases, the prototype is used as a proof of concept. Can the design team make something work on a smaller scale so that it increases confidence it can be done on a larger scale. In this case, the prototype is important in order to secure funding for the software release.

Use Cases

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

The use case describes how a system responds to actions on it. In an abstract sense we can think of objects performing actions on the system and then specifying how the system will react.  The objects could be people, other programs, or events.  The objects are often called actors and the use case creates a series of steps that describe the action and the resulting response from the system.

The use cases have value because they help the designers and testers to craft the expected flows of the system.  A use case document is also typically easy to read and less formal and verbose than many traditional requirements documents.

It should be noted here, that my good friend Mike Cottmeyer tells me the proper name in agile development methods is “user story“.  Looks like in the case of a user story, the documentation of the requirement is simplified but requires and additional step of documenting an acceptance test.

Regardless of the methodology used, remember the key task with this work is to define the expected use of your system. Define who will use it, how they will use it, and what they expect to see as the results.

Process Maps

Once you have established use cases for a release, you can combine all of them with a process map, or flow chart.  This document defines how all the pieces of the software will fit together and flow to make a complete system. It shows how various use cases may be linked, describes decision points, and shows the possible paths through a system.


The mockup is a way of designing the user interface of system through images or drawings. The mockups are not functional. The purpose of the mockups are to allow your designers to create the page layouts that comprise the system. They’ll be considering things like object locations, form layouts, colors, fonts, etc.  Don’t discredit the importance of this step. Many a A/B test has proven that things like the color of button or location of an object on the screen can have impact on your site conversion rates. You don’t necessarily need a designer for this task, but you do need someone who is visual that can bring your process flows to life.

I added the experience and usability functions to the concept map for an eCommerce model that I’ve discussed.  I welcome your feedback and input.  No model is ever complete and in the spirit of continuous improvement I’ll always be looking for ways to tweak to so that it creates more value.

How management escalation promotes organizational entropy

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

Previously I defined organizational entropy and how modern organizations evolve to this type behavior through a randomness of work order and completion. Another contributing factor to organizational entropy is management escalation. Let me start by saying that this post is not about bashing the practice of management escalation. Escalation is actually a needed and healthy component of high achieving organizations that have properly empowered workers to achieve the mission of the business.  There are however times when management escalation can disrupt the normal flow of work within an organization which can be disruptive to output. Escalation is random in the sense that its not pre-planned. So when members of the organization escalate issues with the intention of jumping the existing work queue there will be consequences.  The delivery time period of the other work in the queue is disrupted which creates the entropy effect.

What I’m saying is that there is a time and purpose to escalate items to management. Sometimes its for awareness on a particular topic. Often times though, it’s in an effort to get work done in a more timely manner. Here’s a list of negative consequences for organizations that shift work due to management escalation:

Penalizes those who follow the process

There will be times where the business return and value for the escalated item is properly used such that the work should be allowed to jump to the front of the queue. However, there are also times where teams or individuals may abuse the process in an effort accomplish work for their personal objectives or client despite what it means for the overall organization. Unfortunately this means that those who attempt to follow published processes and procedures may be penalized by having to wait longer for their work to be completed.

Opportunity cost from work that is delayed

When management escalation occurs, rarely do decision makers consider the full impact of shifting resources to complete the escalated work. There could be times when the work that is delayed has a higher value to the business than the escalated work.

Doesn’t solve root organizational process issues

In academia there is a notion of absolutes or  “perfect”situations (Economic perfect competition, perfect information, etc.) . This isn’t reality of course, but in the context of a work flow through an organization an attribute of perfect output order is one that processes work in the order of value to the business. In our conversation about organizational entropy and management escalation, this is important because ideally an organization would process the work without requiring escalation.  A need to escalate work for quicker resolution than what the standard processes provides could mean that the standard process needs and adjustment so that future management escalations can be avoided.

Sets precedent for future process avoidance

If individuals or groups see that the way to accomplish work is by escalating to management then others will follow this path. That’s not healthy and only serves to create a more chaotic environment which expands the amount of entropy.

So use management escalation wisely and with reservation. Consider the full cost and if the current system is not working properly then aim to fix it with process adjustments.

I love Marriott, but…

OK. I’ll start by saying that I am fan and rewards member of Marriott. I like their properties. I like the cleanliness of the rooms. I like the attention I receive from the staff. I like their rewards program. I’ve used their website on occasion to book travel. I’ve been impressed with their use of social media. The list goes on…

What I don’t like though is constant barrage of paper mail asking me to sign-up for the rewards Visa card. I haven’t tracked the exact frequency of these but I’m pretty sure its at least once a month. It’s time to bring this arm of the marketing program into the digital age. Segment more fully and learn from members that have not responded to this particular marketing offer. No need to keep sending them the same paper offers month after month. Learn their preference and look to market other services.

Defining an eCommerce Operation – Release Management

UPDATE 10/27/10 – I posted a mind map of my eCommerce Operation on mindmeister that replaces the original map contained in this post. This includes the latest updates to my organizational thoughts on an eCommerce team.

This is my sixth post on the defining elements of an eCommerce Operation. Previously, I’ve written about management in the areas of solution ownershipcontent managementproduct management, demand management and metrics management. In this post I’ll explore elements related to release management activities.

Release management provides for the justification, prioritization, and specification of software that comprises your eCommerce portfolio. Certainly software development is a discipline unto itself, but these elements cover the basic disciplines and functions of the process. This area of your eCommerce operation needs to focus on the ability to get work started, the ability to prioritize a lengthy queue of requests, and the ability to specify what to build.

Business Case and Modeling

Business case activities are mostly used for new software development or development that can be capitalized according to Statement of Position 98-1. Business cases will typically cover:

  • Objectives
  • Risks
  • Estimated costs
  • Estimated return

Building a business case is not likely to be the favorite activity of the team. But doing this does provide great deal of value for your organization:

  • Allows you to build financial forecasts
  • Allows you to build a project budget
  • Shows the expected return of the work
  • Mechanism to gain upper management support and resource allocation to your project
  • Removes pet features
  • Keeps discussions on the merits of the features
  • Removes emotion

Software modeling is another term with a diverse meaning and that comprises many disciplines, tools, and methods. For an eCommerce team, modeling can be a piece of the front end project justification. A software model provides a simple representation of the eCommerce release for the purpose of relaying its purpose, meaning and structure. The model may be composed of graphics, wire frames, or flow charts.

Feature Prioritization

Software shops have lists of items comprised of new feature requests, previously discovered defects, marketing tests, and customer requests. Developing a framework for prioritizing all these ideas can be tricky due to office politics, available resources, financial justification, etc. But prioritizing the list is an essential activity because the size of the list is longer than what you can accomplish. Plus you’ll want to make sure you are solving the requests in a proper order. Here a few ideas for how teams might prioritize work:

  • Based on what customers will pay to receive
  • Based on estimated return value
  • Based on level of effort
  • Use prioritization families – Groups of related requirements
  • First in First Out
  • Value to cost – Highest value to lowest cost first
  • Contractual obligations first

Requirements and Specifications

Documenting requirements is another area that’s a discipline all unto itself and their are many alternative methods for requirements specification. The important aspect of this part of your organization is that you have team members that a) know the business b) know your customer needs and c) are flexible to be able to modify requirements with changing business conditions. Rather than focusing on any one particular method, I advocate having the right type of team member on point for requirements gathering and specification. Adaptability to change to is paramount because the needs of the business and dynamics of your environment will change.

I added these elements of the eCommerce organization to the concept diagram that I’ve grown with each post.  This updated image shows the team layout that I have discussed so far.  I have one other area to cover customer experience, so stay tuned. ( Select the diagram to expand it.)

eCommerce Operation
An eCommerce Operation Team Structure

Pork Barrel Software

If you have read any of my previous blog posts, you’ll know that I’m all about business process management and efficiency. For better or worse, I spend quite a bit of time thinking about how organizations produce work. A common framework for many businesses to produce software releases is to have both a capital projects and an expense (run the business) model.  I’m not an accountant and don’t pretend to understand all the intricacies of

Pork Barrel
Don't let the pork in your software barrel

accounting rules, but I do know that generally accepted accounting principles allow for the capitalization of some software development costs as specified in Statement of Position 98-1.

Producing software is an expensive process when you consider fully loaded project costs to include design, development, testing, management, etc. Expecting a return on this investment and structuring the cost to capture its benefits over time is a natural course of asset management and a step towards proper performance and benefits for an organization.

With that said, organizations should also allow for maintenance of existing software through a more streamlined process. If organizational resources are completely dedicated to capital projects and production support then the overall software output cycle doesn’t follow a consistent release cycle and there are periods of time where some members of the organization are not fully utilized. If you think of your software development team as a machine or production line, then you want to keep each of the stations busy so that the throughput of the machine is optimized.  Otherwise the system will have queued work in some stations while other stations starve for work.

I say all that to get to the main point of this post. If all of the software development activities are on full capital project timeline then members of the organization that try to move work quickly will become frustrated and look for ways to insert work into the system. In a formal project process this is typically a scope change request. The work may or may not be directly related to the original project objectives. It’s like “pork” going into a bill in congress. The organization members that are frustrated by this are members who interact directly the end customers. This could be customer service, sales, or marketing. As they listen to the voice of the customer they will naturally try to solve their business needs as a part of the value proposition and service of your company.  Pork Barrel software really doesn’t benefit anyone. It’s frustrating for the project teams because they feel like scope creep is making their project longer. It creates project justification issues for Project Management Office because the financial analysis of the project changes.  It frustrates the end customer because they feel like their needs are not met in a timely manner.  The list goes on…..

If this is a problem for your organization, how do you solve it? At the core of the answer is that you have to allow for time to be used on capital projects as well as run the business activities such as maintenance, defect resolution, and architectural upgrades. A simple way to do this is to use a percentage base allocation system. So for example you might allocate 70% of time to capital projects, 20% to run the business, and 10% to administrative activities. Adjust the allocation as needed for your business.

What other methods have you used for resource allocation and allotment in your organization?