Well Formed Work Packages

Problem: Project plans are often developed in great haste. The pressure and the atmosphere often leads to poor work package definition and the result is that project planners often plan in haste and regret afterwards. Among the most annoying and disastrous instances of this include MeaninglessTasks and LogisticDisasters both of which are instances of AntiPatterns.

Solution: the way to avoid all of this is to require that all workpackages are well formed. What this means it that they fully spell out the EntryConditions, the PreStagedSupport and the ObservableDeliverable which properly terminates the task. The last integrative element is ClearlyNetworked based on LogicalNecessity.

I have found that following these work definition patterns creates far less risky plans than are often created when the patterns are neglected. When the characteristics of the program involve great risk, then it is essential to incorporate a RiskManagementPlan -- RaySchneider

I'm not sure, Ray, what level of planning you're describing here. My most recent (and ongoing) project is a payroll for 120,000 people with dimensions like (monthly, biweekly, hourly) pay cycle, (nonUnion, UAW, and several other) union, 30 or 40 different states with their taxes, etc etc.

To have a plan for doing this payroll, how many and what kind of WellFormedWorkPackages would I have to have? Thanks -- RonJeffries

If you have a plan at all, then you must have task definitions. These need to be in the form of well-formed work packages, else you will find that the planning is incomplete and prone to serious LogisticDelay. If the project is very large and distributed, then additional management tasks need to be incorporated such as PlanTrackingMeeting. It strikes me that the geographical dispersion and the cultural disconnect of the stakeholders you mention require a very serious and extended requirements analysis to make sure you have all the requirements. I frankly have not been involved in as evidently as politically driven a project as this might well be. My biggest projects were related to aircraft weapon system in the early 1970's - since then most of my software projects have involved embedded programming of instruments which are much smaller. There are obviously patterns that must be scale-dependent. -- RaySchneider

No, you don't have to have task definitions. At least, they don't have to be written down and formally defined. Maybe they are just implicit. Experts usually are able to work efficiently without being able to explain everything that they are able to do. Well documented task definitions are the exception, not the rule.

In general, these patterns do not feel right to me. I don't see them in practice very often, the groups that try to practice them usually seem too heavy handed, and you don't justify the patterns. Maybe I'm missing something. For example, I'm assuming that you want to document all the EntryConditions, which seems like overkill to me. Maybe you mean something else.

-- RalphJohnson

I think Ralph has a point when projects are relatively small - if they are large, failure to do these things can be disastrous. I think though that he is overloading my meaning when he imagines that I want to capture everything - that is unrealistic - but if you fail to capture the essentials you will miss all your LongLeadItems and find yourself with much more LogisticDelay than necessary. Those who fail to plan adequately are doomed to missing all their schedules ... which is the current state of art in software development. I was at a professional management seminar and the person giving the seminar said to multiply programmer schedules by four FOUR! to get a reasonable estimate of completion date. Tell me about how great the state of art is ... -- RaySchneider

I firmly believe in the principles that Ray is proposing. Over the last few years, I have been practicing very similar techniques on all projects I have been leading. Yes, you need to be pragmatic about the granularity of tasks but as a general rule I believe that all developers should be working on a task basis. To me, there is never an excuse for not planning how you are going to get from A to B and what exactly you need to produce as part of this.

We have successfully used the technique to direct offshore development teams. -- AnonymousDonor