In our last post, we covered a quick/easy way to establish budgetary costs and identify the “low hanging fruit” IT projects – those projects that have HIGH value but relatively low cost and/or easy implementation.
Now we’re going to tackle that one HIGH value project that was more complex:
|Project||Preliminary Solution & requirements||Estimated Cost|
|Enhance Customer Ordering||Multiple solutions possible: new web ordering site, mobile ordering app, POS integration, and computer assisted ordering||Requires more info from the business and customers to identify best option from wide range of possible solutions.|
This one happened to the only OPPORTUNITY type project on our list, which isn’t a coincidence. Opportunity-type projects are more difficult, because they often involve a new direction for the company. In this type of decision, choosing the wrong solution can be disastrous long-term, but the problems may not appear for years.
<Rant>For example, decades ago it wasn’t uncommon for companies to purchase the best-in-class of a particular software package, and perform complex integration to connect it to the other systems. I know of a company that still has separate vendor solutions for order processing, warehouse management, general ledger, accounts receivable, accounts payable, and purchasing software. When this company added new software solutions, they chose based primarily on functionality, without regard to existing software in place.
Today, the IT footprint of this company is far larger than it should be, with support personnel required for vastly different systems, as well as the dozens of integration points that must be managed (and seem to constantly break).
My point? To avoid contributing to IT bloat years from now, be sure to consider long-term ramifications when evaluating options. Think strategically.</Rant>
OK, back to our main purpose – we have a project to “Enhance Customer Ordering”. We’ve listed a few possible solutions and decided we need more info from the business and customers in order to ensure we select the BEST solution. Let’s assume we’ve received this additional information from the business and customers:
- Needed: A simple method that allows customers to place orders. Must handle hundreds/thousands of products quickly. Here is functionality the customers have identified as important:
- Copy from a past order and tweak
- Walk around while counting physical inventory and order product as needed
- Scan UPCs for product ordering
- Product images should display wherever products are listed
- Must handle customer-specific (B2B) pricing
Here are the 4 solutions we had previously identified. Using the functionality info above, we can document pros/cons of each solution type. For example:
- New Web Ordering Site – Pros: images can easily be included, fast & easy to use. Cons: may not be easy to walk around and scan while ordering, not all customers have an in-store computer for web ordering
- Mobile Ordering App – Pros: walk around while ordering, fast & easy to use. Cons: data plan/separate scanner may be required (additional cost)?
- POS Integration – Pros: may be easy for customer users. Cons: requires cooperation with customer IT, will require on-going IT work to include new customers’ POS, not all customers have a POS that can be integrated
- Computer Assisted Ordering – Pros: may be easy for customer users. Cons: requires cooperation with customer IT and integration with customer inventory systems, not all customers have inventory systems
We can see our project beginning to come into focus. As a result of the effort above, let’s eliminate the two options that require integration with customer systems (POS integration and computer assisted ordering), since these require effort outside of our control. In some industries, these may be viable options, but for our purpose here we’ll assume customer cooperation may not be easily available. Now we’re left with two projects that we can research, get pricing, and analyze further.
Having worked through a similar project recently, I ended up doing a proof-of-concept at this point. It’s smart to break larger projects into smaller wins — and I like to prove the project can work before involving the whole company/department, if possible…these are ways of reducing the risk of a failed IT project.
We found a mobile ordering app (Handshake) that has public APIs, so I was able to test the integration before making a commitment. Testing the integration up front can be a big win for large projects. In our case, it was a successful project that grew to include online web ordering as well (2 wins!).
This is how we loosely defined the project up front:
- First we tested order import, to ensure we could easily get orders into our ERP. After all, the whole purpose of this project is to get orders from customers! This was actually very easy using Handshake’s public API.
- Next we identified all other integration points, which included:
- Item availability
- A few other extraneous files
- Processes are then mapped out to define things like:
- In what order must data be updated and at what times?
- How will we control the pulling of orders so we don’t duplicate?
- What processes are required from the users?
- How are we handling support?
- I also like to look for areas of risk. What happens if the vendor’s server goes down? Where should we build alerts into the processes so that IT is notified of problems? What is the impact of bad data? We could go on and on, but this blog post is already too long…
At this point, we have enough project definition to create a realistic estimate of costs and time. Since we did at least one proof-of-concept, we should be fairly confident that we can succeed with this project. If your project includes a purchase, you probably want to get competitive estimates from similar solutions and perform analysis to compare vendors (I cover some options here). All that’s left is to sell it internally and get it done!