This paper sets forth a new template for standards that define work and standards that define projects in the new age of technology. The APICS conference theme "Master­ing Change" is directly applicable to this presentation in that work is changing, so also are project tasks changing and the tools to perform those tasks are becoming more and more automated. Project managers and department man­agers need new guidelines to classify work tasks versus project tasks, and they need new guidelines for estimating task completion points, expected durations and acceptable quality at completion.

What Is Work?

In a world of committees and project teams it is easy to misclassify a task as a project when it really should be someone's work. Too many individuals and groups have become work adverse—consequently tasks go to commit­tees or reengineering task teams. Frequently "the work" never gets done.
We all work every day. Some work is tied directly to projects; some work is tied indirectly to projects; and as we reengineer processes, and move to continuous improve­ment work patterns, it becomes more and more difficult to differentiate what is "routine," "ongoing," "day-to-day" work versus what is a project or project team responsibility.

In some companies, project teams are set up for every­thing—each improvement, each new contract, each work method evaluation, each new system enhancement, every new system is a project. This approach burns people out, causes serious resource availability constraints, and fre­quently ends in nothing ever reaching its ideal end point or vision—just a whole bunch of half-way solutions.

Reasonable work definitions that define modern day work tasks might include:

1. Value added activity that benefits from consistent human decision making and intervention in a fairly repetitive manner.
2. Tasks not requiring radical redefinition and resys-temtizing but a more continuous improvement ap­proach.
3. Achievement of milestones and deliverables eas­ily accomplished by one person or a small group of individuals each capable of carrying out the task in a short period of time.
4. Tasks structured with arbitrary stops and starts based upon time clocks, company policy, or processes varying from six to twelve hours.

As we define projects and varying project structures these work definitions will come into clear contrast.

What Is a Project?

Characteristics

Projects can be characterized best by evaluating the scope and complexity of the deliverables involved and classifying the effort based upon predefined project models. Also, projects typically have a formal start date, a budget, milestones and deliverables and a projected end date. Projects usually require resources from more than one functional group simultaneously—if this is not necessarily required then you may not need a project structure or project control system with the added overhead in order to achieve the end point. Perhaps the simple synchronization of efforts by two or more departments is all that is really necessary. That is the responsibility of department heads not project teams.
Another criterion that is useful in determining if a project team approach is necessary is the need for reengineering a process or a group of tasks before a deliverable can be achieved. Reengineering efforts typically are task team oriented and usually cross functional boundaries. These efforts should produce radical changes in relatively short periods of time. The reengineering project team should not be in its eighteenth month without any deliverables on the table.

Varying Project Models

With the advance of open architecture systems and greater independence between levels in the open architecture more and more systems tasks can be performed independent of user involvement, and vice versa, independent of MIS involvement. Consequently some tasks that traditionally required a large project structure can now be accomplished by small MIS work teams and RAD teams.

To Be Continued