'''''Is this an AntiPattern?'''''

Sometimes tasks that are unnecessary or meaningless are put into plans to flesh them out and create a cushion of slack. The best program managers or project engineers will generally catch these and convert them to an ExplicitPad. Less good managers and engineers will use meaningless tasks instead of explicit pads, although sometimes inserting meaningless tasks is the easiest way to deal with "higher ups" who just don't understand.

Examples of meaningless tasks include:
	1 unnecessary analyses,
	1 prototypes of well understood low risk entities,
	1 documents that are unnecessary because they are never used for anything
** (I have some real doosies here from my government years ... my favorite was the "value engineering reports" required by the sponsoring agency that were written by junior engineers to fufill a requirement, were put in wall lockers when they were received and were never read ... but cost $200K out of a $1M program ... go figure!)

Often meaningless tasks are incorporated by managers who don't understand the domain and want to look good and because they read a book somewhere or they think the deliverable sounds necessary they incorporate it into the requirements and the contractor or developer doesn't have the guts to stand up and say this is a meaningless and useless task -- everyone salutes and it costs schedule time and money ...  Sometimes meaningless tasks are simply a way of concealing schedule pad ... the managers know they are meaningless and they will never be worked on -- but because they are on the schedule there is more time built in than could be defended without the meaningless tasks.

-- RaySchneider