Name Your Files for the Readers — If You Care

Filenames — A Trivial Time-waster that Adds Up

How do you react when you see a filename like 500002p.pdf? 

Is this a file that you want to open? 

Do you think that the author of the file cares whether you open it? 

This one's a little better, but not much:  BBP3.0FactSheetFINAL.pdf.

What Do You Want to Know?

When I look at a filename, the first thing I want to know is what it is. After that, I want version information. 

Some people put their initials first.  In a team folder, the listing will group the Jim files, then the Joe files, then the John files, and so on.  (And then there's Jack who sometimes uses JB and sometimes JEB.)

Then you have to search up and down the screen to find all the versions of the same file.  The larger the team and the longer the project goes on, the more this wastes time and leads to mistakenly working with outdated versions.

A government website has a folder of presentation files in this format:  

2014_05_15-Draper-6th-AGNC-Welby-final.pdf

Placing the date first is redundant because you could always sort by date in the file explorer view.  Apparently, the Welby made the presentation and worked for Draper, and the topic was some cryptic initialism.  Now, how are we supposed to find presentations on risk management among 74 files with names like that?  Do you have an hour to spend opening all those files?  

There's another human element. When a filename starts with initials or has a serial number instead of a name, my eye says, "random, meaningless letters." Then my amygdala says, "look away!" 

Sometimes my amygdala wins, and sometimes my cerebral cortex wins. That contest creates stress. wastes time, and sometimes blocks communication completely. 

If you have a Content Management System (CMS) or Configuration Management System (also CMS) such as SharePoint, you have ways around this.  You can add fields for author, date, version, and subject.  

Often, however, we are stuck with filenames.  Even if your team has a CMS, you will still sometimes wish to download a file to your own drive.  If you don't remember what's in that cryptically named file three months from now, will you even bother to open it?

Since I read from left to right, and since an alphabetical sort proceeds from left to right, I recommend the following name format:

topic - [rev or yyyy-mm-dd [24-hour time if needed] ] - initials

example

meeting notes, team, 2015-08-01, rev A, rw.docx

Filenames should be in plain English. 

When I download files, I hate seeing files with names like BB097834.pdf.  I should not have to download and open a file in order to determine whether I want to download and open it. 

And by the way, who is JS, and does he or she even work here any more?  Does it feel professionalI to use your initials?  How professional will it seem to others, two years after you've taken that big promotion at another company and nobody here remembers whom JS was? Spell things out.

Some content management systems assign garbage names automatically.  We cannot do anything about that.  And some authors write only for their own vanity.  They do not care whether anybody reads what they wrote.  Try not to obsess over it; I've already done that for you.

A filename is like a headline or the title of an opus.  

A good author or editor knows that Job One is attracting an audience and, therefore, puts a lot of effort into creating a meaningful, eye-catching filename. Which would the classical music lover in your life rather listen to?

• PITop066.mp3

or

• Sleeping Beauty, Peter Ilyich Tchaikovsky, opus 66.mp3

It's about more than efficiency. It's about consideration.

Copyright 2015 Richard Wheeler

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

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

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.

Communicating the Organization's Direction: The Missing Ingredient

The average worker could not tell you the vision of the employer.

To some degree, the average worker can perform just fine without knowing the mission and goals of the business. However, knowing the purpose of the work can guide decisions made in the course of the work. Perhaps more importantly, having a known, defined purpose can motivate the worker by providing a roadmap to the work's contribution. It provides a personal connection to the work and to the company. This, in turn, improves performance and retention.

Leadership can improve overall performance by communicating the vision, mission, and goals of the business, as well as the specific objectives of each project. (To cut down on wordiness, I'm going to combine all of those messages and call them the "direction" of the business.)

This topic could take up a whole book, but I will address a portion that I think leaders tend to forget. The specific methods and tools used will vary during the lifecycle of a project. For that reason, I would recommend organizing a more complete description of the topic around process groups or project phases:

• Project selection
• Project initiation
• Project planning
• Project execution
• Project monitoring and control
• Project closure

Defining the direction is part of creating the business plan. Any responsible business owner will create most of those materials and update them regularly. From there, communicating the direction requires breaking each section into a PowerPoint presentation, asking lower-level leadership to give it visibility, putting it to work in the organization, and setting up systems of accountability.

Businesses commonly forget to ensure that the elements of the business direction flow down to projects. Leaders present and promote the direction, but they also need to communicate it through actions that create the processes and provide the tools for carrying out the direction and controlling its implementation.

Just as the business needs to continuously review and refine the direction, the projects need to ensure alignment with the business direction. For example, many project managers set the contract as the highest level of requirements. However, many decisions made within a project depend on the business direction.

Leadership can take one step to communicate business direction by empowering Project Scope Management. They can do this by making available a good Requirements Management System (a tool such as DOORS or CORE). The project managers should then include the business direction's documentation as the top level of each project's requirements. During the project lifecycle, the project can ensure that decisions support the business direction and all requirements trace to the business direction.

Many leaders focus on communicating business direction through presentation. However, they must also communicate it through action. Obviously, actions include specific soft-skill behaviors such as demonstrating the importance of meetings by prompt attendance. But they must invest in resources that empower their teams to use direction as a tool and to use it as the measuring stick of performance.

Make Lessons Learned a Part of Your Culture

An organization with process maturity will close the loop on Lessons Learned.

By closing the loop, I mean that the organization will ensure the capture, distribution, and institutionalization of the lessons taught by the school of hard knocks.

While the Project Manager should identify and collect Lessons Learned, Quality Assurance should categorize and preserve them.  QA should take further steps to communicate the lessons.

First, leaving it to everybody to go searching the LL database does not work.  Like that will ever happen! Ha!

Instead, QA should sort the LLs by function and subject and distribute the information to affected functional managers across the organization.  This ensures that, for example, the Integration Engineers in different programs and at different locations receive the expensively acquired knowledge.  If the functional managers fail to communicate the lessons to their people, upper management should give QA the authority to do so.

Second, QA should incorporate applicable improvements to the Organizational Process Assets.  This way, QA does not merely deposit critical knowledge into the Tribal Knowledge Bank, but actually institutionalizes it.  This introduces accountability when QA audits process compliance.  It also allows the lesson to be moved to a section of the database that lists rationales for historical purposes.  Not every Lesson Learned needs to be researched for normal operations.

Note that this involves Change Control at both the project level and at the organizational level.

As an example, engineers delivered documents to a customer without the necessary review and approval of the Chief Engineer.  The incident led to rework and incorrect customer expectations.

Tribal knowledge had established a channel that would have ensured proper review before release.  However, new employees did not know it, and management had nothing in writing that allowed them to discipline experienced employees who knew better.

Engineering stepped in where corporate management had left a gap.  They instituted processes for document review and approval and for an engineering communications manager to coordinate release of documents to clients.

Thus, an incident led to a Lesson Learned.  The Lesson Learned led to policy and procedural changes.  The new practice became part of the formal procedures and did not get lost in a database that ever researched.

Copyright 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

Project Management and Open Communications

Project Managers need to guard against setting up an environment where bad news never reaches them. They need to praise and encourage those who communicate risks before they become issues, issues before they become problems, and problems before they become project failures.

Some managers remind me of the Clinton trial in the Senate, following his impeachment in the House.

The Senate set up a rule requiring Ken Starr to keep all the records and evidence in another building. Bringing it to their offices without an invitation would have violated protocol.

Then the majority of senators refused to go view the evidence. A few who did view it said they came away weeping, and the rest (having refused to view the evidence) said that they lacked evidence sufficient to convict.

Does your comfort zone tempt you to maintain willful ignorance? Does your character allow reliance on plausible deniability? The PM has accountability for project success, which any lack of awareness may bring about; but that accountability extends to achieving success ethically.

 

I wonder:  Do PMs ever include ethical lapses as project risks?

The Best Project Management Software

Project management covers many knowledge areas. Developers approach PM software functionality from the perspective of a particular discipline or PM knowledge area. The approaches usually focus on a narrow selection of the following needs:

• Requirements
• Software Development Life Cycle (SDLC)
• Agile methods
• Model Based Systems Engineering (MBSE)
• General verification/validation
• Software test management
• Software test management with scripting
• Issue and change management
• Product definition from a market research angle
• Scheduling
• Cost management
• Resource management
• Project communications
• Scope and requirements definition
• Quality management
• Configuration management

As a result, all the solutions I have looked at work for only a small portion of project management. For example, MS Project would be useless for requirements management, and DOORS would be useless for project scheduling.

 

Some developers stress integration of their products with other products -- preferably their own. For example, Rational (specializing in SDLC) bought DOORS and worked on integrating the two product lines. Then IBM bought Rational and expanded the integration effort to include other IBM products.

 

Implementing many PM software products and then tailoring them to the organization's needs can require permanent, trained resources. Integrating several products can take years, even in large organizations.

 

With the current state, I believe any attempt at a total PM solution will require a very large initial effort, significant support to maintain the solution, and an acceptance that some interfaces between PM processes just have to be done by hand.

 

Therefore, to answer the question, "What is the best software/tool for end-to-end Project Management?" you need to prioritize the areas of PM because no product addresses the end-to-end needs -- or at least, the top-to-bottom needs.

Buyers versus Users

The new project manager (PM) or systems engineer (SEs) knows that the Seller, the person or organization providing deliverable products or services, must fulfill the scope defined by the Buyer. The Seller and Buyer usually negotiate a Project Scope Description which the project Sponsor includes in the Project Charter. Details of the project scope description may be found in the contract, Statement of Work, and any subsequent approved Change Requests.

 

The PM also knows that the Project Requirements must detail the project scope through requirements analysis and through creation of a Work Breakdown Structure (WBS) that has enough granularity to define project tasks at a manageable level.

 

New PMs or SEs may overlook the importance of a third party: Users.

 

Users are people or organization who put their hands on the product or receive the service. The Buyer may or may not be the User. For example, as part of a project to set up a business office, a manager (the Buyer) may want to buy spreadsheet software for his analysts (Users).

 

In one contract, my company upgraded communications equipment for an agency (the Buyer) that needed new types of signal channels. The Buyer owned the equipment, but another contractor provided the operators, and yet other agencies utilized the communication channels.

 

Even though we took our direction from our contract with the Buyer, we coordinated with the third-party Users to validate the Buyer's requirements. Unhappy Users would have been reflected by an unsatisfied Buyer, which would have cost us future business.

 

The PM must gain acceptance from the Buyer by satisfying the requirements. However, in many projects, the PM must also define the requirements in enough detail to ensure that they reflect the Buyer's needs. This implies added responsibilities:

• The differences between needs and requirements must be identified as early as possible in order to prevent expensive changes later.
• If meeting the needs increases the scope, schedule, or cost, the PM must inform the Buyer and negotiate changes as soon as possible.
• The PM needs the courage to help the Buyer understand what he needs and what he will not receive.
• Enough time should be spent during the planning phase of a project to ensure that meeting the scope, requirements, and needs will result in a happy Buyer.

Returning to the example in the first paragraph: The manager may think he can get by with Lotus 1-2-3 (ca. 2000), but the analysts are familiar with Excel 2007 and need the new functions that come with Excel 2013. The PM needs to advise the Buyer to take a class in computer literacy.

Copyright (C) 2013, Richard Wheeler. Permission granted for use not involving publication.
Expand this commen

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.

Gaming HR's Job Site Limits

Multi-talented people who qualify for multiple positions within large companies have a new reason to bypass HR and use networking to reach hiring managers. Large companies with online application systems create this situation by limiting the number of cover letter and resume versions applicants can use. This severely limits the number of positions to which one can apply.

For example, I applied for an Industrial Engineer (IE) position with a major Defense contractor. Their system stores only one version of an applicant's resume. When I applied for a Systems Engineer position, the system could only use the resume and cover letter I had crafted for the IE position.

• Sidebar: That's Systems Engineer, as in multi-disciplined, end-to-end technical managers of projects. IT Systems Engineers and specialists in other disciplines are generally not Systems Engineers, even though many companies give them the title.
  

This practice allegedly limits the ability of resume-spammers to apply for jobs for which they do not qualify. Counter-productively, it also limits companies' access to high value, multi-talented people. An applicant could apply for multiple jobs under the old mail-in paper filing system, but poorly implemented technology places a governor on the flow of applications.

When HR looks at my application for the Systems Engineering job in two weeks, they'll see the cover letter and resume for the IE job and say I'm unqualified. In fact, they'll ask, "Why's this IE applying for a Systems Engineering position?"

Had I replaced the IE version with my Systems Engineering version, the same thing will happen. In fact, when the IE hiring manager goes to retrieve the IE versions of my cover letter and resume, they will no longer exist in the database.

Even worse, if I applied for all the positions I have the skills for, HR might consider me a job-spammer and ban me from the whole system.

Using a generic version does not solve the problem. For many reasons, generic resumes do not compete with tailored, targeted versions.

The systems severely limit how often you can apply for jobs, even if you're fully qualified for each one.

I may have found a way around this limitation for some job sites. Some offer a way to upload supporting documents such as certificates, transcripts, copies of licenses, etc. One can upload a file containing a tailored cover letter and resume. My hypothesis: If the primary resume in the database gets past HR's screeners, the hiring manager will see your "supporting documentation."

Game HR's web application system if you must. Better yet, bypass HR through networking.

Systems Engineers, IT, and Sanitation Engineers

I feel a strong kinship to the civil engineer who specializes in garbage removal and landfills when PC bureaucrats call garbage collectors Sanitation Engineers.

The IT industry labels just about anybody a Systems Engineer. They demean the title by giving it to people who have skills in computer networks, software coding, or server administration, but may have little or no education in engineering, no multidisciplinary background, and no high-level perspective of systems development. I respect the IT folks knowledge and the hard work they put in to acquire their expertise, but that doesn't make them engineers, let alone systems engineers.

Systems Engineers work both at detail and at higher design levels. They consider business needs, requirements analysis, risk management, cost estimation, project planning, use cases, life cycle analysis, design, integration, and verification and testing. Their broader perspective requires formal, multidisciplined education and extensive experience so they can communicate with and bring together business, management, and engineers from different disciplines to communicate with the customer and deliver a complete and coherent design or service.

Two guilty parties who lead the title inflation include Microsoft, with its Microsoft Certified Systems Engineer certification, and Cisco Systems, with its Cisco Certified Network Engineer certification. MCSEs and CCNEs know their subjects, but passing a test qualifies them as technicians or technologists, not as engineers who devoted four or more years to passing hundreds of tests in dozens of subjects.

Some say the usurpation of the SE title is a non-issue. As a job-hunter, I disagree strongly.

The mis-labeling has wasted hundreds of hours of my life over the past 20 months. I have to access and scan dozens of job descriptions for each systems engineering position I find.

Example:  Sherlock Tech knowingly inflates a Systems Administrator into a Systems Engineer. You're full of you-know-what, Sherlock.

When you multiply that by having to read dozens of systems engineering job descriptions to find one position for which I qualify, you find a very large, tedious, and discouraging task.

Many disciplines such as hydraulics, controls, mechanical, optical, power, and manufacturing engineering -- not just IT -- usurp the term. In their case, the mis-labeling constitutes a lateral misplacement. The problem seems not merely due to inflation, but also due to laziness. This compounds the challenge of job searching for SEs, but also for job hunters in those other disciplines.

The Department of Labor and state employment departments have contributed by cataloging some technical occupations by discipline and others by industry. For example, aerospace and IT are not disciplines; they are industries. Computer systems, networks, software, and (cross-functional) are disciplines.

When I was in school, we already had a term and major for students of IT. It was Computer Systems Engineering. (Some schools lagged in separating out the computer majors from Electronic Engineering, or Electronic Engineering from Electrical Engineering, too.) Software Engineering had just starting to break out as a separate discipline.

A little specificity would go a long way in the job market.

Expectations versus Requirements

Discussions about expectations and requirements tend to focus too narrowly on the relationship with the customer. Expectations come from a much broader group, however.

On a tangent: We do not manage customers. We manage their expectations. Managing customers is just a little too proactive.

Stakeholders include not only the customer, but also management, regulators, subcontractors, and the various departments within the performing organization. Figuratively and to varying degrees, everybody involved is a customer. Expectations, therefore, fall into categories that vary from documented requirements and undocumented management decisions down to bad ideas.

For example, management expects the project to stay within 5% of a given budget. Although management's expectation is not a requirement, it bears just as much force.

Other stakeholder expectations might become product or project requirements during requirements decomposition. For example, -ilities Engineering may identify environmental or safety expectations that the systems engineer will record as requirements.

At an intermediate level, expectations might include awards, schedule needs, training, or internal deliveries of work products or tools that people need in order to do their jobs -- all things transparent to the Buyer.

On the other hand, Marketing may want gold plating that, since they went around the systems engineer, falls to the project manager to reject.

Everybody has expectations. Expectations carry varying degrees of force, but only those that define binding project success in the eyes of the Buyer constitute requirements.

Those in LinkedIn's INCOSE group can read a running discussion about the topic.

------------------

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e
 

Must versus Shall

Updated 2 April 2011

Many think "shall" wishy-washy and "must" unambiguous. They have it backwards.

Few understand the differences between "will," "must," and "shall." For example, since "shall" conveys a sense of weightiness, people often use it pretentiously when "will" would do.

The ambiguity of "shall" lies not in the word, but in confused vocabularies. "Must" has ambiguous timing, certainty, and force whereas "will" and "shall" imply future fulfillment. Additionally, "shall" implies certainty and authority.

A "must" may occur at any time, and its importance can range from zero to critical. One could say "it must have been," "it must be," or "you must obey." "Must" can imply reasons ranging from fulfilling a desire ("You simply must visit us!"), achieving an ends ("To retire comfortably, you must save"), or avoiding injury ("You must remember your anniversary"), to fulfilling a requirement ("The roses must be red"). It can also denote a high probability ("Since A, B, and C are impossible, the answer must be D").

A "shall" may occur only in the future relative to the time of writing, and it implies not merely prediction as "will" does, but it implies certainty or determination ("It shall come to pass that locusts will devour your grain..."). Legal and contractual language assumes satisfaction of the requirement, so "shall" denotes a command or a requirement that will, with certainty, come to pass. I did not say, "shall, with certainty, come to pass" because that would have been redundant.

"Must" carries ambiguity regarding not only timing and certainty, but also regarding consequences. Another way to say this is that "must" leaves open the question of "why?" whereas "shall" makes it clear that this is a contractual requirement. One might say "you must," but saying "you shall" implies "or else...." Shall implies a future, required or commanded action or condition, with consequences if not fulfilled.

"Must" is ambiguous. "Shall" has a narrow meaning and usage -- for those who understand the terms, at least.

Part 2.

I agree with using simpler language. "Shall" only applies to requirements statement such as

Writers employed by ABCXYZ Company shall only use "shall" to indicate requirements.

Dumbing writing down just because people don't grasp the precision of the imperative "shall" (or where to use it) crosses the line.

Someone asked, "isn't it always up to the client?" The client may have a style guide over which the employee has no influence, so sometimes, it is up to the client's preferences.

However, it is not always "all up to the client." Clients have the final say, but the Business or Engineering experts hire writers for their expertise in technical English. Technical writers should dig for expertise in their domain and tell clients what they need and why they need it. Otherwise, they should hand over their jobs to admins.

In a discussion, someone challenged me with definitions of "must" and "shall." He also claims that an Illinois Supreme Court ruling, PEOPLE v. GARSTECKI, cast doubt on the clarity of "shall."

From Dictionary.com

Shall

1. plan to, intend to, or expect to: I shall go later.


2. will have to, is determined to, or definitely will: You shall do it. He shall do it.


3. (in laws, directives, etc.) must; is or are obliged to: The meetings of the council shall be public.


4. (often in invitations): Shall we go?

Must

1. to be obliged or bound to by an imperative requirement: I must keep my word.


2. to be under the necessity to; need to: Animals must eat to live.


3. to be required or compelled to, as by the use or threat of force: You must obey the law.


4. to be compelled to in order to fulfill some need or achieve an aim: We must hurry if we're to arrive on time.


5. to be forced to, as by convention or the requirements of honesty: I must say, that is a lovely hat.


6. to be or feel urged to; ought to: I must buy that book.


7. to be reasonably expected to; is bound to: It must have stopped raining by now. She must be at least 60.


8. to be inevitably certain to; be compelled by nature: Everyone must die.

Neither #1 definition applies because both refer to a first person context, and I only defend "shall" used in third person sentences that state mandatory requirements.

Definition 2 of "shall," "will have to, is determined to, or definitely will" indicates confident prediction. Although this is not the applicable definition, it still leaves no wiggle room for non performance, should the reader mistakenly use this meaning.

Definition 3 has two points. "In laws, directives, etc." is not limited to laws. The IEEE has trended toward use of "shall." That applies to "directives, etc." such as processes, statements of work, and requirements specifications. Engineers aren't known for their flawless grammar, but this does demonstrate that in at least some usages, "shall" has taken on an unambiguous meaning.

("Shall" Def. 3, cont'd) "Must; is or are obliged to: The meetings of the council shall be public" repeats the idea that no wiggle room remains for non performance. The Illinois Supreme Court ruling in People v. Garsteki, does cite a Third Court of Appeals ruling that "shall" sometimes means "may" or "must;" but then it clarifies with a Second Court of Appeals ruling that "'shall' had a directory (strong advisory) reading when it was modified by the phrase 'whenever practicable.'"

In other words, "shall" means "mandatory" until defined conditions negate it. The meaning "may" was not inherent in "shall" itself.

Moreover, the ruling that the Illinois Supreme Court reviewed pivoted not on the meaning of "shall," but on whether the lower court observed exceptions and conditions contained in the relevant stature. It had little bearing on "shall" versus "must."

Definition 2 of "must" -- the first definition applicable to third-person usage as in requirements documents -- "to be under the necessity to; need to: Animals must eat to live," implies reference to a cause.

"Shall" avoids the question, "why?" by asserting authority whereas "must" leaves open the possibility of mitigating the reason. That's a dangerous ambiguity for creative types.

A creative astrohusband might address the cause by putting his cows in hibernation or might address the need by feeding his pigs intravenously, thereby circumventing the "must." The first applicable definition of "must," therefore leaves wiggle room for non compliance.

"Must" definition 3, "to be required or compelled to, as by the use or threat of force," fulfills the need of a compliance document.

Definition 4, "to be compelled to in order to fulfill some need or achieve an aim," parallels definition 2. The sense is not "mandatory," but "needed," which could be addressed in other ways. "Must" demands the question, "why?" Any term that demands more questions than it solves cannot be called "unambiguous."

Definition 5, "to be forced to, as by convention or the requirements of honesty: I must say, that is a lovely hat," would fit right into the structure of a requirement statement. Why must the operator place the box on the top shelf? Because that's his duty? Because that's where we've always kept it? You can't exclude this meaning, just from the structure of the sentence.

I admit, "must" definition 6, "to be or feel urged to; ought to," is conversational. However, some argue against "shall" based on how people process it. This meaning of "must" works (incorrectly) in a typical requirement statement. Definition 1 of "shall" does not. That renders disambiguation of "must" much more difficult. The same applies to definitions 7, "to be reasonably expected to; is bound to," and 8, "to be inevitably certain to; be compelled by nature."

The two (2) applicable definitions of "shall" imply unambiguously the certainty of a requirement. The seven (7) applicable definitions of "must" imply weight that varies from desire to compulsion.

As Garstecki states, if in 3rd-person use, "shall" means anything other than that the verb is mandatory, then it is superfluous; if it is there, it is there for a reason.

But I could be wrong.

Additional reading from both sides of the issue:

PEOPLE v. GARSTECKI, Illinois Supreme Courte, No. 106714, September 24, 2009. http://caselaw.findlaw.com/il-supreme-court/1272225.html

“Shall” Versus “Will.” Grammar Girl Episode 119, July 22, 2008. http://grammar.quickanddirtytips.com/shall-versus-will.aspx

The Judicial Council of California. http://www.courtinfo.ca.gov/jc/documents/reports/1004ItemA27.pdf

The US Food and Drug Administration. http://www.fda.gov/AnimalVeterinary/DevelopmentApprovalProcess/ucm078511.htm

Ministry of Economic Development (New Zealand)
http://www.med.govt.nz/upload/67526/changes_to_the_securities_regulations.pdf

Meeting Minutes and Other "Menial" Tasks

A.S. asks,

How many [technical writers] record meeting minutes for electronic distribution. In other words, perform duties of a secretary or stenographer? There are places where people view technical writers as slightly more expensive secretaries, in which you're expected to take meeting minutes. In most of my jobs, however, it hasn't been my responsibility nor do I think it should be considered part of the core set of expectations. It becomes a burden and takes away time from my normal writing and editing responsibilities. I'm encountering it more and more in job descriptions.

However the one recurring opinion I have developed from taking meeting minutes is that there are so many people who do not know how to conduct a meeting and manage the time.

I empathize with A.S. regarding the stress of having yet another serving of work laid on your already full plate.

He actually raises two issues:

• Should technical writers' duties include taking minutes?
• What should our attitudes be about unexpected duties?

Taking Minutes

Do not underestimate the challenge and prestige of recording minutes.

Producing useful minutes takes a familiarity with the players, the meeting topic(s), and the history behind the topic(s). Some meetings, such as department meetings, have topics that everybody understands. A summer intern could handle those minutes. However, other meetings, such as a corrective action board or a design review, require backgrounds far above what any secretary or stenographer has.

Stenographers take dictation. That's fine if you want everything said in the record or want someone at a higher level to edit down their transcript. It's similar with secretaries. In a technical or management-level discussion, neither has the expertise to decide what to include, and getting participants to stop and dictate during a meeting is nearly impossible.

Personally, the more content-rich the meeting, the more I struggle with taking minutes. I miss too much information when I stop listening so I can write. (I've never been able to listen and write at the same time.) Fortunately, since too many conflicts arose over what was said, I was allowed to use a recorder in my last job.

• Good: Recordings created objective evidence that settled a few disputes. 
• Better: The presence of objective evidence prevented many disputes. 
• Best: It freed me to focus on comprehending the flow of information presented by the subject matter experts so I could record not just what was said, but what was meant.

Taking minutes creates the wonderful benefit of turning each meeting into a course. Using a recorder, you get to listen to subject matter experts twice. During the second hearing, you already know the context, so discussions make more sense. Not only does the repetition increase retention, but so do the transcription, editing, and reading of the information.

Serving at the core of meetings lets you into the inner circle. You get to know the experts and managers -- and they get to know you -- as you interact to ask for clarification or to gather presentation packages during preparation. (Maintaining a library of those presentations can make you quite a resource, too!)

The learning element has another advantage in that, over time, you become the historian on many subjects. Our vice president constantly looked to his board facilitators (who recorded the minutes) for background on different issues. This not only gave us visibility, it also gave us influence.

Depending on the meeting, producing useful minutes both adds to your value and creates value -- and visibility -- in which you can take pride.

Attitude toward Unexpected Work

For perspective: Many leaders do work that subordinates ought to do. If something inconveniences you, a contributor, it inconveniences leaders even more. Tasks belong at the lowest competent rung of the ladder. As indispensable as you think you are, the time of those paid more than you has even more value.

If the job descriptions includes taking minutes, then it is one of your "normal writing and editing responsibilities." On the other hand, employers do not chisel job descriptions into stone (unless you work for a union). If your supervisor approves the task, then it is one of your "normal writing and editing responsibilities." If that overloads you, pass the responsibility for what does not get done to your supervisor by laying out your goals and tasks and asking him or her to prioritize them.

If my supervisor weren't available and I did no want the task, I would answer the organizer, "I'll be happy to take minutes this time, but next time, could you pass that through [insert your supervisor's name here] so he can adjust my priorities?" This will preserve your image as flexible, cooperative, and supportive while protecting you from future disruptions to your scheduled workload due to poor planning on the meeting organizer's part.

A.S's observation about meeting owners lacking skills for conducting meetings is true. It is also an opportunity. If you have (or can acquire) such skills, you could offer to moderate and facilitate. (By moderate, I mean act as an MC to keep things on track. By facilitate, I mean coordinate preparation and follow-up.) Of course, you need the meeting owner to agree to back you up. Moderating a meeting and taking minutes forms a package that will portray you as a leader and benefit your career.

Extend Your Time Management Skills to Your Leadership Actions

Reference: Personal Branding Interview: Jim Kouzes
By Dan Schawbel
Personal Branding Network
Posted August 26th, 2010 at 2:26 pm

You can learn leadership, and you can apply your personal skills to it.

According to Jim Kouzes, a professor at Santa Clara University and an award-winning, best-selling author, Leadership is not about who you are or where you come from. It’s about what you do. He identifies five leading behaviors:

• Clarify values and set the example.
• Envision and enlist others in a positive future.
• Search for opportunities, experiment, and learn from the experiments.
• Foster collaboration and support action.
• Celebrate contributions, values, and victories.

Kouzes recommends formulating one's values, just as one would do for time and life management (see previous entries to this blog). He then recommends conducting a dialog with the team to define work-related values of each person and then identifying the common values. When the team agrees to hold itself to the common values, trust builds and a team culture forms.

For time and life management, one identifies life goals and short-term goals that influence the priorities of long-term and short-term activities. Kouzes states that leaders share and encourage a long-term perspective with their teams. He recommends monthly team meetings to discuss issues and developments that might affect the business. Expanding members' perspectives can lead to innovation. This also establishes common priorities and goals toward which members can work; and seeing your task as part of a larger goal adds motivation.

Kouzes emphasizes that leadership must focus on building and supporting others. This goes back to values. To quote the most famous, totally unknown writer in the world (me), The greatness of a man lies not in what he accomplishes for himself, but in what he accomplishes for others. This extends to the team, as well. When each member of a team focuses on building up and empowering the other members, each person receives knowledge and empowerment from multiple directions. The team leads itself as a growing, synergistic front to any problem or competitor.

Asked about changes in leadership theory, Kouzes points out a shift from command-and-control to serve-and-support leadership. This principle goes wayyy back. For example, two millennia ago, Jesus taught on several occasions,

You know that the princes of the Gentiles exercise dominion over them, and they that are great exercise authority upon them. But it shall not be so among you: but whosoever will be great among you, let him be your minister; and whosoever will be chief among you, let him be your servant: even as the Son of man came not to be ministered unto, but to minister, and to give his life a ransom for many. (Matthew 20:25-28, KJV)

Some people can take directions and immediately act on them with all their strength. As a product of my generation, I need more. I need to know that the directions favor my own interests or at least the common good. "American values" recognize that government derives its authority from the consent of the governed, and that the governed has a right to overthrow leadership that undercuts the common good. Even the American military has found greater success with motivating followers by establishing trust and common goals.

This ties back to the concept in time and life management, that knowing why and feeling in control by connecting values and goals to tasks motivates voluntary focus and performance. What works in time and life management also works in leadership.

Whaddya know, I'm learning some transferable skills!

Job Searching: The Silence of the App

Follow-up seems to be a one-way street when job hunting.  Job hunters are advised at every turn to follow up on every lead. Give yourself name recognition, establish a professional presence on the Web, clean up your personal image on the Web, check on job status, send thank you notes.

Headhunters provide feedback.  Apply for a position and they'll let you know you're not qualified.  They'll even check back with you because you are the raw material for their product -- employees marketed to employers.

Faceless institutions, however, represent black holes.  Your app goes in, and nothing comes out; not even the gravitational waves caused by the bits of your resume' printout hitting the bottom of their shredder bin.  In the days before application via web-based databases, large employers received so many applications that the bottom line may not have provided labor hours to send out individual responses to job applicants.  With the automation that databases can perform, however, I see no excuse for not performing the courtesy of notifying job seekers when reqs close.

Granted, the flood of applications has grown even worse.  Web-based applications make positions far easier to find.  Some employers have even created mechanisms to screen out people who submit resume' spam.  That's right: Some people submit resume's for jobs not even close to those for which they qualify; and if you have the money, you can hire a business to submit your resume' for hundreds, even thousands of positions for you.  (According to What Color Is Your Parachute? 2000, (Richard N. Bolles, Ten Speed Press), that technique never works.)  If you have enough discernment to read this, you obviously would never get yourself blocked as a resume' spammer.

So, with the tsunami of job seekers, it's not surprising that you'll find little departmental information, let alone contact information, in the online career sites.  Some don't even identify the city.  The sites put up a shield of anonymity for their Human Resources departments and their hiring managers.

This quiet zone for managers creates two major problems for job seekers:  First, it destroys a job seeker's ability to prove creativity, persistence, and people skills during the application process.  Second, it cuts off any source of information that the web site fails to provide.

Several weeks ago, I wanted to apply for a low-level management position with a defense-related division of a conglomerate.  The company's career page on listed two positions, Manager I, and Manager IV.  The job descriptions were identical.  No clue was given about which reported to the other.  In some companies, a Manager I would be entry level and a Manager IV would be a department director; but in other companies, a Manager IV would be entry level the way a Second Lieutenant looks up to a First Lieutenant.

Trying to avoid becoming a blocked resume' spammer, I found some contacts in the company and called them with my simple question.  I left a voice message for all but the one who answered.  The one who answered transferred me to HR, where I had to leave yet another message.  Nobody ever returned my call.

Then I found a local facility.  Surely they would talk to me to answer such a simple question.  Wrong.  The company operator who answered would not forward me to HR unless I had a contact's name.  Instead, the operator told me to fax my question to a number reserved for faxing job applications.  The operator did not respond when I asked how many job seekers have access to a fax machine.  I just can't bring myself to investing an hour to drive all the way downtown to a Kinko's and then pay Kinko's the cost of a fax, just to get one little question answered.  I have since replaced my broken $50 scanner/printer with a $69 clearance-priced copier/scanner/printer/fax, but I doubt I would ever have received a response to my question.

I guess this leads to pet peeves about employers' career sites:  First, the wall of anonymity limits job applicants and their evaluation.  Second, not enough information is available about the structure of job titles.  Third, few provide any feedback after you submit your application.  (They usually send an automated e-mail to acknowledge the first application you submit each day.)  The only way to status your application is to go into their database.  If they track the positions to which you apply, some will give a one-word status if the job req is still open.  Otherwise, the job req simply disappears from their database.  In other words, the page for the job req no longer exists and the database forgets that you ever applied for the job.  But sometimes, even those two indicators conflict.

Before I conclude, I want to honor Eaton Corporation, GE, and Raytheon Corporation.  Their job application databases have informed me that jobs for which I applied have closed.

Hypnotic Language Patterns

Basic familiarity with hypnotic language patterns can help you defend yourself against politicians, advertisers, and salespeople who don't necessarily have your best interests at heart.

 Summary:

• Indirect hypnotic language avoids argument or resistance.  Instead of commanding -- you are feeling sleepy -- hedging and suggesting leave more choice to the subject.  For example, instead of telling the subject, imagine yourself, suggest, perhaps you can remember.
• Indirect hypnotic language gives freedom to interpret what is being said in a way that makes sense to the individual.  Instead of putting you on a beach, it lets you choose a peaceful place.
• This focuses attention inwards.
• The yes set is a series of self-evident statements that conditions you to agree with whatever comes next.
• Truisms can lead into a tag question to make the statement before it less direct and easier to accept.  It works, doesn't it?
• Splicing a suggestion to a truism, even if one phrases does not logically flow from the other, associates the truth of one phrase with the other.
• Illusory choices or double binds presuppose the same outcome.  Would you want to pay with cash or with credit?
• Nominalisations use words with ambiguous connotations to turn the mind inwards to attach individual meaning to them.

Language that bypasses disagreement and requires the mind to make subconscious choices prepares the mind to receive suggestions.  Hypnotic language then delivers suggestions in forms easily processed by the subconscious mind:

• Deliberate confusion
• Ambiguity
• Metaphors
• Puns
• Analogies
• Narratives