Blog: CEO’s Corner

agsdix-fas fa-home

Blog: Home

agsdix-fas fa-pen-fancy

Blog: CEO's Corner

agsdix-fas fa-code

Blog: Tech Talk

Blog: Product Releases

agsdix-fas fa-chalkboard-teacher

Blog: Viewing

Blog: Conversion

arrow left circle icon Blog: CEO’s Corner

You Can’t Take Flight Until You Get the Pilot Right

by | Apr 24, 2017

flight1320x742
Having been in the software industry for so many years, I’ve seen a lot of good ways to develop or integrate software applications. I’ve also seen some that are not so good. Everyone has heard of vaporware and knows that at some point you have to cut the cord on promises. However, what if something works in testing but fails in production? How do you protect yourself against that?

For anyone working on technical projects today, there is an accepted way to start a project. Here is a simplified step-by-step outline:

1) Kind of obvious, but you need to figure out what you want to do

2) Do this by tasking one person (or a small group) to perform preliminary research investigating the market for tools and services that may be needed.

3) Around the same time (or perhaps before), survey your user community to learn what they want. Ask for examples that they’ve seen. Have them write, or help them write, a use case that details the processes and workflow that will be done.

4) When the potential tools for the project are found, evaluate them for suitability and judge them against the use cases you generated. This is usually done via a pilot project or proof of concept that determines feasibility.

5) If the pilot is successful, roll it out to a full scale preliminary test.

6) If that test is successful, then go forward to limited production.

7) Once limited production is successful, do a complete rollout.

Note the words “suitability” and “successful” interspersed above. You need to have a successful pilot before you can go forward. Unfortunately, sometimes pilots are not representative of the production environment and valuable time is lost proceeding to limited production. One of the most common culprits for poor transitions from pilot to production is choosing different environments for pilot studies than the ultimate one. Yes, it’s easier to implement a test situation on a laptop with one user, but does that scale to a 500 user situation running on a larger server farm?

It is understandable that a pilot can’t duplicate a fully loaded product environment, but you should try to keep as many variables constant as you can. Here are some best practice tips for accomplishing this:

  • Have the engineer managing the pilot understand your production environment so the pilot will be similar in operation. Many companies use their junior engineers to create a pilot because they’re not needed in critical processes. That’s okay to start, but someone experienced must be managing the effort.
  • Keep the computers and OS the same – don’t switch from Windows to Unix when going to production. Make sure system resources are either the same or the product system is better equipped than the pilot system.
  • Don’t switch web servers or file repositories when transitioning.
  • In our industry, it is important to test representative documents that are similar in type and size. If you have 600-page PDFs in production, test similarly sized PDFs in the pilot. It should be noted that similar sizes in megabytes is not the same as a similar number of pages. Likewise, large Word documents are not the same as large PDF documents.
  • Duplicate the workflow in detail, if not in full production load. If your people are going to have 20 documents open at once, do that in the pilot. If portions of documents are exported as part of the process, test that in the pilot.
  • If a special enhancement is required in production, make sure you test that in the pilot.
  • Don’t shortchange yourself on computing resources. Too many of our customers or evaluators don’t invest enough memory in cores, disk space or data bandwidth. Ask your vendor for advice, but since so few vendors will know your system in its entirety, ask around. We have 256 GB of memory on each of our blade servers and we’re not running large production jobs. Resources are a great investment to insure the success of your production system.

 

When developing complex systems, it is rare that everything works perfectly. Expect problems, but just be prepared to efficiently solve them. The best way to do this is by having experienced people, reliable systems and trusted and experienced vendors that can help clear the hurdles.

Questions, anyone?