Peopleware or Employee-ware?

Tuesday, November 30, 2010
How to measure the complexity of a system? I still wonder. Is it that one with many decisions to make or is it the one with many results to produce? Or maybe a system that involves different users? Or a system that demands complicated users? Perhaps, that system which requires participation from resistant-to-change users? Well, obviously, I overstressed USERS as contributors to the complexity of a system because I have been encountering alike factors since the birth of the idea of this particular system I handle.

Certainly, for a system to work perfectly, it involves different components, hardware, software and peopleware. And maybe I am not that proficient enough to lecture about this subject since it calls for deeper academic discipline, let me just share to you my personal experiences from analyzing a system flow that will be later mimicked by a program.

Following the simple steps in the preparation for system development, I firstly, gathered the necessary data that the system developer requires. I designed a flow chart of the existing system so I will be able to draft a proposed system that would replace it - a better system. I interviewed different people, collected their suggestions, comments and mostly, I noted the existing system's advantages and inferiorities based on their experiences and my observations.

Drafting a new and better system is not easy. You objectify the system's efficiency, accuracy, quality and of course, the span of time to produce results. And you always have to project that there is no such thing as a perfect system. You have to expect that it would not run smoothly at first or even in the middle of a long-term system deployment. Well, you sometimes always have to think for failsafe concepts in case of problems that may be encountered.

So now, let's not totally focus on that, I am blogging this post because I am having problems with the peopleware of this particular system. They do not cooperate well, I am assuming that they don't want a new system because implementing it could mean reorganizing the system they're used to which is true but if you have to reconsider, we do not create new system if it is not better than the previous system right?

And that is dragging the system being developed. When they're told to do dry runs, they would excuse busy schedules as reasons, that complying the dry run without completing the whole process is useless since they have to double up their work, that is dry run on new system while working on previous system — two parallel tasks only that the new system has not yet been finished which they highlighted as the "useless" part.

Maybe this is not actually a factor to be considered as contributor to the complexity of the system. Maybe it's just another workplace dillema that needs to be fixed first before integrating them to system development but I just really wish that this system being developed would not run another year before it is finally deployed. One full year has passed and it's not totally fine with me...


Post a Comment