A common OSS problem

A long apprenticeship is the most logical way to success. The only alternative is overnight stardom, but I can’t give you a formula for that.”
Chet Atkins.

Thanks to a recent comment from Laurence Smith regarding training (see here), I thought I’d elaborate on a theoretical approach I have mulled over previously for overcoming a common issue experienced by OSS implementation teams.

I say it is a theoretical approach because I haven’t been in a position at a CSP to actually trial it. Therefore I’d love to hear your alternative approaches to resolving this common problem.

The common issue can be summarised as follows:

  • A CSP‘s operational staff are almost always already over-loaded before starting a new OSS project
  • The CSP‘s operational staff have to give priority of effort to pressing operational needs such as resolving outages compared with OSS projects
  • The CSP almost always believe that the OSS will be almost as easy to learn as a word processing application for their operational staff
  • The CSP almost always believe that the OSS supplier will be able to implement their solution with negligible input from the CSP‘s operational staff [Note: my theory on any project is the more you put in, the better results you’re going to get out and this has proven to be true on every OSS project I’ve worked on]
  • As such, the CSP almost never assigns additional staff to assist the supplier
  • Nor do they assign enough time for their operational staff to do OSS apprenticeships
  • The CSP almost never realises that their operational staff will need to be quite knowledgeable about the supplier’s whole solution (application, data modelling, interfaces, processes, etc) before they can adequately authorise / accept the solution from the supplier (eg via a User Acceptance Test – UAT)
  • As a result of all these things, the CSP budgets for the supplier’s costs, but often underestimates their own internal costs when preparing their business case for project approval

So anyway, back to my theory, which is as follows:

  • The CSP‘s operational linchpins are going to be required by the new OSS project because they are the ones who are able to make connections (people, data sets, etc) that hadn’t existed before the OSS project came along
  • These linchpins need to be extracted from day-to-day operational issues and less experienced staff are inserted into the linchpins’s roles
  • The linchpins then oversee and guide their replacements, only jumping into operational issues when escalation is required
  • Having the lower-priced replacements lowers the internal costs associated with the OSS project and provides a development pathway, which is good for morale
  • As the replacements get up to speed, the linchpins are then increasingly freed up to dedicate most/all of their time to the OSS project
  • The implementation team can then rely upon the linchpins more to provide the information that only a CSP‘s linchpin could find or derive
  • This allocation of linchpins by the CSP is a relatively small investment to make considering that most OSS projects are cornerstone projects for the organisation in terms of cost and impact
  • The implementation team needs to develop techniques to gain buy-in from the linchpins and make them into project champions because by nature these people tend to also be the key influencers at a project / peer level

I know this is a generalistic plan that falls down if your linchpin is good at problem solving but not good at training others or not willing to relinquish ownership of the current operational tasks, etc. When it comes to personnel, every case has to be treated on its merits obviously.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.