As PDF is the dominant format for corporate document sharing, it is no wonder there is a wide selection of complimentary tools that can help you get more done when working with this file format.
Even though Adobe also has its set of additional tools and extensions, at times they can cost a lot of money.
Luckily, there are a lot of free options a professional can choose in order to be more productive.
One tool that is particularly popular among lawyers, accountants and HR managers is this free PDF to Excel online software.
The beauty of this tool is that it allows you to convert extensive PDF reports without any limitations on the number of files you can convert, or their size.
For example, an accountant can easily take a large annual financial report in PDF format and convert the figures into editable and collectable financial stats. Similarly, an HR representative from a big corporation can easily convert job application data saved in PDF format into editable Excel sheets and save a lot of time by doing so.
PDF to Excel converter is not only more time efficient, but also more effective. By giving the software the task to compile data, the number of mistakes that a human would make while transferring data manually is much smaller.
You can easily use this tool by following the 3 simple steps below.
To start, take the PDF file you want to convert by clicking on the Select button, as seen from the image above. A great bonus for this tool is the fact that you can use it with any device, as the page is absolutely responsive. This means that you can finish all the paperwork from either your PC, laptop, tablet or a mobile phone.
Lastly, click the green Convert button in the third section. Your conversion should take only a couple of minutes. In rare cases it can take a bit longer (up to 30 minutes) if there are a lot of conversions in queue.
That was it, a really simple and free way to save yourself some time at work. Feel free to check this tool out for yourself.
(Do you have any other alternatives for converting files to your favorite formats? Please leave a comment down below. Thanks.)
If you pull your readers into a topic by asking a rhetorical question that’s perfectly acceptable as a writing style.
But if you do that, you’d better answer your own question right away. Otherwise some of your readers can be really frustrated.
Rhetorical questions increase the stakes. They introduce a tension that needs to be relieved by delivering the promised answer. You cannot assume that the readers know the answer to such a question.
Rhetorical questions that are left unanswered is a sign of sloppy writing at best. Some reader may even construe it as “disrespect for the audience.”
Here is an example:
The paragraph opens up with a wonderful teaser: “So, what is Git in a nutshell?”
But then writer disregards her own question and forgets to answer it. No where on the page is there a definition of Git “in a nutshell.” The overall impact is one of frustration and unrealized user expectation.
If you’d like to maximize the User Experience (UX) of your documentation don’t forget to answer your own rhetorical questions. The sooner the better.
Every job, every occupation has its rules, correct?
Break these rules and you’ll be in trouble.
Here are some general rules in tech writing:
Tech Writing is Correct
This is the most important (but not the only) characteristics of technical writing.
No matter what else it is, a technical document first of all needs to be CORRECT and ACCURATE.
If it’s not correct, nothing else matters. You can dump such incorrect document straight into the trash bin.
For example, if a document instructs the user to connect a 100 Volt appliance to a 220 Volt outlet, that is an incorrect and dangerous instruction. Wrong technical instruction can be very costly and even lethal at times.
So I cannot emphasize this one enough: please make sure your documentation is CORRECT above anything else. Double and triple-check the accuracy of everything you write.
Tech Writing is Detached
Technical writing is detached from our emotions and value judgments as human actors. For that reason, a technical writer should refrain from projecting human desires and emotions onto technical systems.
For example, be wary of the verb “want” since a system really never “wants” anything. It either does something or fails to do it.
BAD DESCRIPTION: “When you press the START button, don’t worry if the engine does not want to come alive right away.”
BETTER DESCRIPTION: “Press the START button to start the engine. Wait a few seconds if the engine does not start right away.”
(What do you think about this post and video? Please leave a comment. I’d like to know what you’re thinking. Thanks!)
Someone said “good technical writing is boring writing.”
Not only that is true, but that’s a beautiful thing too.
Allow me to explain.
Let’s think about what makes a piece of writing EXCITING versus BORING.
Read any creative writing book you like and I think you’ll see that the author recommends VARYING word usage, VARYING sentence length, VARYING adjectives and descriptions, the voice and even POINT OF VIEW….
VARIANCE, in short, is what makes prose exciting and ENTERTAINING.
But VARIANCE can literally be DEADLY when it comes to technical writing.
Would you rather be ENTERTAINED or DEAD? (I’m exaggerating a bit of course but I think you get the idea.)
Here is how my reasoning goes…
Imagine you are flying in a commercial airplane.
Again imagine that the MAINTENANCE of that plane has been performed just before you took off, by MECHANICS who were trained by MAINTENANCE GUIDES that included a lot of ENTERTAINING VARIATIONS such as the following:
Page 16: “The TURBO FANS must be maintained every 100,000 aeronautical miles.”
Page 52: “Use only GR567 fluid when greasing the TURBO BLADES.”
Page 110: “Follow these procedures for the second stage of ENGINE ASPIRATION UNIT maintenance…”
Page 268: “Follow these procedures to uninstall and re-install each PROPELLER FIN UNIT…”
Imagine the mechanics trained on an ENTERTAINING maintenance manual, complete with JOKES and TRIVIA, a manual in which the same object (ENGINE FANS) is referred to 4 different ways, with a lot of VARIANCE….
Would you feel flying on a plane like that?
I definitely would like to fly on a plane maintained according to a manual in which the same object is referred to in exactly the same way throughout the manual. I’d feel more comfortable with a manual that exhibits ZERO VARIANCE.
And such a manual would OF COURSE be BORING by DESIGN.
As technical writers we are not trying to entertain the world. There are plenty people who are doing that.
We are instead trying to EMPOWER people so that they will PERFORM technical PROCEDURES without any ERRORS, and do so in a TOTALLY PREDICTABLE way, in a fashion that F-15 pilots call “FLAWLESS EXECUTION.”
Without FLAWLESS technical documentation, there is no flawless execution and lives would be at stake.
So cheers for the no-variance documents! Cheers for boring manuals! And cheers for safe trips across the continents.
(What do you think on this issue? Please leave a comment below. Thanks.)
I’m embarrassed and actually still blush a little when I remember how I started my tech writing career.
The year was 1998.
At the time I was a reporter for a print daily covering the U.S. State Department and the U.S. Congress.
It was an exciting job which allowed me to rub elbows with the rich and famous, the movers and shakers of the nation’s capital.
These were all powerful men and women, way above my socioeconomic class and pay grade.
If it weren’t for my credentials as a journalist, I’d never have the chance to share the same room with them.
Once for example I rode the same elevator with the late Sen.Ted Kennedy of Massachusetts. Perhaps a trivial moment by the standards of many people but I still remember that day.
Other times I would attend the press briefings at the White House even though I was not an accredited White House reporter. To be in the same room with a Cabinet Secretary or the President of the United States is an experience I’ll cherish as long as I live.
However, the truth is I wasn’t making any money at all.
The print journalism was already in trouble and I knew I had to something else if I were to take care of my family.
One morning as my wife was leaving the house I asked her where she was going. “To my head hunter,” she said. Back then she was a newbie computer programmer looking for a job.
“You wanna come too?” my wife asked.
And for no good reason at all, for reasons I still cannot explain, I said “Yes, why not?”
So we went together to this glass-and-chrome employment agency office in a commercial tower in Rockville, Maryland.
After the usual exchange of pleasantries, my wife introduced me as a writer in-between jobs, which in a sense was true.
After she listened to me for a few minutes, the recruiter said something that changed my life forever:
“I might have something for you… would you considering a technical writing position?” she asked.
And like an idiot, I said … “What is that?”
My god, I still cringe when I remember that moment. Whew!
The truth is, like millions of people in the world, I also had not heard of “technical writing” before.
She explained to me patiently what tech writing was and why it would be a great fit for me given my technical and creative sides. I kept nodding my head and the rest is history, as they say.
So if you at this point also do not have a very clear idea of what technical writing is, it’s completely understandable because once upon a time I didn’t know what the heck it was either. There’s a beginning to everything, isn’t it?
(How do you feel about this video? What do you think? Please leave a comment below. Thanks.)
1) Create a free account.
2) Go to https://www.glassdoor.com/index.htm
3) Make a search with keywords, company, or title. For example let’s use “writer” as a search keyword. For the city, we’ll use “New York City”.
4) Click Search. This will take you to search results page.
5) Click the Create Job Alert button to receive daily job alerts about writing jobs in NYC.
1) Sign on to your free Google or Gmail account.
2) Go to https://www.google.com/alerts
3) Enter a keyword into the “Create an alert about…” field.
4) Configure alert options by clicking the Show Options drop-down list.
5) Click the Create Alert button.
1) Log in to your free Craigslist account.
2) Go to the Craigslist page for the city you are interested in.
3) Click the JOBS category title.
4) In the JOBS page, make a search with a keyword.
5) Click Email Alert link right next to the search field.
Writing a cause and effect sentence is very commonplace in both fiction and non-fiction works.
Its structure is very simple and straight forward.
There are two basic types of cause and effect sentences:
1) You start with a CAUSE, then connect it to an EFFECT with a CONJUNCTION.
2) You start with an EFFECT, then connect it to a CAUSE with a CONJUNCTION.
An alternative form starts with the CONJUNCTION:
3) You start with a CONJUNCTION, then follow it with a CAUSE, comma, and an EFFECT.
What is a “Conjunction”?
A conjunction is a sentence component that JOINS two clauses, two parts of a sentence.
Although it sounds complicated, actually it’s not since you already know and use dozens of conjunctions in daily life.
For example, every time you use AND you are using a conjunction.
Other examples: OR, NOR, YET, THEREFORE, BECAUSE, SO, WHEN, AFTER, BEFORE, SINCE, etc.
1) Sentences that start with a CAUSE and end with an EFFECT
“He studied hard for the SAT exam [CAUSE] and [CONJUNCTION] got a perfect 800 [EFFECT].”
“They trained hard [CAUSE] but [CONJUNCTION] they still lost the match [EFFECT].”
2) Sentences that start with an EFFECT and end with a CAUSE
“She has been unhappy [EFFECT] since [CONJUNCTION] she was assigned to this case [CAUSE].”
“We chose him [EFFECT] due to [CONJUNCTION] his MBA [CAUSE].”
3) Sentences that start with a CONJUNCTION
“Because [CONJUNCTION] of the severe weather alert [CAUSE], all flights have been cancelled [EFFECT].”
“Now that [CONJUNCTION] you’ve seen the evidence [CAUSE], I’m sure you can write a better report [EFFECT].”
Cause and Effect Paragraph
Writing a cause and effect paragraph is not that hard: you can either start by a cause and then explaining the effects; or the other way around – start with the effect and explain the causes.
Let’s examine these two different types of paragraphs one by one:
1) Paragraphs that start with a CAUSE
Let’s say you start your paragraph with “rising fertility rate in rural villages.” That’s a CAUSE.
What would be the effects? Let’s mention three:
Falling living standards (if agricultural productivity remains the same).
Thus eventually a migration to cities.
Importance of Assumptions
Here as you can see the crucial component is the ASSUMPTION that agricultural productivity will remain the same. This is important because if the productivity goes up it can support a growing population and thus there won’t be any urban migration.
You start with a TOPIC SENTENCE which describes the CAUSE. Then you continue by listing the EFFECTS. Important thing is to make clear what your ASSUMPTIONS are including in your reasoning and mentioned very clearly.
“Fertility rate has risen 7% in Western XYZ between 1990-2010 [THE CAUSE].
One effect of this would be increased pressure on food resources, if we assume that the agricultural productivity remains the same [THE ASSUMPTION].
A second and related effect would be dropping standard of living in Western XYZ.
We should expect this to lead to an eventual migration to the cities in the region like La Capital [THE EFFECT].”
2) Paragraphs that start with an EFFECT
You start with a TOPIC SENTENCE which describes the EFFECT. Then you continue by listing the CAUSES. Important thing again is to make clear what your ASSUMPTIONS are.
“Those with a college degree are shown to earn a million dollars more over a lifetime than those who do not go to college at all [THE EFFECT].
One reason why this is so is the higher paying jobs available to college graduates [CAUSE 1].
Another reason is college graduates are more comfortable with high-technology which helps them start high-profit businesses [CAUSE 2].
Of course, we are here assuming that the two groups (college and non-college) start off their adult lives more or less from the similar socioeconomic backgrounds.”
As you can see, even though there is a structure to the way a cause-paragraph is written [TOPIC SENTENCE first, followed by supporting effect or cause sentences], there are no standard phrases or keywords that you need to use while writing them.
As a writer you should use your creativity and come up with the correct style to stitch together the cause and effect elements together as shown in the above examples.
XML-based structured authoring has been one of the hottest topics in the technical writing community for quite a while. Shifting from traditional documentation to “structured documentation” has been the “holy grail” of top-echelon technical communicators for the good part of the last decade. In one survey reported by Scott Abel of The Content Wrangler, for example, 44% of the companies surveyed said they were using XML-based structured authoring. That’s an impressive number indeed.
Yet, as I can tell you from my own personal experience as a Fortune 100 technical writer, the transition is not always smooth and easy. Even though they are usually touted as the next best thing after sliced bread, structured authoring and platforms like DITA (Darwin Information Typing Architecture) have their own disadvantages and hurdles as well.
Here are five of them.
The most serious obstacle standing in the way of converting to structured authoring is this: perhaps you do not have a real need, a good business case why you should convert. Ask yourself: will your documents be read by customers in different countries talking different languages? Will the content of your documents be published in many different formats like PDF, HTML, digital content on mobile phones and pads, and even in publicly accessible kiosks? Will they be updated regularly or frequently? Will you reuse the same modular content in different combinations to create different deliverables? You need to give a strong “Yes!” answer to these questions to justify the conversion.
The transition takes a serious commitment of resources. You need to purchase not only a reliable, robust and scalable CMS (Content Management System) but also hire the correct SMEs (Subject Matter Experts) to lead and manage the transition. We are talking about an investment of not hundreds or thousands of dollars, but easily of tens of thousands of dollars, either paid upfront or budgeted monthly. In some cases the total cost can climb up to well over six figures. When they hear the real numbers, most small and medium businesses have a change of heart and decide that perhaps they should “wait a little more” before taking the plunge.
Structured authoring requires cleaning up the legacy files. DITA expert JoAnn Hackos of ComTech suggests four kinds of decisions that documentation managers need to make: 1) What to convert, 2) What to reuse, 3) What to rewrite, and 4) What to leave behind (see https://www.youtube.com/watch?v=x8lTRxzh7b0).
To get the management agree on all these four questions is a monumental task in itself since it can get political easily. Managers protect their own turfs and area of operation. Getting rid of certain documents, rewriting others, or changing their mode and scope of distribution affect their own decision making autonomy directly. So it sometimes becomes an inter-departmental battle to decide what to do with the legacy documents. That in itself may delay the conversion significantly as well.
Structured Authoring has a steep learning curve. Training not only takes time but money as well. You need to have a team of technical writers willing to make the transition by learning new tricks and devoting themselves to the conversion. When the team leader or one of the writers support the decision but the others don’t, team spirit and productivity suffer. Some writers love the way they traditionally do their job and they are threatened by this “new hi-tech mumbo jumbo.” It’s totally out of their comfort zone; and so they resist the process.
Thus even when the management commits the appropriate resources, internal staff conflict can make the transition a most unpleasant experience indeed.
Even if you answered all the above concerns satisfactorily, you’ll still need to structure the conversion, as all structured authoring experts agree. And by “to structure” this is what they mean: you cannot one day just start slapping XML tags to document components and think you’re converting them into “structured documents.” The conversion needs a much more comprehensive effort than that.
You first of all need a “Content Strategy.” You need to know where you are heading; how you will assure quality; how you will distribute the new content; how you will measure the results; etc.
After that, you need a “Content Model,” that is, which XML-based conversion platform are you going to use? Will it be DITA, one of the widely-adopted platforms, or another like DocBook, S1000D, TEI, SPFE, Markdown, or a totally custom-made platform with specific XML components for your niche?
Following that you’ll need a Pilot Study to test the limits and outcomes of the conversion. If your legacy documents have a lot of visual elements embedded into highly-designed page layouts, for example, the structured outcome may not be what you were expecting. This may give you an opportunity to tweak your style sheets and redesign your templates. During the pilot phase you may also find out that you have difficulty with some of the output formats. This is the time to correct such errors or find workaround solutions. Once the pilot project starts to generate the kind of outputs you are pleased with you can go into full production and scale up your production.
Do your homework and ask all the above questions before making a commitment to structured authoring.
This is a long-term conversion project that requires significant investment of time, money, and human capital. It’s better to stay on the sidelines and watch where this particular documentation niche is going than investing heavily because “it’s the new sexy trend to follow” and suffer in the end.
I have been working with XML since it was a glimmer in the eye of Jon Bosak. In fact, before XML was conceived, there was SGML; going from SGML to XML represented a streamlining for the web, but at its core there was not much functional difference; in fact XML is a subset of SGML. The key concept of semantic markup is central to the core value of SGML/XML.
The two main perspectives I have seen are Document-centric XML and Data-centric XML. SGML initially appeared in support of document-centric work: managing all the technical documents or contracts of IBM or Boeing, for example. Charles Goldfarb has maintained that “SGML literally makes the infrastructure of modern society possible” and I think he’s right – hmm, should we blame him for the lengths to which humans have gone to destroy the earth?
The document-centric XML world is really a direct continuation of SGML. When XML came out as a standard in 1998, those of us working with document-centric XML became giddy with excitement, anticipating that the standards being proposed at the time (notably XML itself, XLink, XML Schema, RDF, XSL and pre-cursors to SVG) would finally facilitate tools that made publishing work for organizations that weren’t quite as big as IBM or the Department of Defense. The vision of a semantic web and ubiquitous XML multi-channel publishing, seemed to be growing a foundation in theories gaining critical mass, with apparent support of software companies. It appeared these vendors might actually adopt the standards of the committees they were sitting on. “Throw away Xyvision!” I told my boss at Bertelsmann, “this XSL-FO will completely revolutionize database publishing!”
We were sorely disappointed over the next five years. In the years before 1998 W3C standards seemed magical; concepts from the standards were implemented relatively quickly, without perfection but with steady progress: browser updates would reflect CSS and HTML advances; even Microsoft was shamed into some level of compliance. But the monopolistic tendencies of those on the standards committees, coupled with the academic approach of some of the standards committees, managed to make it less and less likely that a given standard would find a functional implementation.
And there was that other perspective – the data-centric side of things. For many reasons, XML was at the right place at the right time in terms of data management and information exchange. In fact, the very year that XML became a standard, it also became the dominant way that machines (servers) talked to each other around the world. Highly convenient for exchanging info, as firewalls would tend to block anything but text over http, while XML markup would allow any sort of specification for data structures, and validation tools would ensure no info was lost.
In 1998, when you asked a programming candidate “what do you know about XML?” only the document-centric people would know anything. By 2000, everyone doing any serious programming “knew” about XML. Trouble was, they typically knew about “XML” only in the much easier-to-use, irrelevant-to-publishing, sense.
And the standards now had to accommodate two crowds. The work of the W3C XML Schema Working Group, in particular, showed the disconnect. Should a schema be easily human readable? What was the primary purpose of Schema? Goals were not shared by the document- and data-centric sides, and data-centric won out, as they have tended to dominate the XML space ever since that time. RELAX NG came about as an alternative, and if you contrast RELAX NG with W3C Schema, you will see the contrast between the power of a few brilliant individuals aligned in purity of purpose and the impotence of a committee with questionable motives and conflicting goals. Concurrent with a decline in the altruism of committee participants was the huge advance of data-centric XML and the disproportionate representation of that perspective.
Ten years later, we find in the document-centric world that toolsets related to XML in a data sense – parsing, transforming, exchanging info – have made great leaps forward, but we are in many ways still stuck in the 1990s in terms of core authoring and publishing technologies. It is telling that descendants of the three great SGML authoring tools as of 1995 – FrameMaker+SGML, Arbortext Epic, and SoftQuad’s Author/Editor, are, lo and behold, the leading three XML authoring tools in 2009.
There have been some slow-paced advances in document-centric XML standards and tool chains as well, especially the single bright light out there for us, Darwin Information Typing Architecture (DITA) which came out of IBM like XML itself. Yet standards for rendition, XSL-FO and SVG especially, have not advanced along with core proprietary rendition technologies such as InDesign, Flash, or Silverlight, though all of these enjoy nicely copied underpinnings pillaged from the standards. More important, nothing has stepped in to replace the three core authoring tools: the “XML support” of Microsoft Word and Adobe InDesign, for example, do not approach the capabilities of a true XML authoring application. There are a proliferation of XML “editors” but most of the new ones are appropriate for editing a WSDL file or an XML message (the data-centric forms of XML), not a full-fledged document.
Meanwhile, on the data-centric front, XML has simply permeated every aspect of computing. There are XML data types in database systems, XML features in most programming languages, XML configuration files at the heart of most applications, and XML-based Web Services available in countless flavors.
Document-centric XML is simply a deep challenge that will take more time (and probably more of a commercial incentive) to tackle. For the time being, structured authoring managed the XML way is still implemented mainly by very large organizations: such an approach has “trickled down” from organizations the size of IBM to organizations the size of Adobe (which does, in fact, use DITA now), but there are not tool chains yet available that will bring it down much further. The failure of the W3C XML Schema Working Group to provide a functional specification supporting document-centric XML can hardly be underestimated.
As long as content is not easily authored in a semantically rich, structured fashion, the vision of the semantic web will remain an illusion. When and if document-centric XML gets more attention from standards bodies and software vendors, human communications will become far more efficient and effective.
Max Dunn has been programming typographical output for over 15 years. In 2000, after 4 years directing programming at Bertelsmann Industry Services, Max founded Silicon Publishing, a development company specializing in document generation and dynamic web site automation.
A full-fledged doctoral program that focuses exclusively on technical writing and communication is still a rare bird out in the market today.
Here are the top 3 Doctor of Philosophy (Ph.D.) programs in the United States on technical communication – the highest academic degree you can get as a technical writer and communicator.
1) Illinois Institute of Technology
Name of the degree: “Ph.D. in Technology and Humanities” (used to be called “Ph.D. in Technical Communication”)
This is not a practical hands-on program that prepares technical writers for the real world of technical writing out there. However, if you’d like to be an academic and do research and teaching in a university setting in the field of technical communication then this might be what you are looking for. It is a 72-hour program beyond the bachelor’s degree. Students who have earned a master’s degree in a relevant field may transfer up to 30 credit hours.
Is is easy in Excel to calculate the number of working days between two dates. Most, but not all businesses, operations or project activities and progress happen during weekdays. So, if you need to report and calculate the number of days that have elapsed between a start date and an end date of a project or project milestone for example then counting weekends in the calculation is not what you want to do, and you will need to avoid those days in your calculations. It is easy to do in Excel with the NETWORKDAYS function.
The formula NETWORKDAYS is pretty straightforward and has two required arguments or parts to it.
The syntax of the formula is
So, an example always helps when working through Excel formulas.
Below is the start date and end date of a short project. Start Date is in cell C4 and End Date is in D4.
The formula calculates the number of workdays (excluding Saturdays and Sundays which is the default), in this example it is 64 days.
So, this is a straightforward calculation automatically excluding Saturdays and Sundays, but some projects could and do include Saturdays, Sundays or even both.
Well of course Excel can handle this. In this instance we can use the NETWORKDAYS.INTL function.
The difference with this formula this is that it includes an extra argument or part, a weekend code, which allows us to specify which days to exclude as a weekend day or days. The syntax of this formula is
Let’s apply the same formula- but let’s assume we know our project work was active on Saturdays also. So, we need to ensure exclude any Saturdays from the calculation of days worked on our project
So, we need to select option 17 which is Saturday only. You can choose any of the options of 1 to 17 from the drop down menu. This now increases our work days to 77 days in the period 01/01/2015 to 31/03/2015 as Saturdays are now included as normal working days and should increase the number of days worked on our project. The number of days between the two dates now increases to 77 workdays.
The NEWTWORKDAYS and NETWORKDAYS.INTL are a useful couple of Functions to have in your Excel Tool Kit.
BJ Johnston has been an advanced Excel user for 15 years and is the creator of http://www.howtoexcelatexcel.com a site that shares Excel tips and tricks with it’s enthusiastic members.
1) BUSINESS and TECHNICAL WRITERS assigned to write a proposal in response to an RFP. There is plenty in here to guide a writer from start to finish, including a detailed description of every component that a good proposal needs to have.
2) PROJECT MANAGERS whose jobs are much harder since not only they need to hire and direct the RFP writers, but they also must first evaluate if the RFP is actually the right one. If that research yields a positive result, then they need to shoulder the even more ardous task of putting together an RFP project team and driving the delicate process to its very end. This ebook also has chapters exclusively written for such project managers.
The main chapters are:
1) Introduction and Terminology
2) Six Set-Aside Programs (for small businesses)
3) Subcontracting facts
4) GSA Schedules
5) Focus on Selected Agencies and Resources
6) First Things First – the things you need to do to start the process
7) Questions to ask BEFORE you start to write your proposal
8) Questions to ask BEFORE you start to send out your proposal
9) Parts of the proposal
10) 5W + H Reality Check
11) Watch Out for the “Fishing Expeditions”
12) Step-by-Step Reply Process for RFP Managers
13) RESOURCES: U.S. Federal Procurement Web Sites (69 web sites)
14) RESOURCES: U.S. State & Local Procurement Web Sites (71 web sites)
Chapter 13 is a unique chapter: it describes a step-by-step development process for the proposal management team, starting with the assignment of responsibilities and selection of work teams all the way to writing the final draft and bringing the project to a successful conclusion.
The updated and alphabetized list of 140 federal and state procurement web sites in the resource chapters alone is worth the modest price of this comrehensive guide.
Those two chapters alone can save you untold hours of searching for the appropriate resources. Knowing where those web sites are important to find the right RFP or project bid. Now you have them all under your finger tips in two convenient lists.
“Proposal Planning and Writing for RFPs” is recommended for all business teams, project managers, business and technical writers, and all those who would like to get their share from the annual $500 billion U.S. federal procurement pie.
If you have access to Microsoft Excel or a similar program, you can use it to simplify your life with these handy templates. These templates work in Excel and many of them work in the Open Office Calc program. There are many to choose from but here are the top 7 Excel templates that will simplify your finances and planning activities on a daily basis.
1. Monthly Calendar Template: You’ll never have to buy an expensive calendar again with this template. You can create professional looking calendars for every month out of the year. You can type in important events before you print off the pages. You can also customize the calendar to make Monday the first day of the week.
2. To-Do List Template: If you’re like most people, you have a growing to do list that needs your attention. Instead of writing your tasks down in several different places, you can stay organized with the To Do List template. The template is customizable and is very simple to use. You can type in tasks before printing or write them in later. You can even categorize your tasks to simplify your life.
3. Printable Grocery List: Shopping for groceries is made simple with this template to keep you organized. You can classify your purchases by sections of the grocery store so you won’t have to walk all the way across the store to get the one item you forgot. The template pack also includes a general shopping list, which is helpful during the holiday season.
4. Personal Budget Template: These days it seems like everyone is interested in saving money. If you need to budget your monthly income, this personal budget spreadsheet can make the process easy. This template helps you make a budget for the entire year. You can use the suggested spending categories or create your own so that it totally suits your needs.
5. Expense Tracking Sheet: Once you’ve built a budget, you need to keep track of how much you are spending. This can be made easier by using the Expense Tracking Sheet. It works similar to a checkbook register, but you can use different columns for separate expenses. You can use this template for expenses in any category. It is also helpful if you are doing a major remodeling project, own a small business or want to see where your money is going.
6. Debt Reduction Snowball Calculator: Reducing debt is a worthy goal and it can be made much easier with this spreadsheet template. There are many different ways that you can organize paying off your debt. This amortization calculator and debt spreadsheet allows you to try many different methods, including the debt snowball method, to see which one works best for your expenses. Once you play around with the different methods, you can put your plan into action.
7. Daily Food Log: Whether you’re trying to lose weight or you’re just on a special diet, this template can come in handy. The printable template comes with three complete days on one sheet. You can write your meals and food items on separate lines and then track calories, fat grams or food groups.
These seven templates just scratch the surface of what is possible with a spreadsheet program. By downloading these templates, you’ll be on your way to having a more organized and simplified life. Do a search on Google for them today and start simplifying your life tomorrow.
Simplify your life with one of dozens of custom Excel templates from Vertex42.com.
Adobe FrameMaker 2015 has been released this month (June 2015) and I’m really pleased with some of the new features they packed into this new version.
My most favorite new feature is mini-TOC which I know I’ll be using during my daily work. I’m grateful for it.
No one has any idea about the untold hours I’ve spent in the past constructing these chapter-specific mini-TOCs.
Such mini-TOCs are a must when you have chapters in a book as long as mini-books. When you have a 100-page long chapter, for example, with 20 or 30 sections in it, to have a TOC in the beginning of the chapter is a really user-friendly feature.
But until now the only way to construct such a mini-TOC was to cross-reference each and every section heading and section page number by using a table, a user-define mini-TOC paragraph tag created just for that purpose, and generating each link one by one – a very time-consuming affair.
But in FrameMaker 2015 you can create such mini-TOCs automatically and update and maintain them automatically as well.