j e s r u s h . c o m

Hard drive loss (at home) is something nobody wants to think about. Imagine losing all of your music, financial data, documents, and perhaps most importantly — family photos. It could be caused by a virus, mechanical failure, fire, or even theft.

To mitigate the risk, you can backup your data to an external drive or use an online backup service like carbonite or mozy, but neither solution is adequate. Your external drive would be barbecued in a fire or gone in a burglary and the online backup services become too slow/expensive when you try to store 300+ GB’s of photos, videos, music, and movies.

Enter the ioSafe solo, a 1.5TB external backup drive encased in a fire resistant, water resistant, shell which can be tethered (locked) to a desk. This is a brilliant product. Highly recommended.

I wanted to share a handy little tool which I picked up awhile back: The PIECES framework. This short checklist is simply a list of things to think/worry about when designing, building, or implementing a system or application.

I suppose there are a lot of frameworks and checklists floating around out there, but this one happens to be really good. I use it not only for design, but also for change management to make sure I’m not forgetting anything. I have no idea who created it, but I’m forever in their debt!

Performance
   -Throughput
   -Response Time
Information (and Data)
   -Outputs
      +Lack of any information
      +Lack of necessary information
      +Lack of relevant information
      +Too much information – information overload
      +Information that is not in a useful format
      +Information that is not accurate
      +Information that is difficult to produce
      +Information that is not timely to its subsequent use
   -Inputs
      +Data is not captured
      +Data is not captured in time to be useful
      +Data is not accurately captured – contains errors
      +Data is difficult to capture
      +Data us captured redundantly – same data is captured more than once
      +Too much data is captured
      +Illegal data is captured
   -Stored Data
      +Data is stored redundantly in multiple files and/or databases
      +Stored data is not accurate
      +Data is not secure from accident or vandalism
      +Data is not well organized
      +Data is not flexible – cant meet new info needs from stored data
      +Data is not accessible
Economics
   -Costs
      +Costs are unknown
      +Costs are untraceable
      +Costs are too high
   -Profits
      +New markets can be explored
      +Current marketing can be improved
Control (and Security)
   -Too little security or control
      +Input data is not adequately edited
      +Crimes (e.g. fraud, embezzlement) can be committed against data
      +Ethics are breached: data or info gets to unauthorized people
      +Redundantly stored data is inconsistent in different files or databases
      +Data privacy regulations or guidelines are being (or can be) violated
      +Processing errors are occurring (people, machines, or software)
      +Decision- making errors are occurring
   -Too much control or security
      +Bureaucratic red tape slows the system
      +Controls inconvenience customers or employees
      +Excessive controls cause processing delays
Efficiency
   -People, machines, or computers waste time
      +Data is redundantly input or copied
      +Data is redundantly processed
      +Information is redundantly generated
   -People, machines, or computers waste materials and suppliers
      +Effort required for tasks is excessive
      +Materials required for tasks is excessive
Service
   -The system produces inaccurate results
   -The system produces inconsistent results
   -The system produces unreliable results
   -The system is not easy to learn
   -The system is not easy to use
   -The system is awkward to use
   -The system is inflexible to new or exceptional situations
   -The system is inflexible to change
   -The system is incompatible with other systems
   -The system is not coordinated with other systems

The other day I witnessed a major misstep when a vendor serving my own employer recommended a solution to us which was incompatible with one of our key business constraints.  Fortunately we caught the problem, and the proposal was scraped.

But not everyone is so lucky.  Insane sums are spent on rework for systems which were built with bad or missing information.  As someone who builds and implements these systems myself, I can’t say that there is a foolproof method for uncovering every constraint, assumption, requirement, and interface which might affect the solution I propose.

But I can say that there is a process of due diligence which must be systematically followed to try and fully understand the target business.  I decided to sketch a brief list of things which the project manager, business analyst, and technical lead should look at when building and implementing a solution:

•  Corporate objectives.  The suits might be leery of sharing the three or five year plan with a vendor team, but the more information you can get about the organization’s strengths, weaknesses, opportunities and threats — the better!  Is the organization growing, innovating, changing, and/or trying to cut costs?  If so, how are they accomplishing these things?
• Competitors.  Who competes with this organization?  What does market share look like and how have these competitors designed their systems?  How can they be outdone?
• The Industry.  Checkout the trade journals, attend a conference, and join any industry organizations.  You need to become a kind of insider who can help lead the customer to a solution which they never even considered.
• Org Charts 2.0.  You need to take the plain old org chart and dress it up with some key details for each department or entity: mission, function, and current initiatives.
• Infrastructure Charts.  How do the existing systems communicate with each other?
• Location Models.  Geographically, where does everything sit?  And what laws, cultures, and locale-specific variables change from one location to the next?
• Business Events.  What events drive the business? Do they come from customers, partners, suppliers, regulators?  Who springs into action when these things occur? Do they occur on a regular schedule?
• Process Models.  Workflows and interactions.

While so many customers (and providers) want to dive directly into the requirements gathering phase, there are huge benefits to first researching these domains.  It can mean the difference between a well conceived proposal and an expensive disaster. But more than that, it can lay the foundation for a customer-provider relationship which goes beyond this project.

Imagine if you (as a provider) noticed a trend in your customer’s industry which led you to design a solution for a problem which your customer didn’t even realize they had!