Put Off Blaming Procrastination

Work will always expands to fit the schedule.

Recent posts on the theme of procrastination, or more specifically, finishing work on deadline rather than early, have stepped on my toes. I'd like to speak up on behalf of my fellow "procrastinators."

The theme implies that people have nothing to do besides that One Task. It implies that they sit around playing games and don't have to scramble to meet multiple, simultaneous, arbitrary deadlines and then die inside when people criticize the lack of perfection.

On Time is Late -- Are you sure about that?

Before dealing with "procrastination," one should question the value of beating deadlines rather than meeting them.

The Lean principle of Pull states that early delivery can cause waste. Normally, one thinks of storage costs as waste, but doing work before it's needed presents other costs. For example, racing to complete a task might sacrifice planning, risk management, or quality. It might also cause neglect of lower-priority tasks or accelerated cost of funds.

The real schedule-waster is not procrastination. The great Time Thieves are multitasking and perfectionism.

The assignments will multiply to fill the schedule.

Multitasking eats up time by inserting course changes into the day. Human minds are not like Intel chips with four independent CPUs. It takes time to push task A into the stack, bring up task B, recall where you left off, and start making progress again. Moreover, what manager will forgive neglecting task A, which is due tomorrow, just so task B can be completed a day ahead of its due date one week from now?

The reach for perfection will stretch to the deadline.

Management teaches "procrastination" by forgetting to balance constraints. If you expect perfection in any human endeavor, expect employees to pour every available hour into quality.

Managers who want early deliveries need to increase collaboration with their reports. That means, first, avoiding micromanaging, but still sharing enough involvement to guide energies toward the right balance between progress and quality. It means, second, putting themselves in a position to say, "Stop! That's good enough," when the task reaches sufficient progress and quality.

The prevalence of multitasking and perfectionism make "procrastination" not a performance problem, but a management problem. Sure, when employees fail to adapt, it becomes a performance problem; but I caution against pointing fingers at the effects when the cause lies within Leadership's hands.

Project Selection

For project selection, the Project Management Institute's (PMI's) Project Management Body of Knowledge (PMBOK) Guide assumes you have more than one project from which to choose. By analyzing the options, you can determine which has the greatest value to the company. The formal method for choosing the best option is called a project selection method.

 

Suppose I have to choose between

• fixing my child's favorite meal and leftovers for my wife, or
• fixing my spouse's favorite and cheese mac for my child.

So I ask, "which gives me the better Return on Investment (ROI)?" To answer the question, I consider

• How much time and money it will take
• How much of a mess I will have to clean up
• Does it align with my goals (fun vs. study time)
• Rewards (somebody else WILLINGLY taking out the trash)
• How long it will take to reap the rewards
• Risks (what if I overcook the macaroni? or burn the steak?)

A Project Manager (PM) will place a priority on each criterion and score the probable outcomes. The sum of the weighted scores for each option yields a total score for that option.

I did this with my daughter last year when she needed to buy a car. The result surprised me and was not at all what I expected, but it turned out to be a great choice.

The primary use of project selection is for choosing between projects. However, one can also used it during the project life cycle. The projected ROI of a project can change, for example, due to changing market or regulatory conditions. If the ROI falls, it might be worth canceling the project so the funds and resources can be applied to a more promising project. This is a special case of selecting between competing opportunities.

 

The executives of a company I won't name signed a contract to deliver a product on a certain date. If the company failed to deliver on that date, the company would have to pay liquidated damages; and if the company canceled the project, it would have to pay penalties.

 

Unfortunately, the executives failed to have Engineering review the contract. It turned out that the company could not meet the deadline. The PM tried schedule compression, but as risks turned into issues, it became clear that the project could not meet its deadline.

 

What should they have done? The company should have used the project selection method to choose between

• Completing the project and paying the liquidated damages
• Canceling the project and paying the penalties.

Remember, the considerations aren't always directly related to the project. Things such as the company's reputation, the future value of establishing a market presence, or future business based on this project's design work have value, too. For example, cell phone companies often sell cell phones at a loss because they make their money on the service contracts.

Copyright 2011, Richard Wheeler

Handling a Customer's Wishes

Under what circumstances might change requests to the project's scope be denied? How can i handle a customer's wishes if the scope change is not approved.

Short answer: The Project Manager's (PM's) job is to handle the project's requirements, not to handle the customer's unfunded wishes.

Scope changes always affect schedule, cost, quality, resources, and/or risk. A PM will not approve a change that negatively affects those constraints unless it is necessary in order to meet other, higher-priority constraints. 

Obviously, if adding a bell means going over budget and falling behind schedule, the PM will disapprove it. On the other hand, if the customer will not accept the project because the whistle toots with the wrong tone, then the PM may approve spending more to tune the whistle. 

Remember, these are business decisions. At some point, the penalties for cancelling a project may cost less than the cost of completing it.

The above deals mostly with changes requested internally. If the customer requests a change, the PM will present the customer with the effects (cost, schedule, ...) of the change. The customer then bears responsibility to sponsor or reject the change. 

As always, this is a business decision. Even if the customer will bear the cost, extend the schedule, and forgive any realized risks or impacts on quality, the available whistle-tuners may have been committed to another project (inadequate resources), or the loss of reputation (even though the customer specified the wrong tone) may hurt the business in the long run.

To "handle the customer," get out your requirements traceability matrix and present the effects of the change on the scope. Then present the effects of the change on cost, schedule, etc.

Copyright (C) 2012, Richard Wheeler. Permission granted for use not involving publication.