Search This Blog

01 June 2014

Differences between Risks and Issues, Part 2

Differences between Risks and Issues, Part 2

Threats; and Another Side of Risk

 
Part 1 (click here) of this series defined issue.

Threat versus Risk

If a situation, such as a cause and its effect, is certain, then it is an issue. With risk, we deal with uncertainty. If the probability of something is zero, it has no uncertainty. If the probability is 100%, again, it has no uncertainty. The term Risk only applies when

0% < probability < 100%

In Risk Management, we avoid the term "threat" because in everyday discussion, "threat" could also mean "promise of harm" or "logical sequence resulting in harm."

For example, a bully "threatens" to call you a bad name. If we believe the bully, this type of threat would be an issue, not a risk, because there is no uncertainty. If we don't care what the bully says, there is no effect, so it is neither a risk nor an issue.

Another side of risk

Most explanations of risk concentrate on the probability of the event. What if the event is certain, but you don't know what the effects will be?

Risk has two real parts:
  • Cause - A condition or possible change in conditions
  • Result - The effect that may happen
Risk has a probabilistic part, too:
  • Uncertainty
PMP study materials usually focus on uncertainty about whether the cause will happen. However, we can also have uncertainty about what effect a condition or change in conditions may cause.

Therefore, a condition (or change) may be certain, but you still have risk if you have uncertainty about the results.

As PMs, we are communicators. We listen. Others often use terms and definitions different from ours. So we ask people what they mean and negotiate a common vocabulary. We do this to control the risk of broken communications.

If we find that somebody says "the bully is a threat" and means "the bully poses a risk," then we could enter this in the Risk Log in one of three ways:
  • There is x% chance that the bully will call another worker a bad name, causing that worker to quit.
  • The bully will call another worker a bad name, and there is y% chance that the other worker will quit.
  • There is x% chance that the bully will call another worker a bad name and y% chance that the other worker will quit.
If there is 100% probability that the bully has or will call the coworker a bad name and a 100% probability that the coworker will or has quit, then we have an issue.

And if you go around calling my coworkers bad names, we have an issue.

Further study: Use a search engine to learn more about "aleatory variability" and "epistemic uncertainty." However, please don't ask me about them because, the way other authors explain them, I do not understand at all.

(c) Copyright 2014, Richard Wheeler

25 May 2014

Influencing without Authority

Does anyone have advice or resources for managing up when you have proposal contributors or stakeholders who are Sr. to you? (Especially when they have no idea of proposal best practices but they still have...opinions). -- Etiak Y.

Learning to influence without authority

I love the way Etiak worded that, "but they still have... opinions."

My inability to manage or influence without authority hindered my own career. I didn't even know until a few years ago that it had a name.

Because my title (Senior Systems Engineer) did not match the titles of the supervisors and directors whom I was supposed to monitor as part of my job, I limited my attempts to influence them, even when they needed somebody to hold them accountable.

Because I did not see myself as having authority and did not know how to "influence without authority," those in authority did not see any reason to promote me. Remaining at the same level for decades will stunt and eventually kill your career.

Challenging authority challenges experience

Be sure you have a good case before challenging the stakeholders. What is the authority of your "best practices?" Have you considered the impact of the changes you want to make? What will stakeholders have to change in their current practices and relationships in order to make the changes you want? Will it really make a difference? Are you sure the customer is ready for the new practices?

Communicating the challenge

You might consider laying out, side-by-side, the old and new ways. Be ready to explain, "if we do it this (old) way, then (problem). The Standard recommends doing it that (new) way, which prevents (problem) and (other benefit)." Appealing to logic does not always work because "old ways" take root in the subconscious. You want them to visualize (fear) the problems of the old way and visualize the benefits (reward) of the new way. Communicating through story can help.

If you get buy-in from the stakeholders who are in your chain of command, then you move from a position of influencing without authority to influencing through the halo effect. That is, you borrow the respect given to those who wrote the standard; and as a representative of those who do have authority, you can get the other stakeholders to at least listen.

Manage issues with change

If you have to ask stakeholders to re-write their sections because you failed to communicate your needs, it will reflect poorly on you. Announce that the format will comply with (standards) at the very beginning. Help them do their parts correctly the first time by describing the purpose and methods at the very beginning. Give them templates or easy-to-follow guidelines.

Be sympathetic when people whine and moan, but remind them of how the new way provides a way to escape the problems of the old way, remind them of the rewards of the new way, and thank them for their flexibility.

More on influence

You can find materials on influencing without authority in various places. I just finished reading The Science of Influence, by Kevin Hogan (Wiley, 2005). Understanding more about influencing others will give you the side benefit of having more power to influence your own behaviors.

(c) 2014, Richard Wheeler

19 May 2014

Recruiting 101 says not to put salary ranges on job posts.  -- LinkedIn discussion

When only one party in a negotiation has intelligence on the other party, the other party will lose. This is counterproductive. When the losing employee realizes what has happened, he will lose motivation and become less productive, jump ship, or (in extreme cases) undermine the employer.

I'd like to clarify another concept: Suppose a company hires somebody who earns $10/hour and pays him $14/hour. The company should not view that as "giving" the worker a 40% "raise." It may be a 40% increase of income to the worker, but from the company's perspective, it's dividing by zero. Literally.
 
Raise % = (New - N/A) / N/A x 100%
 
You can only give a raise to somebody you already employ. Substituting a new hire's history for N/A is dishonest.
 
Moreover, the situation is like sunk costs. Sunk costs only have emotional value in decisions. Good managers base objective decisions on the value and cost going forward.

Take an extreme example: Suppose I fill time between jobs making $8/hour as a WalMart greeter while finishing my PhD. If I apply for a position that pays $88/hour at your company, are you really going to negotiate my new salary down to $10/hour with the argument that $88/hour would "give" me a "raise" that's too big? Or if you hire me for $88/hour, are you going to boast that you "gave" me a "raise" of 1,000%?

Employers and recruiters may think they have all the power. So do the sphincters in the alimentary canal; but what happens to the system when they abuse their power? Job applicants have power, too. Unethical applicants can become dissatisfied losers in the negotiations and undermine the company; the best applicants can walk away and find competitors that will reward them for moving their companies forward.

If companies and recruiters demand transparency from applicants, then "integrity" means they have to practice transparency, too.

18 May 2014

Window Panes versus Tiles

A lot of web and application designers follow the Windows 8 paradigm that uses flat, borderless tiles.

However,

Change for the sake of change

I don't believe in change for the sake of change. "Change is good" only when the changes are good. When you want to go north and your bearing is 20 degrees, change is good when somebody says, "Let's turn left 10 degrees." But when somebody says, "Let's turn left 180 degrees," change is foolish. Good change is good. Change for the sake of following a fad out of Redmond is dumb.

Stepping backwards - Why not go all the way back to MS-DOS?

Flat, borderless tiles are boring; but that is subjective. Objectively, borders, especially three-dimensionally shaded borders, provide strong geometric shapes. By guiding the eye, they provide actual functionality.

Forward into ambiguity

The paradigm of imitating our three-dimensional world made GUIs more intuitive. The new trend makes graphics ambiguous: Is it a non-functioning picture or a functioning button -- make that, membrane switch? You shouldn't have to waste time experimenting to find out what's functional and what isn't.

Will it be up or down?

For notepads, tiles make some sense. Compared to PCs and laptops, notepads and smart phones have small screens and low processing power. The simplicity of tiles has its advantages.

Some day, notepads may outnumber PCs to such a degree that PC users will want the consistent look and feel.

On the other hand, notepads will gain in image resolution and processing power. Maybe the designers will return to the higher standard, and this ugly fad from Redmond will go away.

04 May 2014

Trusting the Project Team

Vikas Gupta asks on Google Plus, pretty well answering his own question:
How much can/should a Project Manager interfere in the technical details of a project? For e.g. If a developer thinks that xyz is the most efficient way of implementing a functionality, is it unproductive for the Project team to have PM challenge that beyond a limit? I personally think that challenging the team members is ok, but a PM must trust the technical skills of team members and too much interference may demotivate the team.. Thanks in advance for your expert opinion!
 Discussion Link April 30, 2014

Project-Aria replied,
It is rare that a PM is just a PM.
Usually the PM also adds value by bringing technical expertise. Now the question here is: does the PM have the expertise in technical area in question. If yes, then yes. If no, then interference may be a dangerous path.
I would also note that communicate is a 2-way challenge. It is also important to all team members, including experts, to be able to explain their ideas and convince others. It is important for the expert to be able to communication without hiding behind a expert-cryptic language.
Apr 30, 2014

I think Vikas stated it well and correctly. Early in each design phase, the PM can ask the team to consider his personal favorite solution. The design team should then compare the various options for each architectural element and weigh them against each other. The result is a trade study that weighs the trade-offs and makes an objective recommendation of the best solution.

Unless the decision is very close, the PM should leave the decision to the results of the trade study. If he does not, it can reflect badly on him.
  • It indicates that he did a poor job of selecting his team.
  • It insults the design team and, as Vikas said, demotivates them.
  • It may indicate that he failed to have the design team include his favorite option in the trade study.
  • It may indicate that he failed to properly define the design parameters.
  • It indicates subjectivity, a failure to rely on objective evidence produced by the trade study.
  • It turns the time and cost of trade studies into waste.
  • Failure to trust often results from projection; that is, expecting others to do what you would do. Therefore, it raises issues about the PM's ethics.
  • Overriding the results of a trade study can create an appearance of impropriety (for example, the PM appears to take a bribe from the selected vendor or subcontractor).
As Project-Aria stated, the PM may bring enough technical expertise to deserve the right to override the design team; but he had better have convincing technical reasons for his actions and had better own up to his mistakes that made his action necessary.

If your experience has shown you more reasons why a PM should or should not override the decisions of his design team, I'd like to hear from you in the comments.

30 March 2014

Training the Software Requirements Engineer

What are different type of training required for a Software Requirement Engineer?

The correct answer is, it depends. Software requirements training should fit with the type of project management used by your organization.

One type of training you don't need

Many people think a software requirements engineer should thoroughly understand programming and software engineering. Obviously, you should know something about the software engineering discipline, but knowing too much can destroy your ability to write good requirements. This happens for two reasons.

First, good requirements should ignore the technology (such as which platform or language is used). This is because requirements should not dictate the solution; they should only define the problem to be solved. Devoting too much study to the technology will bias a requirements analyst toward particular solutions. This makes consideration of alternate solutions more difficult for the design engineers.

Second, requirements elicitation is an art as much as a discipline. Managing stakeholders, conducting meetings, choosing elicitation methods, and choosing methods for representing information require strong skills in psychology and communication. Putting all your energy into learning programming languages and tricks will cost you on the human side. It would be as great a mistake as putting all your energy into market research. You need to know enough about programming to win the respect of the designers and to communicate with them, but your job is to build a bridge between the customer and the designer.

What should I wear? Well... where are you going?

Organizations that work with large systems that integrate multiple technologies tend to follow traditional Project Management and Systems Engineering methods. They use some variation of the Waterfall model, such as the V model.

For a high-level understanding of Systems Engineering requirements methods, I recommend starting with INCOSE's (International Council on Systems Engineering) Systems Engineering Body of Knowledge (SEBOK) and using the SEBOK as a guide to subjects for study. Also consider studying Model-Based Systems Engineering, one subset of traditional methods, and SysML, the modeling language used for MBSE.

Organizations that work primarily with software tend to follow Agile project management methods. In Agile environments, requirements engineers tend to go by the title Business Analyst. I recommend starting with the IIBA's (International Institute for Business Analysis) Business Analysis Body of Knowledge (BABOK) and using the BABOK as a guide to subjects for study.

Agile is a set of principles and not an actual method. I have asked for a recommendation for a book that describes the different methods (such as Scrum and Kanban) but have been told no such book exists; for each Agile method, you need to find a different book.

The requirements methods differ considerably between traditional and Agile. Traditional methods nail down requirements and then negotiate schedule and cost. Agile nails down schedule and cost and then negotiates, prioritizes, re-prioritizes, and drops requirements.

The two methods do share some of the same tools. I suggest studying Unified Modeling Language (UML). UML is not a language, but a set of graphical methods for defining requirements. The most commonly recommended book on software requirements is Software Requirements, 3rd edition, by Karl E Wiegers and Joy Beatty.

23 March 2014

Classes for Technical Writers / Communicators

Any suggestions for what further education pairs well with technical communication?
-- Nicholas
Ask the Right Question

Nicholas has asked the right question -- sort of. I don't think anybody can answer the question for him.
 
A technical communicator translates the Subject Matter Experts' (SME's) geek-speak into plain human-speak. Learning the SME's language will play a pivotal role in success. Even introductory courses in the chosen domain will dramatically shorten the learning curve once he lands a job.
 
The question omits any decision about the domain in which Nicholas will practice. When he chooses a direction, he will be better able to determine the answer for himself.
 
If Nicholas has not chosen a domain, yet, I would suggest that he visit his school's career office and the state employment office and ask, "What industries show growth potential for Technical Writers?" Once he has a list of, say, the top ten fields, he can consider which field(s) would most personally reward him.

After that, he can ask, "What subjects would best help me learn the language of the SME's in that field?"
 
Supporting Skills
An employee does not just sit down and start doing the job. Each job has supporting knowledge areas such as planning work, reporting activities, conducting meetings, and defining and adhering to ethics. A successful employee also looks ahead in the direction that the career and the profession will take. That adds soft skills, management, and industry trends to the list.
 
I will name two of the most important skills Nicholas could add to his quiver.
 
First, the most important SME in anybody's career is the boss. Learning about project management (I suggest PMP Exam Prep by Rita Mulcahey) will help Nicholas:
  • Understand how he can support his manager's success
  • Learn more about organizing his own work
  • Start his climb up the career ladder
The knowledge areas defined by project management standards can also serve as springboards into further studies.
 
Second, the ability to visually model processes and information would help Nicholas in any industry. To that end, he should familiarize himself with the Unified Modeling Language (UML). An Internet search will turn up plenty of tutorials.)
 
UML is not a language (not in my vocabulary, anyway), but rather a set of graphical styles and standards for defining and illustrating relationships between entities and for defining the processes in which entities interact. If Nicholas works in the software field or supports business processes, he will probably need to understand UML, anyway.
 
Basic Life Skills for Success in Any Technical Career
 
People normally associate project management with management and producing products, and they associate UML with software engineering, systems engineering, and business analysis. However, the set of tools these two topics would give Nicholas, and the ways of thinking that they teach, would be invaluable in almost any domain. He can study those areas while thinking about the industry he wants to work in.
 
"Professionals" distinguish themselves by continuously and independently learning. Schools lead students through semi-standardized curricula, but professionals write their own curricula. Nicholas should plan his future studies but bear in mind that:
  • he will continuously update that plan, and
  • he does not have to do all his studying now.

The Dramatic Death of Windows XP (yawn)

Update for Commercial Users (29 May 2014)

If your computer stores consumer data such as credit card or health information, certain regulations require you to upgrade your system. Charles Ripley of IDG Creative Lab states that regulators and credit card companies require many businesses to upgrade their systems immediately or else risk fines or discontinuation of service. For more details, read Protect Your Bottom Line by Making Sure Your Business is Compliant.

(Updated: 8 April 2014)

Death! Destruction! Hackers! Viruses! Despair!

For the last decade, it seems, we've heard about the impending crisis due to Microsoft discontinuing support for its 12-year old Windows XP operating system, Office XP, and Office 2003. This snippet comes from NASA's CIO:
Using Windows XP past April 8, 2014 may leave users significantly more vulnerable to viruses and malicious code. There is a high likelihood of a significant increase in attacks targeting XP users by malicious actors once support is officially discontinued.
That's pretty calm, compared to some sources.

Windows XP End of Support: A Hacker's Paradiseheartlandtechnologies.com
 
Hackers Will Feast On Windows XP Starting April 2014
invisionkc.com/

Windows XP Could Be Infected Within 10 Minutes of Support Ending
tomshardware.com
End of Windows XP support will be 'starting pistol for hackers'
telegraph.co.uk

Take a valium, breath into a paper bag, and count to ten.

Obviously, the hype will drive many to replace their XP operating systems with Windows 7 or 8. This will bring a boom in sales to Microsoft. It will also benefit computer manufacturers when people find out that Windows 7 or 8 won't run on their old computers.

In fact, it will probably benefit Apple as people who really wanted a Mac finally go through with that purchase they've been putting off.

XP still accounts for almost a third of personal computers, worldwide. The loss of support from Microsoft will eventually make XP computers a soft target for hackers. However, as the world rushes give Microsoft more of their money, XP will become less common and, therefore, a less interesting target for hackers.

XP will not suddenly become vulnerable to all viruses on April 8. Microsoft updates operating systems after weaknesses are discovered. That process of identifying and responding to new threats takes weeks to months. Since Microsoft releases its updates once per month, XP won't miss its first security update until May.

When XP misses its first security update in May, the hackers will pick apart the updates for Windows 7 and 8. Since some of the vulnerabilities in 7 and 8 date back to XP, the May update will give hackers clues about weaknesses in XP. Deciphering all that will take time. Inserting code to exploit the weaknesses into new viruses will take more time. Then they have to start distributing the viruses, and it takes more time for viruses to spread.

Microsoft stops, but not everybody stops.

Microsoft stopping its XP updates does not mean that antivirus software will stop working! Antivirus makers such as AVG and Norton will continue updating their software.

Keep Calm and Compute On

I have an old XP desktop that I use for recording audio. I generally do not use it for accessing the Internet.

On April 8, I'll make sure I have the latest updates from Microsoft. Then I'll back up the softpacks in case I need to restore the drive.

I'll order the barkeep to pour me another sarsaparilla, and pay attention to tech news. When I begin to fear that XP has become too vulnerable, all I have to do is turn off its access to the Internet. I right click on the Wireless icon and click on Disable.

(But first, I'll probably update the virus scanner one last time.)

Then, to free up disc space, I uninstall my browsers and email program. No big deal!

But, but, but... the ATMs!

On the dangerous side: I have read that all ATMs use a version of XP. I have not seen any articles describing what ATM owners intend to do about it.

However, I suspect that ATMs use Virtual Private Networks (VPNs) to communicate with bank servers. A VPN is an encrypted link, like a tunnel through the internet between two computers. A VPN would block most other Internet communications.

When was the last time you saw somebody using an ATM to browse the Web, download music, or check email? Those are the most common sources of malware. ATMs don't get exposed to viruses and hackers like our home or work computers do.

I'm sure many hackers will take up the challenge as new weaknesses in XP become known, but again, such things take time, and ATMs have a lot of security already in place.

Recurring Theme

Do you see what I'm getting at? Instead of an asteroid slamming into Earth at 20,000 miles per hour, it will be more like The Blob, creeping slowly as people run around in panic.

We have time to take steps and to figure this out.

Steps to Protect Your XP Computer

  • It is 9 PM, California time. Microsoft is still allowing me to download and install the latest security updates. If you haven't done so, open Internet Explorer, click on Tools, Windows Update. Then guide your computer through the update. I suggest using the Custom update because some of the optional updates will add to your computer's security.
  • I went to update our house guest's laptop and found that, apparently, it had been years since she had run the update. Almost 160 updates are being downloaded now. (Estimated time, almost 6 hours!)
  • Make sure your Windows Firewall is turned on.
  • Make sure your antivirus software has the latest updates and virus definition files. If you use the Internet much, make sure the antivirus software scans your computer at least weekly. If you do something that raises your suspicions, run the scan manually.
  • If you don't have an antivirus program, get one. PC Magazine's The Best Free Antivirus for 2014 names AVG and Avira Free Antivirus (2014) as the best for keeping viruses out of your system. (Look under Real-Time Protection in the article. If you have viruses already, look under the Cleaning Up the Mess.)
  • There's good news about antivirus programs: Most of the antivirus programs that support XP will be supported for another year -- even Microsoft Security Essentials. Make a mental note, though: In April 2015, you may have to replace your antivirus program with another one.
  • If you log on as the only user, you are probably the Administrator. That means that, when you run a program, it can make changes to Windows. If you are not the Administrator, you may still have admin privileges. To prevent infected Web sites from making changes to your computer, you need to log on as a regular user without Admin privileges.
  • If you are the Admin or sole user of the computer, go into the user accounts settings and create a new user (you). Make sure the new user account does not have Admin privileges.
  • If you have a secondary account but also have Admin privileges, have the Admin log in and disable your Admin privileges.
  • Although Internet Explorer is up to version 11, the latest version that supports XP is version 8. Microsoft will stop supporting IE 8. I recommend Chrome and Firefox. Install them and don't use IE unless you find a good reason to.
  • As I said above, when I begin to fear that XP has become too vulnerable, all I have to do is turn off its access to the Internet. I right click on the Wireless icon and click on Disable.

 

(C) 2014, Richard Wheeler

Use Google to Search for Jobs on Craigslist

You can use Google to look for jobs on Craigslist by keyword.

Go to Google.com and type

site:[the URL of the Craigslist site for the city where you want to work] [keywords]

For example,
site:goldcountry.craigslist.org/ barista coffee espresso

If you don't care where the job is, just use "craigslist.org" instead of "goldcountry.craigslist.org".

One of the advantages of this is that an employer might post a job under any of several categories. This way, you don't have to move from page to page in your search.

As another advantage, you don't have to read through all the postings that don't relate to your search.

You can get Google to send you an email alert with your search results.

Just go to www.google.com/alerts and enter your search as shown above. Then adjust the settings and click on Create Alert.

You can change the alerts and their settings by clicking on "Manage your alerts."

You can create more than one alert.

Here are some ideas:
  • Create an alert for each city or region where you would take a job. Just browse around the Craigslist site to get the URLs.
  • Instead of having Google search just Craigslist, have it search the whole internet for your name (and variations on it). This way, you can monitor your reputation.
  • If you want to keep up with the news about a particular company, you can set up an alert for it, too.

19 February 2014

Change Request Analysis or Filing the Change Request -- Which First?

As sample question for PMI's PMP exam asked, in part, whether an analysis should be performed before "raising the change request." I believe that the PMI-approved answer is that, when somebody such as the customer requests a change, the first step is always to analyze the impact.

Defining the Change Request

The answer to this question depends on how one defines submitting, filing, or "raising" a Change Request (CR). If it means submitting the request to the Change Control Board (CCB), expecting its approval, then one definitely should perform the analysis first.

However, I define filing a CR as placing it under control of the CCB. That does not mean that the entire board oversees the CR before it has been analyzed. It means that the CR is entered into a Change Request Log so it can be tracked and analyzed with adequate oversight.

Preventing Duplicated Analyses

Performing the analysis before filing the CR implies that, if the request is not practical, the Change Request may never be filed. That can cause problems.

Suppose the customer suggests a change to the Chief Engineer, and the CE does an analysis of the change. Then the customer suggests the change to the Project Manager, and he does a separate analysis. Later, one of the engineers thinks of the same change and does yet another analysis. Do you see the waste?

To avoid such waste, an organization should have a coordinator act as gatekeeper for the Change Control Board. Each Change Request (CR) should be filed with the facilitator before an analysis is performed. The coordinator can cross-reference the change against previous CRs to identify similar or duplicate analyses that have already been performed. This prevents duplicated effort. The coordinator can also suggest other resources, such as studies or subject matter experts. Or, the coordinator might create efficiency by combining the analysis with another activity.

Tracking Progress

Now, imagine that the customer asks the PM to make a change, and the PM performs an analysis, but it falls off the PM's desk into the trash can and is forgotten. Later, the customer sues the company because it did not make the requested change.

Instead, imagine that the PM filed the CR with the CCB coordinator FIRST, before analyzing the impact. The coordinator would create an entry in the Change Request Log and assign a due date for the analysis. When the due date comes, the coordinator asks the PM, "where's your analysis?"

Objective Evidence

Later, if the customer asks, "Why wasn't that change made?" the PM can ask the coordinator to look it up in the CR log. The PM finds the file number of the analysis and sends a copy of it to the customer.

Controlling the Cowboys

One last scenario: Suppose the hydraulics engineering manager falls in love with a certain change. He takes a week to perform the analysis and then files the CR with the CCB. However, the CCB has a wider perspective and wants the analysis performed by the Mechanical Engineering director in coordination with Purchasing and Manufacturing. The second analysis takes another week. If the hydraulics manager had submitted the CR to the CCB first, they could have saved a week and gotten the change approved earlier, when it was less expensive to make.

Conclusion

The PMI answer may assume that you should not bother the CCB until you have analyzed the change. However, allowing the CCB to coordinate CR analyses can reduce analysis costs, save time, create accountability for completion of CR analyses, increase the quality of the analyses, and ensure that the analyses become part of the project records.

18 January 2014

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.