United Way Logo

Programming and Instructional Design with Microsoft Office Tools

In my current position I work jointly as a Grants and Financial Compliance Specialist for Community and Family Resource Center and for Tippecanoe County Child Care Federation. I have learned many things in this position and one thing in particular. When working for not-for-profits - you make do with what you have on hand. You also wear many hats.

Not-for-profits often struggle just to get the hardware, networking, infrastructure, and basic software needed to operate. I believe my two organizations have done an exceptional job in that respect - they share an IT department of one individual who also oversees all physical facilites - the Southside Community Center, the Head Start Center, the Counseling Center, the various Day Care locations, etc. He has an IT staff of one part time student, and a physical facilities staff of 2 individuals. Yet he has managed to give us and to maintain a robust client-server environment, a website, and well set up workstations.

What I'm saying is that not-for-profits don't have access to all the traditional programming resources for creating various end-user software applications and locking them down tight. Or perhaps not-for-profits must be more experimental and go through various models before they "get there." While they can get significant discounts for software at sites like Tech Soup, the cost of maintaining or even out-sourcing programming services for on-going application development and maintenance can be very cost prohibitive.

I have used Microsoft Office Programs and SharePoint Services to create, or as I prefer to say, model a tickler system and collaborative work environment for grant reporting in Outlook, a time sheet/activity report, various Productivity Tools, a Creative Curriculum Assessment Tool, and a CDBG Client Reporting Tool in Excel, and to run queries on a proprietary piece of Software ORS with Access. I have also designed accompanying training pieces in PowerPoint.

I think several of these tools could end up as database-driven, web-based applications on a collaborative platform or intranet - and in fact, with SharePoint Services, intranet construction has already begun. But in order for us to leverage our software and hardware to maximum benefit for the organization, these applications must first be socially negotiated.

And here's why I like being where I am. After earning a bachelor's degree in education, and then teaching for a while, and then earning an associate's degree in computer programming technology and working in the IT field for a much longer while, and then going on to earn a master's degree in educational technology and Instructional Design, and doing design work in that field, I have reached an informed opinion about traditional systems design theory. It's rather simple, really. I think that in its approach to software design, and in particular to design of traditional business and other end-user applications, systems theory tends to want to override the human cognition factor. It almost treats it as if it were the enemy. This is kind of understandable really - it's a temptation for any programmer to see how many hoops we can make that computer program jump through. But sometimes we tend to want to go too far and design the human right out of the system. Traditional systems design theory is also not constructivist enough to my liking - it doesn't go far enough in addressing and facilitating the social construction and negotiation process that inevitably accompanies the design or acquisition of any new end-user application. Traditional systems design theory rather tends to emphasize speed and economy - how fast can we get it done and how little can we pay for it. In doing so, it can sometimes 'shoot itself in the foot,' as many veteran systems analyst well know.

In short, I think that instead of designing the human out of the system, we should design the system to scaffold and support the human's cognition - not override it. And that's the challenge in programming and designing with tools such as Excel and Outlook where you can't lock things down nice and tight, (nor in terms of long term maintainability and staff turn-over would it be a good idea to) and where successful execution depends on user understanding. The other advantage of being where I am, in a smaller organization, where one must wear many hats, is that I find myself more “situated” in the problems and the solutions. Educators and teachers have found situated learning to be a very effective approach – and I believe it leads toward more satisfying end-products in application development as well.

 

In case you arrived here through the back door ...