"Best Practices" eBooks and "Business Case" Templates

The United Kingdom’s http://www.e-consultancy.com offers a model of professional planning and service development.

In particular, the site offers free…

This resource site is not Open Source, but the site’s focus upon quality information provides an information service benchmark that Open Source projects can aspire to.

Here is the list of “Best Practice Guides” eBooks…

  • Web Design
  • Paid Search Marketing (PPC)
  • Search Engine Optimization (SEO)
  • Managing an E-commerce Team: Integrating Online Marketing into your Organisation [sic] (Note: Not an error, British Spelling)
  • Web Project Management
  • Online Retail User Experience Benchmarks

eConsultancy.com also offers a templates for building a “Business Case” for Web development.

I believe that building an “Educational Case” for Open Source, and for the Integration of Technology are missing elements of the wider strategy of driving improvements in teaching and learning.

Here is the model that eConsultancy.com uses…

  • Who this Business Case is For
  • Their Level of Expertise
  • Related Resources

Our work in promoting Open Source Solutions should focus upon developing and documenting an “Educational Case” for each stakeholder group within a school district. These “Educational Case” documents should detail the…

  • Instructional Goals, Targets and Benchmarks
  • Integration of Open Source with other Technologies
  • Project Management Best Practices for Deploying Open Source
  • Timelines, Milestones and Evaluation Criteria

Just stating that Open Source solutions offer increased opportunities for improving instructional delivery and increased student outcomes seems inadequate.

We must “Show and Tell” each stakeholder group…

  • Exactly “How” this instructional improvement is accomplished
  • Precisely “Who” has already shown the improved instructional outcomes
  • Precisely “Why” our Open Source solutions are easier, faster, more efficient, more effective than other solutions (Commercial, freeware or shareware solutions)
  • Exactly “What” is required to plan, design, develop, manage and evaluate Open Source solutions
  • Exactly “What” steps successful implementers took to achieve their successes
  • Precisely what professional development will be required, “How Much” that professional development will cost, and “How Long” the development cycle will take before “Measurable Instructional Results” will prove the value of our solutions

….and our message must be different to each stakeholder group!

Educational stakeholders require proof that Open Source strategies and solutions…

  • Provide increased opportunities for driving student achievement and for motivating lifelong learning
  • Require less effort and energy than implementing competing commercial products
  • Have a direct and measurable impact on increased student performance, including high-stakes test scores
  • Minimize the risk of failure and minimize the risk that the stakeholder groups that “sign off” on these Open Source solutions don’t “end up looking stupid,” or worse, “out of a job”
  • Maximize the use of current hardware and software investments by working seamlessly with other platforms (interoperability)
  • Provide a structured and streamlined transition to the Open Source innovations from current “Best Practices” to newer, “Better Practices”
  • Provide a structured and streamlined transition to teachers who will need to update their classroom management and instructional delivery skills to adopt the required constructivist, engage-learning, project-based strategies that research shows are more effective instructional options
  • Provide an implementation path that is stress-free, and provide the necessary follow-up support
  • Provide an implementation path that is scalable, so that pilot project can be rolled out in a streamlined manner once positive evaluation of the project and deployment kinks and hurdles are worked out

Our “Educational Case” for deploying Open Source solutions must address these concerns, allay fears and minimize risks that stakeholders perceive.

We must communicate to each stakeholder using that particular stakeholder’s frame of reference, targeting the issues that impact that stakeholder group. Otherwise, Open Source solutions, no matter how beneficial, will continue to be perceived as solutions only for the few and the proud “Techies” that can put up with demanding technical requirements and “quirky” configuration difficulties.

As technology becomes easier to use and more powerful, the productivity benefits associated with Open Source solutions must keep pace with our commercial competition.

Open Source solutions must free users from technical hurdles and must come to rival commercial products in ease of use and productivity. (Techies probably are the only group that care about technically superior solutions. Other stakeholders care more about what solutions can do for their productivity and care more about what impact any innovation project will have upon student achievement.)

“One Click” installation, configuration and transparent operation is the ultimate target for the Open Source packages that we support. And, promoting the widest possible use of Open Source products means cross-platform support.

Each stakeholder group wants to hear how Open Source will benefit them, and, each stakeholder group wants different benefits.

This is the reason that Open Source struggled to catch on in the past, and why implementation of Open Source solutions lags behind commercial solutions, i.e., commercial companies have multiple marketing campaigns aimed at the various stakeholder groups.

As Open Source advocates tailors our marketing campaign to target each stakeholder group, we need to ensure that every prerequisite and every requirement is in place, so that the Open Source initiative can be successful.

Savvy commercial firms do this by…

  • Ensuring that their product works on 98+% of computers with only a need to accept the defaults, i.e., Microsoft(TM) Windows
  • Ensuring that their product only runs on their proprietary hardware, i.e., Apple(TM)
  • Providing real cross-platform solutions, i.e., Sun(TM) Java
  • Providing third-party cross-platform support to expand the value of proprietary hardware, i.e., Parallels(TM)
  • Ensuring that their product is an industry standard, then providing the product to schools at 10% of the street cost, i.e., Adobe(TM) Dreamweaver, Microsoft(TM) Office
  • Ensuring that their product integrates with industry standard software (MS Word(TM), Excel(TM), PowerPoint(TM) and Project(TM), i.e., (fully) Mindjet(TM) MindManager Pro; (partially) Inspiration Software(TM)’s Inspiration
  • Providing discounts that are almost 60% off list to key, large-scale vendors, i.e., Cisco(TM)

And commercial firms devote separate sections of their Web sites for the various stakeholder groups.

Open Source integration projects need to embark on the same strategies that commercial products use to communicate value to the various school district stakeholders.

For example, instead of just offering an office productivity suite, like Open Office, why not offer a complete set of teacher and student tools, the way that Microsoft(TM) or Apple(TM) do? Then, make this set of tools platform independent, and market with different marketing messages concerning the benefits to…

  • Teachers
  • Students
  • Parents
  • Curriculum Staff
  • Professional Development Staff
  • District IT Department Staff
  • School District Administrators
  • School Board Members
  • The School Community at Large

And our message to each stakeholder group must communicate our “Educational Case” for deploying Open Source solutions in educational, not technical terms.

Do we have the data that show how Open Source solutions improve student achievement?

These data can be collected by…

  • Case Studies
  • Action Research
  • Head-to-Head Comparisons
  • Scientific Experimental Research Studies

Anecdotal records and testimonials lack the rigor and strength inherent in scientific research methods.

And, the endorsement of technical folks based upon technical requirements and specifications will fall short of impressing any school district stakeholder group, except the “Techies.”

So, even when Open Source advocates shows school district IT Department staff how Open Source projects can benefit their productivity; if other stakeholders are not convinced, the Open Source project can become a “rough row to hoe.” Any IT project can be “more trouble than it is worth” if…

  • Users complain (or revolt)
  • The projects components remain unused
  • Various stakeholders didn’t want the benefits that the project was designed to deliver
  • Projects have to be re-developed or redesigned
  • Projects have to be dropped and commercial solutions need to be deployed for a substitute or replacement project at greater cost (and with greater urgency)

So, Open Source advocates must craft our packages with patience and deliberation. We must conduct “wide and deep” needs assessments for each stakeholder group, and we must ensure that our solutions packages deliver on the most needed benefits to each group.

Then, we must communicate “Educational Case” benefits to each stakeholder group. And, we must back up our claims with research and real-world data.

Building our movement according to educational “Best Practices” requires planning and patience.

How Open Source advocates markets our Open Source packages to each school district stakeholder group will probably have more impact on our success than the sheer technical superiority of our solutions packages.

It is the “Educational Case” for improving instruction and for increasing student achievement that determines whether a strategy is a “Best Practice” or not. The formula is simple, i.e.,…

  • The innovation drives instructional progress, student achievement and positive student outcomes
  • The progress can be measured
Share and Enjoy:
  • Digg
  • Bumpzee
  • del.icio.us
  • Facebook
  • Furl
  • Mixx
  • NewsVine
  • Reddit
  • StumbleUpon
  • YahooMyWeb
  • Google

Leave a Reply