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.

The Verification Cross-reference Matrix (VCRM)

Background

After defining and organizing requirements, managers need to track compliance.  This post describes a method used in engineering, but the method helps with any kind of project. The Verification Cross-reference Matrix (VCRM) addresses, or puts you on the path to addressing, many needs.

1. Requirements, as documented through surveys, interviews, analyses, contracts, Statements of Work, standards, or regulations often mix requirements with preferences and background information. Before you begin work, you need to isolate the essential information to gain approval of mutual understanding between customers and the planners or designers.
2. To determine or reflect the steps of the service or the components of a product (for example, in a Work Breakdown Structure), you need to organize requirements.
3. Before starting work, you need the team's agreement that the requirements make sense. For example, are they SMART -- Specific, Measurable, Achievable, Realistic, and Timely? (There are many variations on SMART, and it is only the beginning of the types of tests one can apply to requirements. For example, is the requirement written in active voice? Does each sentence have exactly one requirement? Is each requirement verifiable?)
4. The planners or designers need the requirements in a format that allows them to check off each requirement as they put it into effect in the plan, solution architecture, or detailed design.
5. Risk analysts need a list of requirements for early what-if analysis.
6. Test engineers need to identify parameters that will require measurement. They will need to add requirements to build measuring points and measuring devices into the system, or they will need to obtain test or monitoring equipment.
7. Verification requires planning the conduct of testing so that it occurs in a logical order and in coordination with other processes such as project phases, start-up, or burn-in.
8. Validation and customer acceptance require relating the results of verification back to the original requirements as evidence of compliance with the terms of the contract and fulfillment of the customer's needs.

This post provides a summary of traditional methods that support the above needs.  Each topic above could lead to another post, or even books. When exploring this area, one should consider another tangential topic, requirements traceability. Traceability allows creating threads showing linkage of the details to the general requirements. This allows management to

• identify every detail that may be affected when a more general requirement changes
• prevent creation of details that the general requirements do not authorize
• ensure that the details fulfill every general requirement
• re-use portions of the product's or service's organization in future projects for cost and schedule estimating and for planning or design.

The VCRM

A VCRM lists the requirements of a specification and identifies the method(s) for verifying them. The details included in a VCRM vary with the customer, the phase of the contract, the nature of the contract, and the relationships within the contract.

Simple VCRMs such as the one used by NASA in figure 1 list requirements and the appropriate quality control methods for each requirement. This would more properly be called a “Requirements Verification Matrix.” Detailed VCRMs may include considerably more, such as test ownership, verification requirements, and verification results.

Figure 1. Simple VCRM from a NASA specification. (Click for larger version.)

The QC methods normally include Inspection, Analysis, Demonstration, and Test (IADT).

• Inspection includes qualitative observation. "The fruit basket shall include three Granny Smith apples." (You don't need to run DNA tests to verify that.)
• Analysis includes computation or comparison to historical or experimental data.
• Computation: One might have to calculate the power of munitions, since using them destroys them.
• Comparison/Similarity: Since Project A used Widgets, Project B can re-use the historical data to show that the Widgets meet its requirements.
• Modeling and simulation: We have all seen photos and videos of smoke streaming over the wings of model airplanes or cars in wind tunnels. Did you know that scientists can run computerized simulations of galaxies colliding? They get the results a lot quicker than when they wait around billions of years to see what happens.
• Demonstration verifies performance of a function that does not require qualitative measurement.
• Test verifies that a function executes within specified parameters.

Variations

Figure 2 shows an example VCRM from the Department of Transportation that includes the complete text of each requirement, added information about the verifications, and the party responsible for each requirement's verification.

Figure 2. Example VCRM from the DOT. (Click for larger version.)

The DOT calls what NASA used (figure 1), a Requirements Verification Matrix. The simpler table does not really cross-reference the requirements to anything else. The DOT adds part of the Test Plan (columns 4-6) before calling it a VCRM.

The DOT adds Certification of Compliance as a test method. They don’t define it, but it sounds like a type of Inspection where you inspect a certificate rather than inspecting the product. Since the contract has multiple sellers, Certification of Compliance might refer to using certificates provided by an equipment provider. For example, if the Government furnishes its own equipment for the contractor to install, it may already have verified the equipment’s compliance. Other examples would include calibration certificates or certifications by independent testing labs.

Figure 3 shows an example of a procurement specification that allocates verifications to contractual phases and cross-references performance requirements to verification requirements. Figure 3A shows the table and figure 3B shows verification requirements.

Figure 3A. VCRM used by U.S. Army Corps of Engineers. (Click for larger version.)

Figure 3B. Verification requirements used by U.S. Army Corps of Engineers. (Click for larger version.)

Figure 4 includes a “VCRM” that documents not only the verification plan, but also the data that determines compliance. This goes beyond calling it a “VCRM.” It should, perhaps, be called a Verification Report.

Figure 4. Verification requirements used by U.S. Army Corps of Engineers. (Click for larger version.)

Forcing design and requirements engineers to identify verification methods protects both Buyer and Seller by ensuring that the requirements are verifiable. By definition, one cannot verify an unverifiable requirement. Without objective verification criteria, a Seller can falsely claim to have fulfilled the contract or a Buyer can claim the Seller did not fulfill the contract. Including VCRMs in specifications allows general agreement about requirements verification methods and prevents problems during product acceptance and at contract closure.

In the world of paper requirements documents, VCRMs occupy an appendix or the beginning of the Quality Assurance section. Each document contains its own VCRM. Simple tables contain the data. However, Requirements and Test engineering should control VCRMs centrally. The reason requires taking a tangent into requirements control.

Tools

Many projects now used a database such as DOORS to control requirements. Databases' storage tends to isolate a sentence from its context, forcing statement of each requirement explicitly and independently. The repetition is a pain, but it ensures design quality by forcing exhaustive identification of requirements and by reducing or identifying ambiguity in the scope.

At one company, a project manager employed a distributed requirements database. He allocated requirements using spreadsheets and distributed them to the various design teams. He reassembled the spreadsheets later.

During the project, multiple teams took ownership of some requirements, while nobody took ownership of others, especially when one team would try to transfer ownership of a requirement to another team. Project management had to play catch-up with ownership changes and the teams had to take corrective actions to address dropped requirements.

The lack of centralized control also resulted in the loss of rationales and lessons learned. A robust requirements database would have retained such information. Even a requirement labeled "not a requirement" would have been retained in previous baselines.

Instead, teams kept records at inconsistent levels of detail and often discarded records after deeming them irrelevant to their own efforts.

A requirements database allows you to trace up and down the layers requirements as they are decomposed. One can use Excel spreadsheets for a simple set of requirements. A larger operation needs tools such as DOORS, RTM, or a database developed in house.

Such tools allow one to verify product scope by ensuring that lower-level specifications satisfy each top-level requirement. The help prevent requirements creep by verifying the contractual authority of each bottom-level requirement. This is called traceability.

One can also take the requirements database to the next level by adding (or linking to it) a Verification layer. The Verification layer identifies the Test plan that verifies each requirement. A robust database could even contain the test documents and results.

Case Study

A friend, Jim Pannunzio, once worked on a contract for a first-of-its-kind product. Since many requirements had high risk of being unachievable, the contract provided incentive fees for accomplishing the high-risk requirements.

The company had not used the right tools, so they had not traced some successful tests to the requirements and had failed to bill the customer. This cost them money. When Jim cross-referenced the verifications to the requirements, he found a number of such requirements. Jim also found requirements that the company had failed to verify. This allowed him to suggest further verification.

By identifying untested requirements and untraced successful verifications, Jim’s attention to detail brought hundreds of thousands of dollars of added revenue to his company and turned the project from an economic failure into a success.

Conclusion

Tight integration between requirements and verification provided by a VCRM forms a vital link between design and thorough quality control, between contractual provisions and acceptance, and between the buyer’s and seller’s bank accounts.

For more information see:

Scukanec, Stephen. A Day in the Life of a Verification Requirement. Northrop Grumman. 28 January 2008. http://sstc-online.org/2009/pdfs/SJS2408.pdf
or
Scukanec, Stephen, and James van Gaasbeek. A Day in the Life of a Verification Requirement. Northrop Grumman. 24 October 2007. http://www.dtic.mil/ndia/2007systems/Wednesday/AM/Track1/5536_1004_1042.pdf

Sources:

Figure 1: Goddard Space Flight Center, Greenbelt, Maryland. National Polar-Orbiting Operational Environmental Satellite System (NPOESS) Preparatory Project (NPP), Science Data Segment Requirements Specification, GSFC 429-05-11-01. April 7, 2005. http://nppwww.gsfc.nasa.gov/PEATE/NPP_SDS_Lev3Req.doc. Downloaded 1 June 2011.

Figure 2: Office of Operations, Federal Highway Administration, Department of Transportation. Testing Programs for Transportation Management Systems: A Technical Handbook. Appendix A, Example Verification Cross Reference Matrix. June 20, 2007. http://ops.fhwa.dot.gov/publications/tptms/handbook/app_a.htm. Downloaded 1 June 2011.

Figure 3: Engineer Research And Development Center, Corps Of Engineers, U.S. Army Topographic Engineering Center, Alexandria, VA. Performance Specification: Improved
Position and Azimuth Determining System (IPADS), MIL-PRF-52955C. 8 November 2002. https://aais.ria.army.mil/AAIS/Award_web_03/DAAE2003D01500000/DAAE2002R0177/attach_exhib/spec_attachment_2.pdf. Downloaded 1 June 2011

Figure 4: Baun, Rich. GLAST Large Area Telescope: LAT Pre-Shipment Review: LAT Level Test Verification Process. Gamma-ray Large Area Space Telescope. 27 April 2006. http://www.slac.stanford.edu/exp/glast/flight/rdm/livepreship/04_Test_Verification_Process.pdf. Downloaded 1 June 2011.

Copyright 2011, 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

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
 

Speed Up MS Project 2007

When Microsoft Project 2007 slows to a crawl, speed it up with this simple tip.

As the project size grows, so does the file size. Updates to one entry can have a ripple effect. For example, changing a date early in the project's critical path can force changes to all the following dates. Project has to make all those calculation and then rewrite all those pieces of information in the project file.

You can speed up Project by turning off the automatic recalculations.

• In the menu bar, click on Tools. 
• In the pull-down menu, click on Options. 
• Click on the Calculation tab. 
• Change the calculation mode from Automatic to Manual. 
• Click on Close.

Setting MS Project Options for Manual Recalculation
(Click figure to view at full size.)

Entering data will go like it was a new project again.

Here's the drawback: To see the effect on calculated values, remember to click on Tools, Options, Calculation, and then click the Calculate Now button. 

There's a shorter way. You can set it up as follows.

• In your standard command toolbar, click on the down-arrow at the far right. See the illustration.

Accessing the Customize Toolbar Dialog Window
(Click figure to view at full size.)

• Click Add or Remove Buttons.
• Click on Customize.... 
• The Customize dialog menu should appear as shown in the next figure.
• Click the Commands tab of the dialog window.
• In the Categories list, click on Tools.
• Scroll down in the Commands list until you see Calculate Now.
• Using drag-and-drop, drag the Calculate Now icon to the standard command bar. You can place it anywhere you wish in the bar. I put mine next to the Help icon.

Adding a Calculate Now Button to the Standard Commands Toolbar
(Click figure to view at full size.)

You should have a Calculate Now button in your command bar, as shown in the next illustration.

The Calculate Now Button in the Standard Commands toolbar.

These changes personalize Project. They will apply every time you open Project, not just for the large file you are working on. To set recalculation back from Manual to Automatic, follow the same steps. You might, however, consider leaving the new button in your Standard Commands Toolbar.

Changing the frequency of recalculation from automatic to manual speeds up Microsoft Project 2007 for large project files. The same idea, and very similar steps, also works in Microsoft Excel. And now you know how to add frequently-used commands to (or take buttons you never use from) your toolbars, too!

Strange Phrase: Hoisted by His Own Petard

For tis the sport to have the enginer Hoist with his owne petar.

 -- Hamlet

Petard or petar was a container filled with explosives and placed against a gate to encourage it to open. The word itself comes from the Middle French word meaning to fart. So, what has this to do with hoisting anyone to his just deserts?

Unwelcome guests would place a petard on a long lever arm. The lever arm's mount resembled that of a trebuchet. The machine would sling the petard over against the gate and hold it in position while its operators remaining behind cover.

Upon release, the arm would hoist a careless, entangled army engineer toward the gate along with the petard. If this occurred at the wrong moment, it would result in the undoing of the engineer's structural integrity.

References

• Hoist with your own petard. The Phrase Finder. http://www.phrases.org.uk/meanings/hoist by your own petard.html.
• Petard. Wikipedia. http://en.wikipedia.org/wiki/Petard.

To maintain propriety, I formated this post using Trebuchet font.

Manipulating Employees into Overtime

It is my honor to compensate for my failings and it is my pleasure to donate to what I support.

Your work ethic, probably like mine, demands of you an honest day's work for an honest day's pay. If I underperform, I will use my personal time to make up the quantity or quality of work that I should have produced. My work ethic frees me to donate my personal time to help my company and my coworkers.

Any attempt through extortion or fraud to obtain what I have not agreed to provide, however, dishonors me. It devalues my time and personal value, dishonors the contract between me and my employer, and disrupts my relationship with my managers.

They say "time is money." Taking time without compensation steals money.

Time is also life. Taking time without compensation steals life.

My managers used the tactics described by Geoffrey James to manipulate their people many times during my career. Many did it with the best of intentions, since they had fallen for the tactics themselves. To them, I would say what these paragraphs contain with respect and only in chunks that they could handle.

It feels great to think of oneself as professional, especially when starting one's career. However, unless you have a masters degree, a doctorate, or some sort of recognitions such as Professional Engineer, member of the State Bar, or physician's license, think twice before calling yourself a professional. It's one thing to be professional (adjective) and exercise professionalism. It's another thing to be a professional, be compensated as a professional, and have the demands that go with such compensation placed upon you.

If you supervise people, always remember that taking your employees' time by coercion or by fraud steals their money and life, just as surely as did the thief who stole my boat motor. What you steal from employees, you steal from their friends, their families, their causes. Moreover, disrupting their recovery or study time will erode their spirits, their energy, and their ability to grow.

Imposing your pressure-formed work ethic on others will produce unintended consequences. Productivity and quality will erode. Happily donated time will become resented stolen time. Growing employees will stagnate. Your community and its values will deteriorate. You will exacerbate the class divides that progressives and Marxists seek to exploit, thus the justifying government interference that hinders business and saps profits.

Even if you do not believe in karma or in Judgement Day, in the end, you will repay.

Reference: James, Geoffrey. The 7 Dirty Tricks That Bosses Play (and How to Cope). BNet: Commentary. 21 April 2011. http://www.bnet.com/blog/salesmachine/the-7-dirty-tricks-that-bosses-play-and-how-to-cope/15211?promo=713&tag=nl.e713

Copyright 2011, Richard Wheeler

My Tech Support War Story

I've known people who were... not exactly computer literate.

One day at work, I heard a cranky old engineer over the cubicle wall. "Blank blank blank blankety blank!"

(Pause....)

"Blank blank blank blankety blank!"

(Pause....)

"Blank blank blank blankety blank!"

He asked his neighbor for the number for tech support. It was "2-HELP."

"Blank blank blank blankety blank!"

"Hello? I'm having a problem with my computer...."

I listened for a while and grew increasingly amused. Tech support couldn't figure it out, either. SLAM went the telephone. "Blank blank blank blankety blank!"

I walked around Cubicle Island and approached him. "Hey Del. Can I help you with something?" By now, I was about to bust a gut, but not from laughing; rather, from holding back the laughter.

"Blank blank! I don't think so. Even the Help Desk couldn't figure it out. They said they'd have to send somebody to look at my computer."

"Well, since I have eyes on the situation (and, I didn't mention, since I know you), why don't you tell me your problem?" I already knew the problem, but this was too fun not to drag out.

"Every time I type something, what was already there disappears! Blank blank computers!"

I said, "Del, on the right side of your keyboard, above the arrow keys, you will see a key that says, 'Ins.' That is your Insert key. Tap it one time and then try typing again."

Sure enough, that fixed the problem.

Nit of the Day: Panes vs. Panels

A member of LinkedIn's Technical Writer Forum asked, I want to find out the difference usage of these two words: pane and panel. e.g. There are two panes or panels on this screen. You can place a dockable panel (not pane) anywhere on the screen. (sic)

A panel is a flat, physical area, usually containing controls, receptacles, a display such as an LED or LCD screen, or allowing users to remove it for access to whatever lies behind it. A screen is, technically, a physical, displaying area of a panel.

A pane is a section of a window. For a physical example, a paned window is a window that is divided into sections known as panes. Originally, the meaning pertained to sectioned glass windows in walls. (Wikipedia).

Thus, panes in Word 2007 would include the title bar where it shows the names of file and of the application, a menu bar, a "ribbon" bar, the editing area, a status bar, and optional ruler bars.

Microsoft uses "task pane" to designate an area sectioned off from the main area of an application and used for some function. For example, in Excel 2007, if you click on Review, Thesaurus, Excel will divide off a portion of the editing pane to create a dialog pane so you can search for synonyms.

MS Office task panes are dockable: You can drag them to different borders of the window or leave them to float, independent of the application window. Thus, Office task panes can convert between panes and pop-up windows.

• Panes make up windows.
• Windows occupy the screen.
• The flat-panel display houses the screen.

The screen is both physical and virtual, whereas the panel is only physical, and the panes and windows are virtual.

To correct the question:

Better: There are two panes or panels on in this window screen. You can place a dockable panel (not pane) at any margin of the editing area, or you can leave it as a pop-up window anywhere on the screen.

Best: This window has two panes....

If the company style book differs, however, remember the Golden Rule: He who has the gold makes the rules.

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

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

The New Resume: For Experienced Workers

Long-term worker, expect resume-shock.

If you haven't explored the job market in five or ten years, you probably need a whole new resume. What works best has not changed, but what's commonly recommended has. Throw out all your old materials about resumes.

• Older materials explain the Functional style. Recruiters and hiring managers reflexively ask, "what is the applicant hiding?" and give functional resumes a quick toss.
  
  
• Many older samples used paragraphs; but paragraphs have given way to concise bullet points.
  
  
• Your descriptions of achievements, employment history, and objectives may need a radial re-write..

It's not about me.

Your Achievements and Employment History sections used to describe what you did. Now, every description must state how well you did it or how it will benefit the reader.

The same applies to the Objectives statement. Replace it. First, the application or cover letter should make it obvious which job you want. Second, emphasize what you bring to the pot luck, not what you hope others will bring. Your resume is a marketing device, not a Request for Proposal.

That's tough for long-term cogs of giant machines where managers rarely communicate the significance of the work. Restating my duties as accomplishments with numbers and results, and figuring out my work's significance from 10, 15, or 20+ years ago required a lot of research. But it has to be done.

Value propositions are in.

Look at the job description and at the company's mission and objectives statements. Figure out the business case for the job. How do the job requirements support the employer's goals?

Then consider your abilities that match the job requirements. Why does the employer want somebody with your skill? What is the value of your skill? Ask and re-ask what happens for the employer if your skill provides that value. Stop when you get past your sphere of influence, and take a step back. Now you can state the value you will bring by doing what you do.

Don't claim the VP's accomplishments. State that your redesign saved the final $2 million that made selling doohickeys profitable, but don't claim to have saved the Division (unless you really did). For example, if the required life of a satellite was seven years, you could describe how you contributed to on-board diagnostics that extended the life to 15 years.

Specifics build a case for the truth of your claimed abilities.

Set a time limit to avoid agism.

By the way, only go back ten (plus or minus) years. If you haven't lost the skills you had in ancient history, they've probably become obsolete. I break that rule. I divide my employment history into Recent Employment and Early Employment (>10 years ago) and go back all the way. I enjoyed and want to return to those older jobs. Without the older jobs, I can't support some of my claimed abilities. However, if I can support my claim to be qualified for a job based on my recent employment history, I chop out the Earlier section.

Let the shoe fit the foot.

This goes to tailoring your resume for each position. The combination format allows me to sort my Accomplishments so the most relevant skills appear at the top. It also allows me to delete distracting, irrelevant skills.

If you apply for a variety of jobs on a corporate site, however, they probably limit the number of versions of your resume. In that case, you have to keep each version of your resume longer and more general.

Less is more, but more is more, too.

Starting out, one page is reasonable. Short and relevant is best. A lot of technical managers want details, though. Making them get out a magnifying glass is not the way to do it. A veteran engineer who organizes a resume with lots of headings gets the "core competencies" across in a 15-second reading. If that 15-second read catches the hiring manager's interest, the applicant will probably get away with two or three pages.

Apart from the part about job objectives, Barclay's podcast provides a great overview.

Note: Most European employers and many American professions such as academia and research require curriculum vitae (CVs), not resumes. All I know about CVs is that they can run many pages.

Conclusion.

The worst resume mistakes of 2011 include describing what you want or what you have done. Every statement of proposed value, accomplishment, or history should demonstrate how you will support the employer's business. Keep it as short and as simple as you can, but include enough to support each claim you make.

For a good audio over view of resume writing (except that he still uses Objectives instead of Value Statements), visit The Job Stalker - PodClass III - Resumes.

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

Writing "Warmly"

Reference: I read an article about techinical writing skill, it advised to write in warm words, i have no idea what does the warm words mean? does it mean short sentences, very concise, no big words? Technical Writer group, LinkedIn.com. 18 January 2011.

Jiawei, a technical writer from China, wants to know what "warm words" means. Other writers haven't heard this term used. Jon guesses that it means words that make the reader feel included and able to relate to the article. Doug guesses that it means stating the goal of a procedure before listing the instructions. Nick things it refers to ambiguous words that convey a warm feeling. Ray said it was nonsense. Most agreed that warm words have no place in technical writing.

I think "warm words" can mean writing in a friendly, understandable way. In English, we try to write as an equal to the reader and assume that the reader welcomes the information or instructions we provide. As part of this, it can also mean using humor and conversational words.

I think "write warmly" can mean writing as though the reader is your equal and welcomes your instructions. It can also mean using humor and conversational words.

I learned from my wife's uncle, a Ukranian Jew who survived Hitler's death camps, that many languages such as Russian have different ways to state the same thing to different people.

For example, the same statement, "The thermometer reads 98.6 degrees" might use different sets of words when addressing a superior, an equal, a subordinate, a customer, or a child. Learning such differences can be like learning different dialects. I think this is also true of Japanese.

I've seen attempts to carry over excessive politeness in Asian instructions written to American consumers. English generally lacks such differences. Most English-speakers have a distaste for class distinctions. Writers need not say,

1. Please use the video cable to connect the DVD player to the TV.
2. If you wish, you may plug the DVD player's power cord into the wall socket.

Rather, the writer may address the reader as an equal and as somebody who wishes to be told what to do.

1. Using the video cable, connect the DVD player to the TV.
2. Plug the DVD player's power cord into the wall socket.

Those who dislike being told what to do (in other words, men and teenagers) will ignore the instructions, so the writer cannot offend them.

A variation on this theme: While you should assume that your readers want you to tell them what they need to know, do not assume that you know their mind. You do not want to alienate readers by making them feel like you judge them or like they are dumb.

Note the mild humor I injected about how men and teenagers dislike taking orders. I do not suggest using humor in cross-cultural writing. It's too easy to make mistakes. I have seen web pages devoted to collections of embarrassing mistakes in English signs designed by non-English speakers.

However, I will often use mild humor (sparingly) to make text more interesting. I believe that when readers enjoy reading my text, they will be more likely to read, will read more of it, and will read more carefully.

Conversational text means using terms easy to understand. Avoid slang, buzzwords, and big words where smaller, more common words will suffice. Use acronyms only after you have spelled out what they mean, only if you need to use the terms more than a few times, or only if "every" potential reader understands them (such as DVD and TV). Above all, never use abbreviations normally used in cell phone text messages! I hate when people do that on LinkedIn! You want your reader to understand without having to interpret.

If you word your technical writing as though you write for equals who want you to tell them what to do, take a risk with a little mild humor once in a while if you know the readers' culture, and use a conversational style as much as possible, your writing will become "warm" and enjoyable.

Four More Tips for Using Social Media in Job Hunting

5 Tips to Keep Your Head Above Water with Social Media
by Laura Click, founder of Blue Kite Marketing
Guest post on the blog of Dr Shannon Reece
21 December 2010

I’m at a turning point in my approach to job hunting. The referenced article (above) reinforced my decision. The article aims at a wide audience (points #3 and #5 have the most value for me), so I'd like to apply it more narrowly to my comrades in the unemployment line.

1. Perfect your profile. Your profile on an SM site is your resume. Make sure it shines when recruiters find it.
   
2. Search for the best way to locate open positions. Learn to use Twitter’s search function and to find job announcements in LinkedIn groups.
   
3. I get a lot of self esteem from helping people by answering questions, but the ROI is zero. Figure out what activities do and do not get you interviews.
   
4. The recommended half day is way too much time to put into social media. Allocate more than a half hour only to activities that produce leads.

Social Media and job-hunting experts have repeatedly told me to use SM to help people so somebody will notice and help me. I give up on that. Or, at least, I’m going to apply that advice a lot more narrowly.

Recruiters - What to Expect

Reference
Two Types Of Recruiters – Retained and Contingent
Brad Remillard
IMPACT Hiring Solutions
Undated; downloaded 16 January 2011

Summary of the Article

Recruiters contract to find applicants on behalf of hiring companies. Two major categories dominate: Retained, and Contingent. They may be a convenience, a connection to that job you need so badly, but neither works for you. They work as hired guns for the employer.

Retained recruiters get paid 2/3 of their fee whether or not the company hires the applicant. They only get the final 1/3 if there's a hire. They also offer guarantees to their clients (the employers), so if a new hire doesn't stick around, the recruiter has to return part of the fee and loses a bit of his reputation and future business. An employer won't want to pay multiple fees for each employee, so he will contract only one retained recruiter.

Retained recruiters protect their business by getting to know a company's culture and job requirements and by obsessing over finding the perfect match. Expect a thorough, frustrating screening and then having to repeat the process with the hiring company. They also submit only a few resumes, so the applicant competes against only a few others; but the others have gone through the same screening and match the job well, too.

Contingent recruiters get paid only if you're hired. No matter how many contingent recruiters submit applicants, the company only pays one, so a whole squad of recruiters might go out looking with a single position to fill. If two submit the winning applicant's resume, the first one gets the fee. This put them in competition, so they collect resumes for fast submission and skimp on niceties like pre-screening.

Applicants relying on contingent recruiters compete against the larger number of applicants from multiple recruiters and have lower likelihood of fitting the job; but other applicants are less likely to fit the job, too. Applicants don't go through dual screenings, and their names get in front of the employers sooner, but they experience more of the black hole effect, never hearing back from the recruiters.

Also, once a contingent recruiter has your resume on file, he might submit it to companies without your knowledge. This can complicate your search if employers get tired of seeing your resume submitted for positions for which you don't qualify.

When dealing with a recruiter, ask how his client compensates him and how he will use your resume later.