Share via

You Never Know What You Don't

  • Article

I was once asked by a colleage at a previous employer what skills would be required to implement and maintain a piece of software we sold. After thinking about this a bit, I wrote back with three points:

  • Software Development Experience
  • Motivation
  • Interest

The answer I received in reply isn't fit to print.

A well planned project includes a list of tasks that need to be accomplished in a given order, and sets expectations as to the timeframe those tasks should require. It's an artform or sorts. Some tasks come in quicker than the estimate, some longer, but the goal of project management is to manage the margins. Basically, to keep tabs on where everything is and where everything is trending so that you can adjust your long term plans before you get so deep into it you'll never ship.

In this particular case, this software package required both infrastructure/operational elements and development elements. Infrastruture and operations were pretty much the same as most apps - database servers, network connectivity, load balancers, etc. The development elements were also pretty much the same for any customization effort - knowledge of the API would of course be helpful, but isn't strictly required. You'll pick things up as you prepare for the project, and the timeline assumes someone is new to the product.

The answer this person wanted was that we needed people with experience deploying, customizing, and supporting the product. The challenge was, the client in question had never deployed, customized, or supported the product. The only way the client was going to get those skills was by doing, with someone who had done it before walking behind everyone, prodding them along and keeping them inside the margins.

That's just how products are adopted. Sometimes you get an opportunity to send a bunch of people to a training class, and if you can swing it, that's great - a definite help. But training classes and the real world seldom intersect in a way that improves delivery - if anything, they serve to highlight to the person the fundamentals of the product they are deploying or customizing. You know know what you don't know, and know what questions to ask. This is also the goal of project preperation, where you plan out activities in detail and send people off with manuals and documentation in the bags. In many instances, training represents a different sort of documentation delivery.

And for the record, I'm not knocking formal training. Consider this - in college, you bought this big expensive text book. If you were dilligent, you could have read the text book end to end, taken the exam, and passed. You could have taught yourself. Or, you could take your textbook and attend class, where your teacher explains the things in the text book to you, and shares his or her own personal experiences. Now product training and documentation may not have the wide gap in knowledge adoption that say, a calculus class and a calculus text book might have, but the same thing goes.

Comments