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 ownership, content management, product 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:
- 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.
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.)