Tips & Tricks
Featured Article: Getting started in Open Source and Education (Part II of IV)


Part 2 - Planning:

Last month you began a four part journey to get OpenSource software into your school. If you did your homework, you should have gone to some sites, looked at your own IT needs, and made a nice list of answers, and more questions, and even more answers. This list should answer: "Where are we?" and "Where should we be?" This month, we move onto the next phase: Planning.

Now that we have a rough estimate of what our needs are and what tools may exist to meet those needs, we can begin to plan.

Obviously the plans will differ depending on the complexity and scope of your assessment, but the broad strokes will fit:

  1. Establish a time line.
  2. Pick the low hanging fruit.
  3. Choose one or two pieces of higher hanging fruit.
  4. Establish milestones and deliverables.
  5. Produce the plan.
  1. Time line- This is one of the hardest things to establish and stick to, but it's the kiss of death if you don't do it. You need to give yourself an end point, or you will never finish. Yes, these things are never "finished", but portions of your deployment will have a drop off.

  2. Pick the low hanging fruit - These are tools and applications that exist today and can be deployed immediately, or with the shallowest and shortest resource curve possible. General classifications of use such as web server, e-mail server, file server, browser, chat client, e-mail client fall neatly into this category,as they aren't reliant on closed standards or code. These are also the types of things with the most stability, peer support, and documentation, as they were among the first itches OpenSource and Free Software scratched. You'll find that applications that won't draw end user push back go well here (i.e. Evolution looks so much like Outlook, folks may not even notice, let alone care).

  3. Higher hanging fruit - These are things that would be really nice to have on the first pass, and could conceivably be accomplished. For example, testing key proprietary apps under emulators like Wine, and deploying. Finding similar tools and apps that meet the same function, but may need testing, training or documentation. Projects involving coding or big data migrations belong here.

  4. Establish milestones and deliverables- This is the twin cousin to the time line - if you don't know what you are delivering, and when, your project will creep on and on and never appear to produce anything. You will also lose any sense of accomplishment gained by "checking things off" your list. You have to know when you are done, and you have to have something to show for it. You have to be able to say you accomplished the usual PLUS these x number of things for this much less (time, money, resources).

  5. Produce the plan- Many folks are familiar with MS Project, but you can easily use MrProject as an alternative and have the management of the project be as much proof of the concept as the project itself. Get your plan into a spreadsheet or project management tool. If nothing else it's a good thing to reference when the pointy haired boss appears.

Some advice:

  1. Don't allow scope creep - (ie if it ain't in the plan, it waits)
  2. Don't allow feature creep - (ditto unless it's fruit that fell right off the tree)
  3. Move aggressively when you can.
  4. Establish and manage expectations (be realistic, be pragmatic)

One thing to remember about expectations, most folks prefer the known evil to the unknown, no matter how good it may potentially be. Each of your planned initiatives will have to outshine the existing in order to get anyone's attention. If you are expected to land on the moon, but only orbit the Earth, you have failed, no matter how cool orbiting the Earth is.

Be prepared to face underwhelmed audiences until the bottom line is directly affected. Be prepared to have people be mouth agape with astonishment at some very simple things, as well.

Now that we have the broad strokes, you need to establish the dependencies. Ask yourself:

Who will support this machine? Will they need training? Who will use this application? Will they need training? Who will migrate these e-mail users? Me? Okay, how do I do that? Do I need training?

You begin to see a pattern. The main reason you have your current solution is that people know it. Part of the uncertainty surrounding OpenSource software is the perception that it's got a built in learning curve and the other part is the existence of a built in learning curve.

Getting the solution on paper is one thing; deploying, configuring, managing and supporting it is another. Your project may lose scope in this portion of the phase, but don't lose heart. What you are left with is something you can point to and say, "I did that with nothing... imagine if we reallocated spending here and here..."

Your homework for this month is to establish your time line, milestones, deliverables, and go back over and align dependencies with owners. If you get that far you're ready for the fun part, next month's topic:

Getting started with Open Source in education - Part 3: Execution


Read Part 1: Assessment