Welcome to my personal web page. As you can tell, this is really the page upon which I park my resume. My real website activity takes place elsewhere: I am the webmaster for http://www.word.mvps.org
However, if you look at as many web pages in a day as I do, perhaps you will appreciate a webpage that is very simple and so loads extremely quickly?
To download, click
Resume.
Contacts:
By Post: |
Unit 1407, 83-85 Spring Street, Bondi Junction, Sydney, Australia 2022 |
By Email: |
mailto:john@mcghie.name |
By Phone: |
+61 4 1209 1410 |
So: What is it that I do? John McGhie is the principal of McGhie Information Engineering Pty Ltd, a privately-held Australian company specializing in documentation engineering.
Documentation engineering begins with the premise that "Documentation that serves your needs is a piece of engineering, not a work of art" – which just happens to be my company slogan. That's what we really do: We analyse what you want people to be able to do after reading your documentation and we analyse what they already know. Then we design a suite of communications resources to bridge the gap.
Documentation engineering is normally practiced by a team of five or six people, including the documentation engineer, one or more subject matter experts, a business analyst, a project manager, an editor and a production editor. Projects typically run one or two years and of course the budget can be substantial. Projects such as this are best suited to "clean-sheet" design situations where the customer needs to establish an entire library of documentation for a new product or company. The key to successful, standards-compliant and economical documentation throughout the entire documentation lifecycle is the strategic planning that occurs before the first word is written.
Business analysis is a key component of documentation engineering. It is the formal process of analysing needs and specifying requirements. There is abundant evidence to prove that the really expensive mistakes happen through inadequate business analysis. "Any fool can make a mistake; a real disaster requires an entire project team (and a database)." The three immutable truths of business analysis: users do not know what they need, businesses do not know what they want, and developers don't know what you mean. It is more difficult to prove that the real successes come from good business analysis, but you may wish to bear in mind that "If we are not planning to succeed, we have already planned to fail."
Once the strategic planning and design on a project has been done, producing documentation becomes a much simpler process. Technical writing is the process of collecting and structuring information, and rendering it in multiple output formats for dissemination: including paper, web sites, help files and XML knowledge bases. Technical writing is still engineering, but typically creates or updates the literature for only one product.
Writing the responses to requests for proposals is a specialised area of documentation engineering. Producing a substantial response tends to quickly sort the players from the stayers in our industry. Most technical writers can successfully produce a 2,500-page document, given sufficient time and resources and a relaxed quality requirement. People who can successfully manage a 2,500-page RFP project to survive the rigours of a government bid assessment panel with three months to deliver are much less common. There are very few who can do it well enough to win $500,000,000 worth of business! Yes, I know: luck and politics are important attributes in such a project, but customers who may well be betting the financial survival of their company on the outcome tend to be very risk-averse! Large-scale documentation required in very short timeframes really finds out whether the project team knows what it is doing with its project management, requirements specification, traceability and production engineering. Delivery day is not a good time to discover that your production database is corrupted.
1997-2008Microsoft says that Word is easy to use and extremely powerful. Both statements are true. Unfortunately, many people discover a week out from their absolute deadline that they are two separate statements. Large scale documentation is not "simple". The knowledge base of an average corporation is far more complex than its computer system, and the management of it is an undertaking on a much larger scale. It's really a bit like flying a 747: easy if you know how. If you don't happen to have a pilot's license handy, we'll send you someone who has.
The term macro is much-abused in the industry these days. It was really coined to describe a small re-useable routine an end-user could create in a few seconds to automate a repetitive task. The power and programmability of Microsoft Word has closely observed Moore's Law: a Microsoft Word "macro" these days is often several thousand lines of object-oriented structured programming that offers very substantial return on investment. Or it's a business liability your contingency planner would be interested in. If you would like one of the former kind, give us a call!
Contingency planning, often termed business continuity planning, is a branch of business analysis. A wise man once said "The essential secret of business is to stay in business." Business continuity planning is the discipline of working out (ahead of time!) how you will conduct business when things go wrong. The Sarbanes-Oxley act now brings the very real prospect of unpleasant personal consequences for the directors of companies who display inadequate diligence in their corporate governance. One of the things shareholders expect boards to be diligent about is business continuity planning. There's evidence to suggest that a major company these days is unlikely to survive financially if its core computer system is down for longer than three days. "We're all right," I hear you say "We have a backup system and a diesel generator -- what could go wrong to take the computer down for three days?" A broken water main. I'm kidding you, right? Wrong: No water means no cooling towers. No cooling towers means no air conditioners. No air conditioners means no computers. No computers means no business. And the Sarbanes-Oxley Act means the CEO gets to sit in a jail cell for up to 20 years. While turning over in your mind the new and interesting friends you would spend your evenings with in a jail cell, maybe you would like to give your building engineer a call on Monday and ask just how long your building could operate without water!
