DeMarco, Lister and Parkinson

In chapter 5 of their best-seller "PeopleWare: Productive Projects and Teams", DeMarco and Lister conclude that "programmers seem to be a bit more productive when they can do the (feature) estimate themselves, compared to cases in which the manager does it without consulting them." Backed up by scientific data, they construe that "projects on which the boss applied no schedule pressure whatsoever had the highest productivity of all." If the above statements were true, wouldn't it be best to "protect" the development team from project managers? Wouldn't the techies be better off left alone?

Not according to Cyril Northcote Parkinson, the author of "Parkinson's Law: The Pursuit of Progress". According to Parkinson, "work expands so as to fill the time available for its completion." In other words, give a developer 2 weeks to complete a feature, and he/she will get it done in 2 weeks. Give them 3 weeks for the same feature, and they will use up the 3 weeks.

I firmly believe that every software development feature has a two-day, two-week, and two-month version, and that without deadlines, some developers will waste time adding bells and whistles that offer little or no value for the customer. As a former software designer myself, I can assure you that developers appreciate timelines. Not only does a project schedule provide a sense of urgency, but it can also be a great source of motivation. Knowing that an actual customer is impatiently waiting to try out your piece of code can be extremely encouraging.

Nevertheless, one shouldn't confuse an appreciation for timelines with a lack of maturity and dependability. Unlike what certain managers believe, developers are not lazy people who only get work done when faced with an overly optimistic schedule. As explained in “Excessive Schedule Pressure”, not only will an unrealistic plan increase project risk, but it will also have a negative impact on the quality of the release. Consequently, the poor quality of the product will eventually force you to over-invest in software maintenance, which will directly increase the overall cost of the solution. Furthermore, consistently pushing your team to work evenings and weekends will eventually damage your relationship and might even lead to some of your top developers resigning midway through the project.

As a project manager, I'm sure you already have a preconception as to who's right between the two schools of thought. If you accept as true DeMarco and Lister's conclusions, then your management style most likely is laissez-faire. You assign individual features to developers early in the project then sit back and enjoy the ride. You are confident that your developers will deliver on time and according to specs. You feel that applying schedule pressure will be a waste of energy and perhaps even counter-productive. On the other hand, if you live by Parkinson's Law, you probably push your development team as hard as possible, and perhaps even maintain two project plans: an aggressive one that you share with your development team to "motivate" them, and a padded one that you review with your customer to protect yourself from any potential schedule slips.

Which is the most effective approach? How do you ensure that your team consistently delivers software on time, according to specs, as efficiently as possible? My advice is the following:

1. Pick your software development team very carefully. Stay away from developers who consistently try to gold-plate features. If a developer is known for not respecting project schedules or meeting his/her deadlines, don't sign them up for a time-constrained project.


2. Set major milestones and/or deadlines required to successfully meet your business goals. If a project is time-constrained, then you are responsible for setting and communicating the major milestones. You need to clearly mark the deadlines in your plan and share them with your team. If the project is feature or budget-constrained, then identify the major milestones that need to be achieved and communicate the dates as ranges instead of hard dates. In other words, state that "code freeze needs to occur between March 1st and March 15th" instead of "code freeze needs to occur on March 5th". Refine those ranges as the features get better defined.


3. Once you've set the major milestones, ask the individual developers to help you develop a set of miniature milestones. As DeMarco and Lister note, developers are more productive when they can do the estimate themselves, compared to cases in which the manager does it without consulting them.


4. Communicate and review the schedule with your team as frequently as necessary. The goal is to ensure everyone is aware of the important dates, not to constantly annoy your team. If you've respected the three guidelines cited above, your team will meet the dates as long as they know what they are.