Monday, March 28, 2011

eCrater: A Review for a Small Buisness

The OverviewI was recently asked to provide a review of eCrater, a free online store template that can be used to quickly setup a online store. If you haven't heard of eCrater.com - don't worry neither did I before I was ask for my thoughts on it.

eCrater provides a common and simple layout for offering products online. The site layout can be customized with a combination of templates (7 to choose from) and images. The images are to be provided by the store owner and can be used to represent the store logo, company name, products and categories (featured on the home site).  Additionally, eCrater also embeds its own advertising banners within the products page.

The Organization
A small tool supply company that sells products under 3 Brands. The challenges that faced were numerous as this is a small company that hosts its product information in many Excel spreadsheets - one sheet for each product and all its variations. I attempted to consolidate this product information with the goal of providing a functional example (will not take actual orders) of what they can do to quickly move to a web based order taking system.

The Process
The product catalog files had to be consolidated this involved a manual extraction, for each page of the catalog, of each product item entry. Secondly, for the purposes of eCrater’s bulk import, product images were stored to a publically accessible location which was added to the upload file. The product file was then consolidated to unique products by image which was done to ensure the file would be successfully uploaded when manually reviewed by eCrater for unique products. This consolidation resulted in 54 unique products- eCrater requires a minimum of 50 unique products for the import to be accepted. Finally, after consolidating to the unique products, a tabbed delimited file was created and uploaded to eCrater.com - it took 4 days to be manually processed by eCrater.

The Pains
The most frustrating experience in creating the site on eCrater was by far the Bulk List functionality. Creating a simple tab delimited text file was time consuming and uploading required several attempts. On the first attempt, I wanted to see what the site would look like with populated data. I quickly created a file for import through the eCrater "Add New Import" function of the "Bulk List/eBay Import" option. This quick test resulted in the file structure containing basic errors, such as missing the header and  formatting of quantity values and fatal errors such as length of the file ("Fatal error: Bulk file contains less than 50 products").  These errors prompted further investigation into the process which revealed several issues with the process:

  1. Each product needs to be completely unique. eCrater does not provide functionality to offer varying sizes of the same product nor does it permit multiple entries of similar products to contain the same image. This is a severe limitation for the tool supply company offers numerous variations of a particular product.
  1. Manual Review Process - Once the file is uploaded and approved by import process, a manual review process is triggered. This process took four (4) days to complete and with no notification, the uploaded products were offered online. The online forums also indicate that a site can also be deactivated without notice.
  2. Although Categorization and nesting of categories is extremely simply and easily incorporated into the bulk import file, products cannot be listed under multiple  categories. 

The Gains
As a small business where funds and technological skill are not readily available, eCrater provides for a good start to developing a online presence. The promotion tools and guidance would be a extremely valuable feature for a company attempting to create an online presence for the first time. When a site is finally up and running, the benefits of using eCrater far outweigh the cons - the primary benefit is the speed at which I was able to create a functioning site - minutes. I was able to create a subdomain, high level categories and a small number of products in minutes.  
The ROI
Creating an ecommerce site on eCrater, although quick and feature rich, was too simple for a company with the need to list products with multiple specification variations as well as multiple product categories. While limitation of eCrater were reached during the sample deployment, the ease of use features, payment processing functionality and marketplace all provide significant benefit to the small business with extremely limited resources.

Hope this helps and not hinders!
-Project: ROI


The following is my approach and thoughts on the site.

Sunday, March 13, 2011

AGILE! My old nemesis.

 
I LOATH AGILE DEVELOPMENT.

Ahhhhh... that felt good to get off my chest. To be honest, Agile development is a great idea. I don't hate it, just the way its implemented. It becomes an excuse for doing less 'fluff' and more coding.

 :| Oh no, this will end badly.
In one organization I witnessed the implementation of Agile methodologies with this kickoff:
 "Ok we're going to be doing Agile now. The good news is we have been doing it all along! Yay."
They were doing the bare minimum to get by on a large scale project and now they wanted to implement Agile. What they really wanted to do was to justify their 'effort' to the client and they did! They had some daily processes in place, team structures yet documentation of the system prevented knowledge transfer. We would see, and all to often, production systems being effected by updates that did not receive full testing and updates effecting other systems because dependencies were not documented. Changing their development methodology was not going to fix their problems, especially if the information needed is never recorded let alone access.

This is a prime example of why I loath AGILE - the implementation.

DO AS MUCH OF WHAT YOU CAN… to move the project forward
This usually doesn't mean comments, documentation or planning. When done right, progress can be made and quickly. The scrums allow for progress to be track, controlled and perhaps documented. Problems can be quickly resolved and a small team can accomplish amazing results. However; if you are thinking about implementing AGILE or any other development methodology you have to think to your self - what are we looking to get out of this, what's the ROI?

Development methodologies, and I am going to generalize, are a set of steps followed during development to produce a result. This result is not, in my opinion just the final output but the surrounding documentation that supports it. If there is a problem and the developer is MIA, where do you go? In my first development job, the methodology was developed in-house and was flexible. Depending on the size of the project, certain steps would be included (ie feasibility steps were omitted when changing report formatting)

If you can answer this, then you have a better chance at picking the solution/approach that best fits your organization. There are so many models to follow during the Software Development Lifecycle (SDLC) such as recursive, waterfall etc., that you should gather a good understating of each rather than implementing what's hot: AGILE.

The ROI
The benefit of using the AGILE methodology is primarily the speed of development. With clear objectives and a team leader that can stay focused on the target, the results will be shorter development time (cost savings) and concise documentation. This is key - clear goals that are not moving targets are great candidates for this approach. If you find that the goal shifts frequently, then you may have other project management issues to contend with in addition to development problems; however, this too can be resolved with AGILE - provided the team understands that with shifting goals the end may never be reached. The constant contact with the customer will provide for a deeper relationship and develop customer loyalty - provided the team leader can manage scope creep.

At a later date we will have to review AGILE and its components in more detail. For today - hopefully you now know what you're getting yourself into and why.


Hope this helps and not hinders, Enjoy!

Friday, March 4, 2011

DOCUMENTATION is for wimps!

Coders code, PM's write Diaries!
Within every major IT department, there really only two job functions: Coders and non-coders. The coders to which I am referring are those people who speak in binary, code in assembler, and haven't seen the sun since their first computer (aka Code Monkey). Then there is everyone else - you know - people. People who speak your language - english or better yet business, people who know technical details as well as the function of a balance sheet and people who can communicate.

WARNING: Graphic Images!
This is an actual dramatization...
of a coder writing documentation.


Verbose pseudo code
Communication is important. Correction: Communication is VERY important. Whether you are documenting a new application (preferably pre-development), meeting minutes or project status', communication is now at the core of the IT function. No longer is it adequate for coders to just code - they also need business knowledge and communication skills. Sure, a good coder might leave a few comments sprinkled throughout their code libraries, although greatly appreciated - it's not enough.

Now I have to admit - I was a code monkey in training. Yes, yes its true; however I managed to break free. As a junior coder I was stuck in a hobbit hole somewhere coding while the people around me conversed - then I discovered documentation (beam of light from the heavens and choir singing). There was a gleaming piece of hope that I followed out of my hole.

Sure the true IT grit lies with the coders (admins may argue), but you or your team can evolve to be the uber multi-lingual geek. A coder who not only writes code but communicates their intentions to the business and NO we are not writing Diaries and its not girly.  Documentation is like coding - actually think of it as "Verbose pseudo code" and the compiler is known as "Marketing".

Don't be a code monkey - document!
Writing documentation sucks - a lot. However, the benefit is that it communicates your ideas to your team, client and/or bosses. It helps you think through your approach, serves as a road map and simplifies the development process. Ever hear a coder say "Oh I must have overlooked that" in reference to a key issue created by the poorly documented change? Of course you have. With a little communication, the business need could have been outlined for the developer (not coder) and in turn, the approach could have been documented prior to development. The benefit of these steps are:
  1. Business articulates their need
  1. IT reveals the approach
  2. Everyone agrees (scope)
  3. Impact of proposed changes (scope creep) can be evaluated against project plan.
  4. New team members can get up to speed quickly

In one office, I was replacing the code monkey who decided it was time to leave. I had less than 2 weeks to extract all the knowledge he had because once he left so did the documentation.  The real reason he was leaving? I think he realized he made a mess of the systems and could not remember what any of them did. For the next few months, I spent my time stumbling through the systems and trying to document what they actually did and in the event of a failure - I did this while debugging. Sure we made mistakes - but by the time we were done - the core systems were usable.

Ramble, Ramble - Now The ROI
Good documentation saves time, money, customers and sanity. Coders have a map to follow and what the system does is clear and available - You don't have to step though the code to figure out what it does or wait for the code monkey to return from vacation to point you in the right direction. Customers will benefit from the professionalism and the reduced errors due to forgotten specifications/functionality. Finally, when you stop shooting yourself in the foot, everybody wins!


Hope this helps and not hinders!
-Project: ROI

Links
89 BENEFITS of documentation <-- looks through - not sure there was too much documentation