Context Identification, Policy Problem Definition & Modeling

Part 01

1.      Context, Environment of the Problem Situation

The faculty members at X polytechnic University uses many forms of learning management systems (LMS) to support their teaching efforts. The variety of LMS adopted causes problems for students since it leads to a new learning curve experience all the time and causes problems for support staff in providing trouble shooting and other support services. This wide spread inconsistency has caused many student complaints as well as a logistical nightmare for the support staff.

Extent of the Problem – the problem is university wide and students who take different courses between different faculties do have many issues in using different LMS to support their learning efforts.

Client, Policy Makers and Stakeholders – The client is the Educational Technological Committee (Edtech) which is advocating to implement a common LMS to be adopted across the university. The policy makers would be the university senate which has the authority to approve or reject any policy on this topic. The stakeholders include faculty members, who continue to use LMS arguing for academic freedom, students who complain about the varying formats, the technology support staff who faces day to day support related issues and the faculty association who is concerned about faculty rights.

The Analyst – Is a faculty member who has been hired by the Edtech committee. As a former member of this committee, the analyst is bias towards using a standardized , one size fit LMS.

Other Considerations – One important consideration is the present collective bargaining agreement that has been signed between the management and the faculty association that will have a significant impact on the implementation of any policy on this area.

2.      The Problem that can be Resolved

Definition Alternative Effects
There are too many LMS used for classroom teaching   between different disciplines Use a standard, one sixe fit all LMS to teach in   classrooms Resistance from faculty, easier for students, less   costly for support, increased consistency of LMS used
Too little knowledge of common LMS that could be used   for classroom teaching  between   different disciplines Improve the knowledge of standard LMS  available Increase in training costs, increase in support cost   in the short run, decrease in support cost in the long run, increase   consistency.
There is too little interest in considering a common   LMS for  classroom teaching between   different disciplines Create an inter disciplinary committee to look   at  possible common LMS Identification of common usage requirements, better   knowledge of differences in teaching needs, identifying a common goal.

3.      One Problem Definition

The problem definition that is selected to continue this discussion is the 2nd option. The 1st option is eliminated since it could cause resistance from faculty as well as there would be implementation issues. The 3rd option will be shot down from an academic freedom point of view. The analysts being a former member of the client committee, holds the same view of the problem as the client.

Variables

Too little 80% of faculty members of the University
Knowledge An understanding of how the medium could be similar   although the discipline is different
Learning management system A software program that could be used support teaching   and learning experiences
Classroom teaching Imparting knowledge in a classroom context.
Different disciplines Different subject expertise fields. Example   Business, Humanities etc

Criteria

  • Interdisciplinary use – able to use among any discipline taught in the university
  • Adaptability – ability to customise according to user requirements
  • User friendliness  – ability to learn how to use and navigate without extensive formal training
  • Cost – cost of development, support to be within the annual technology budget
  • Support – able to maintain it (backup, storage space) within the existing technology infrastructure
  • Consistency – Use same knowledge of the technology to navigate every time the system is used
  • Security – the applications should have user control access and managed by an administrator.

Policy Alternatives

One policy alternative could be to identify a common readymade LMS that is available in the market that could be adopted. A second policy alternative could be to hire a software development organisation and develop a customized LMS that would meet the organization wide teaching interest. The third alternative could be to use a web based application LMS (web 2.0) to meet the diverse needs of the organisation.

Part 02

Models of Choice

The analyst would like to use a comparative model and a cost benefit analysis model in finding possible lab solutions. The comparative model will provide the analyst the opportunity to compare between different LMS available and to see how it fits the requirement. The cost benefit analysis would help the analysts to consider the benefits that each option may offer to consider the viability in presenting possible lab solutions. Both these models will find common ground with the problem definition since they look for common application formats.

How These Models will be Applied

The comparative model will indicate development and implementation issues between different LMS that are available to see the common interfaces that could be used by different parties. The cost benefit analysis model will present the benefits of each LMS and the associated financial, social and opportunity costs.

Applying One Model

The analyst would like to draw the attention of the reader to appendix 01 of this analysis. Based on the comparative model presented here, the reader may note that there are many formats that would provide a common LMS. The following lab solutions are suggested based on this model.

Lab Solutions

Lab Solution # 1

Get the trial version of Moodel, WebCT, Black board and run a pilot project between two faculties to support their teaching efforts. Already these applications are used by different faculty members although none of these are endorsed by the university as a whole. The outcome of the pilot project could be used as a training solution, to counter any resistance towards using one of the LMS and also to test this against the set criteria.

Lab Solution # 2

Develop a web based LMS using an application such as Google Apps with a standard format that could be used between different disciples to support teaching.  Due to the development aspect involved in this alternative, the two faculty members who are identified should be given quarter time release to facilitate the development and the eventual implementation.

The reader may note that only two lab solutions have been presented although there are other options to introduce other LMS. The reason being, the above two lab solutions are the most politically feasible options given the interests of the client and the other stakeholders. These lab solutions are now applied to the initial criteria that has been set out in part one. (Note: More lab solutions will be suggested when model two is taken up)

Applying Criteria to Lab Solutions

 

Criteria

Lab   Solution # 1

Lab   Solution # 2

Interdisciplinary use

Very High

Very High

Adaptability

Very High

Very High

User Friendliness

Moderate

Poor

Cost

High

Low

Support

High at the beginning.

Training support at the beginning

Consistency

Very high

Moderate

Security

Very High

Very Low

Chances of these Being Adopted

After applying the criteria to the possible lab solutions, the first lab solution would most likely be adopted by the client and the stakeholders. The reasons are highlighted below.

  • For the client, it meets all the criteria in full. Although the second lab solution may meet many other criteria, on security grounds it may get rejected by the client.
  • Faculty members could also easily transfer their existing formats to any one of these LMS giving them some form of choice and flexibility.
  • As for students, migrating between the 3 formats of LMS would be easy, since they all belong to the same generation.
  • The support staff may advocate these positively since all these LMS provide a higher amount of implementation support.

This will eventually allow the client to advocate for a standard application at a future time.   The feasibility analysis will further support the provision of alternatives which will be discussed in the next section at a future date.

References

 Geva-May, I (2010). An Operational Approach to Policy Analysis: The Craft. Boston: Kluwer (1997, 2001 with Wildavsky, A.); New York:Palgrave Macmillan, 2nd ed.: Chapter 1

Bardach, E. (2009) , A Practical Guide for Policy Analysis: The Eightfold Path to More Effective Problem Solving. Washington, D.C.: CQ Press, 3rd ed.: Chapter 1

Miller, M. (2009), Introduction to Google Apps, Prentice Hall, Pearson Education Canada.

Learning backboard /Webct , extract from www.ibritt.com/resources/blackboard-webct.htm

E-learning light , extracted from http://www.e-learningcentre.co.uk/eclipse/ Resources/usingvles.htm

Appendix 01 – Comparative Model

 

  Market Solution – Vendor   based Open Source LMS Market Solution – Vendor   Based Close Source LMS Market Solution – Web based   Open Source LMS Custom Solutions – Developing   a customized LMS soft ware program for X polytechnic.
Examples Moodel, WebCT, Blackboard Customer written market solutions Google Apps. Ning, Facebook etc Software company developing software
Development Purchase license to use , install the software to   common server Purchase license to use , install the software in   vendors server

 

None Needs assessment by software company with different   faculties,

proposal presentation,

buy-in from different faculties, suggest alterations

Support Staff Assign support staff for initial set up, initial training   on usage Assigned support staff liaise with vendor, initial   training on usage by vendor Assign team to initiate the project, train user by   project team Assign support team to provide system access, back   up, roll out

 

Users User makes requests, assign to templates development   template and backs up User makes requests, assign to users, the template   is  developed and managed by the user.

 

User down load web applications, user develop   populate applications based on teaching needs, the web browser backs up   content, trouble shooting by user User populate based on common parameters

 

Back End Support team carries out master back up and trouble   shooting Trouble shooting done by vendor at a cost Project team provides general support Trouble shooting by software developer

 

Advertisements

Comments are closed.

%d bloggers like this: