Welcome to my personal web page. As you can tell, this is simply 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?
Availability: Available July 2013. Click Resume to download my current resume.
||By Post:|| Unit 38, 24-28 First Ave,
Sydney, Australia 2148
||By Phone:||+61 (0)4 1209 1410|
So: What do I do?
I am 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 information 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 may 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.
My company also offers Technical Writing services. The difference between Documentation Engineering and Technical Writing is largely one of scale.
A Technical Writing project may have only one or two people on a job. 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.
Some of our clients are already resourced for a combination of Research, Analysis, Design, Review, Editing, or Project Management functions. We can supply one or more people to fill in the gaps. Some of our people are experienced working Fly-in, Fly-out on resources projects.
Microsoft says that Word is easy to use and extremely powerful. Both statements are true. Unfortunately, some 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 normally more complex than its computer system, and the management of it is an undertaking on quite a large scale. It's really a bit like flying an A380: easy, if you know how. If you don't happen to have an Air Transport 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 that 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 sometimes several thousand lines of object-oriented structured programming that offers very substantial return on investment. Or it's a business liability that keeps your contingency planner awake at night. If you would like one of the former kind, give us a call!
We now offer commercial Microsoft Excel VBA coding. Our focus is more on data management and manipulation than mathematics.
The key to successfully deploying any automated system is to "make the right way to do the job the easiest way to do it". We believe it is unrealistic to expect busy senior people on a project to learn fiddly procedures for doing things. They simply won't do it, and the project rapidly ends up in a mess! So we create our "management system" as one of the first things we do on a project. And often, we create it in Excel, because it is available and it's powerful enough to do most things we need.
Effectively, we are simply offering one of the "tools we use in our trade" for independent purchase. Documentation Engineering projects tend to be "large". We can all manage five pieces of information on a whiteboard, and if that's all we have to manage, a whiteboard is the best way to do it. A Documentation Engineering project can easily grow to multiple project leaders, perhaps 50 contributors, hundreds of documents and thousands of different pieces of information. We can easily be tracking more than a million possible permutations.
At some point we need some machinery to keep track of what is going on. Obviously Microsoft Project and Microsoft Access are designed for this purpose, and we use them when they are available. If they are not, we do it in Excel, and we can do that for you.
We will also tell you if you are attempting a job that is really too much for Excel. I am aware that some consultants will just sit there happily munching your budget if you ask for a job that is beyond the practical capabilities of Excel. We would rather give you that information so the decision on whether to continue, or look for a better solution, remains in your hands. And we won't accept a job unless we're confident that we can do it well: if your requirements exceed our capabilities we're happy to refer you on to partner companies.
Business analysis is a key component of documentation engineering. It is the formal process of analysing needs and specifying requirements. There is abundant evidence 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 know what they want, but not what they need, businesses know what they need, but not what they want, and developers don't know what either means. It is more difficult to prove that 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."
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 with six weeks to deliver, and survive the rigours of a government bid assessment panel, 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!
Contingency planning, often termed business continuity planning, is a branch of business analysis. A wise man once said "The first 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 after 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?
No. I'm not. 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 ... 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!