Sunday, February 27, 2011

Reflection on EDUC-6145

(Kelly, 2009)
Reflection on EDUC-6145 Project Management in Education and Training
At the conclusion of each course I am taking at Walden University, I am required to write a brief reflection on the course. This is the reflection I  wrote on the ”Project Management”class I just completed.
Rarely have I completed a course with the same level of enthusiasm for what I have learned. I have informally lead or managed many different kinds of projects over the years, but I have never felt I was good at it. In the past, I have written down my objectives, researched the topics involved, and have borrowed heavily from someone else’s plan, or better yet, found someone else to manage the project!
After taking this course, I’m already looking for ways to exploit and develop my new skills. I’m enthusiastic. I am especially enthusiastic about some of the online project management tools I have encountered over the past few weeks, and of those my greatest enthusiasm is for the tools that leverage online collaboration. My immediate plan is to start employing project management tools for the routine projects I manage all the time. Long-term, I think software tools can be over used. Sometimes a notebook and a pencil is the best tool for the job, but for now, I intend to leverage every project as an opportunity to develop my skills.
In the context of education and instructional design, I see potential for synergy in the similarities and differences between the disciplines of project management and instructional design. Design processes in any context involve iterative cycles of analysis, design, development, testing, and review of test results. Instructional design is no different. The design process involves testing and debugging, or in some contexts, trial and error. Design can be messy, and its results can be unpredictable. The messiness of the design process is where project management can assist. There is a danger that management objectives can stifle the design process, with quality suffering for the sake of a predictable timetable. However, planning of the development process with clearly defined objectives to prevent scope creep, can streamline the process without sacrificing quality. In practice, the structure provided by good management can benefit creativity by allowing the creator freedom to focus on design issues.
I have already used my project management knowledge to help a friend brainstorm an entrepreneurial project. When brain-storming, mind-mapping can be a great way to organize thoughts that seem to defy a standard outline. While there are some great mind-mapping software packages available, a pencil and paper is all it takes to begin a plan. Draw a circle in the center of a page, and put your main idea there. Then let the main idea sprout branches and roots, and see where the idea takes you!
Reference:
Kelly, Will. (2009, December 14). Project Management Tools: Beyond Gantt Charts [Web log post]. Retrieved from http://gigaom.com/collaboration/project-management-tools-beyond-gantt-charts-2/

Thursday, February 10, 2011

Scope Creep

youngentrepreneur.com
Scope creep refers to changes to targeted objectives after a project has begun. In my experience it generally results from failure to clearly define objectives initially, although it has also happened after initial prototyping when others begin to see potential applications for the project that are outside the initially planned context. (Portny, et al., 2008)
As a programmer, I encountered scope creep in the form of program changes that really should have been handled as new projects, but were instead added to current or recently completed projects. As with most projects, a programming project has defined users and a defined environment in which the software will be used. Assumptions are made about the equipment that will be operating the software. Assumptions are made about the kind of data that will need to be stored, and whether that data will be stored locally, or on a network.
One extreme example of a programming project that was negatively impacted by scope change began as an unofficial proof of concept program by an engineer who felt software could be written that would save time by assembling a PLC program from a list of standard operations. The initial proof-of-concept was written to program one test machine that was not actually connected to any equipment. The program allowed an engineer to select from a group of pre-defined sets of instructions to create a program to operate automated heavy machinery. Then it read back the program to demonstrate the instructions were sent properly. Next the program was altered so that it could store its instruction sequences to a program file on a laptop. When I thought the project was complete, I was suddenly confronted with several requests that pushed the capabilities of the original test design. Engineers wanted to be able to connect to a variety of machines, including completely different kinds of machines that stored information in different ways. New subroutines had to be written for each kind of machine that the program would interact with.
Some engineers wanted to use the program for troubleshooting a PLC that was off the network. They wanted to be able to connect to PLC’s directly or over the network. Then they wanted security protocols added so that all engineers could see the program code on the PLC, but only certain engineers could alter programs and change them. After network security protocols were added, they wanted to have the same capability whether the computer was connected via the network or when connected directly to the PLC.
Other departments began using the program. Suddenly slow operation of the program (that was designed to test a concept, not to actually run in a production environment) was identified as a cause of production delays. With many more people using the program, there were demands to override security by people who may or may not have understood the safety issues involved in using the program. Meanwhile other departments were demanding to use the program to read parameters from a spec database to standardize machine setups and eliminate the step of having engineers write the PLC programs.
Finally it became necessary to stop all changes to the old program. A new programming project was properly designed to replace the old program, which eliminated many of the conflicting uses of the old program, such as the ability to run on the network and from a laptop. The old program was retained for its ability to display existing programs, but it was no longer used to write and store new PLC programs.
In hindsight, the prototype program should never have been put into use in a production setting. At that point, a new project should have begun, involving all departments that would be using the program, to insure safety and to ensure performance demands for all possible users and environments for the program were considered and planned from the beginning.
References:
Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Tracking projects and maintaining control. In Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.

Thursday, February 3, 2011

Estimating Costs and Allocating Resources For Instructional Design Projects

Today’s blog assignment is to search for resources that would be useful in estimating the cost of instructional design projects. I began my search using Google Scholar with keywords like “Costing Instruction.” I found a number of useful resources that discussed the convergence of project management principles with instruction design principles, but nothing that directly discussed cost estimates. I broadened my search to include all web sites, but that search did not provide any useful resources either. Finally I searched specifically for the title of my blog assignment, “Estimating costs and allocating resources.” I got a couple of useful hits:
Estimating Costs and Allocating Resources In Instructional Design
December 2nd, 2010
http://www.ablsc.com/distance-education/estimating-costs-and-allocating-resources-in-instructional-design/
This link could easily be another student’s post from a previous session of the same class I am taking. The author discusses two links providing useful information about costing instructional design projects. The first link is a paper describing a step-by-step process to cost development of an instructional web site. The second is a report describing a similar process to cost a software development project.
How to Estimate Training Time and Costs
Posted on by Jenise
http://ridgeviewmedia.com/blog/2010/05/how-to-estimate-trainingtime-and-costs/
This link is also a review of other websites that discuss costing of instructional design projects. Its resources include a paper published by the ASTD on the cost of developing one hour of instruction. The next resource is a forum discussion on the time required to develop a course. The last article discusses how to track project hours. 
Then I tried searching the title of the last blog I found, “How to estimate training time and costs.” I found additional useful hits:
Simple Process To Estimate Times and Costs In A Web Project
by Antonio Lupetti
http://woork.blogspot.com/2009/02/simple-process-to-estimate-time-and.html
This link is a nicely illustrated guide to estimating the cost of a web project (not necessarily an instructional design project).
Estimating Costs and Time in Instructional Design
http://www.nwlink.com/~donclark/hrd/costs.html
The last resource may be the most comprehensive resource I found, and it is geared specifically to instructional design projects. It discusses budgets, development costs, and development hours, with a focus on the resources required to develop one hour of training.