Defining Work : Break it down

If web or training content [and I believe even software and other products] is to be developed from several different places by people who probably have not met each other face-to face, it is important to break content down into small manageable chunks. John Van Dreser, a colleague of mine, introduced me to the concept of breaking design and development work into work packages that are more or less uniform in size, in terms of development effort.

We broke work down into small chunks and called them work packages. We defined a work package based on the effort involved, the skills involved and the value it delivered. So when there we started a Project, we broke it down into several assignments, broke assignment down into several tasks and broke tasks down into activities.

When a person requested for work, they defined what the work is in terms of the above mentioned terms. Over a period of time the usage of terms diminished and the protocol was tacitly understood by most team leaders. Several others simply followed. Every work package when requested was given a unique id and team's refered to the id when they requested for work.

Estimate the effort required: When a project was broken down into activities, we could attach a work effort with every activity. Since learning content development was not as clearly defined as say - assembling an automobile, we used a simple approach. We found out what the total price of the project was [based on what the market was willing to pay], reduced the profit margin from that and calculated the number of hours available to develop the content.

Different team members such as Instructional Designers, Visual Designers and Content Integrators were them informed about the exact number of hours that were available to them to complete their work. It did not work perfectly all the time. However we recognised the areas that need some sort of automation or special attention.

Caution: Not all team members care about profitability of the company [as ironic as it may sound]. While all of them have the right itentions not all of them have the right know how to run a project profitably. This aspect will require special attention by leaders at the top.

Do we need a online system or software installed to follow this? No. The protocol is independent of any software or system. It is a simple, commonly understood development discipline that needs to be communicated to everyone and understood by everyone.

However, after a few months of using the work package protocol and once the behaviour change was accomplished, we did build an online system that enabled people make these requests from an online form rather than use a word document and email it. There were different forms for different types of work and every type of request and all forms clearly stated what inputs are required from the requestor for the job to be completed effectively. Technology enabled current behaviour. It did not drive behaviour change.

The initial system which did not store or track the information was build using Java Technology in about 10 person days. It was recognized as a useful tool and a 2 member engineering team expanded it with backend database and tracking in about 30 person days. The effort we saved using this system will definitely be several times the investment of time. Once we grew in size we discontinued the protocol and went back to doing things the old way. However, other communicating improvements like cheaper conference calling and freequent meetings made up for the same.