Hello world!

To personally examine a portfolio of application development and technical documentation (including artifacts of quality and business analysis), please send an email to or call me at the telephone number provided.

Thanks for your interest.

- Richard

What is the pain? And what is the remedy?

There is a gap between project managers, developers, network administrators, business, systems and quality analysts. Project objectives are hindered by lack of smooth translation of documents and jargons. There are different ways of thinking between these resources.

What if there was a capable resource in the organization who has been in the shoes and worn the hats of all those internal stakeholders in order to bridge the gap between between them?

How common is that?

The central theme of my expertise is comprehensive set of strong, synergistic technical skills in tandem with business experience contributing to the success of projects.
  • Are my professional skills comprised of 25% Business Systems Analyst, 25% Technical Communicator and 50% everything else? No, it's more like 300% total.
  • The point is that such combination of skills is ideal for a business systems analyst or technical communicator role.
  • IT-related work experience as various internal stakeholders comprised of (a) Developer, System Architect and Usability Professional, (b) Quality Analyst consisting not just routine quality assurance but far greater responsibility of implementing corporate-wide Quality Management Systems, (c) Network Administrator, (d) some experience as Trainer again adding to general skill of technical communications, (e) a certain degree of project management experience ideal for Assistant Project Manager role as required.
  • Depth and breadth of these hands-on technical skills allow me to be a better “liaison” or "translator" between various disciplines in a project such that they are nicely bridged. It also applied to "content author" or "deliverer" of technical business information. As someone who has been in their shoes and worn their hats thus with whom they can relate, I am able to assist subject matter experts (SME) and stakeholders with their ideas: articulate (if their ideas are general or high level), clarify (if firm) or (if already solid) enrich them by actively contributing others that may be novel and useful while ensuring all pieces form a contextual, coherent whole. This has allowed me to see the bigger picture to ensure smooth transitions between all phases of SDLC.
  • The following examples are actual, commonly occurring situations which demonstrate why that is important or useful.
Why is comprehensive set of strong, synergistic technical skills in tandem with business experience important or useful? Here are a few examples.
  • Deep understanding of subject matter provided numerous advantages that improved overall efficiency and reduced costs for the organization or project. (a) Better inter-relationship because of similar mindsets and usage of the same jargon. (b) More concretely, I didn't have to elicit content from SMEs; I gathered them independently. That includes, for example, reading code or at a higher level, understanding system architecture whether designed or to be designed. This minimized distracting the SME from their normal work. (c) Even if they don’t mind, there is overhead. It costs essentially twice as much (that of the SME’s and my time). As equivalent to the SME, I was able minimize this. (d) As equivalent to SME but having external perspective, I was able pick up on details while not missing the forest over the trees. Thus my deliverables were easily adapted to a wide range of target audience: the public, business managers and technical users (other Developers for example).
  • High level information from requirements gathering sessions was digested and converted into requirements. Requirements were not only elicited in the sense of paraphrasing those provided by the Domain SME but defined - that is, actively suggesting functional and non-functional requirements. Many supporting skills provided perspective in understanding causal factors and foresee conditions to ensure favorable outcome. For example, experience as Developer, Usability Professional and QA applied during business analysis aided in defining non-functional requirements of usability, reliability, performance, security, compatibility, maintainability and transferability. This was performed in collaboration with many stakeholders including Domain SMEs and Sponsors.
  • When requirements needed to be translated into specifications (in, say, waterfall and iterative-incremental projects) or refined as user stories (agile), I was able to assess coding effort required. For example, what looked easy may be identified early as requiring effort not feasible in present form given budgetary or time constraints whereupon it was then reported to the Project Manager and Lead Developer. Or what was believed to be a “nice to have” may in fact require only a few extra lines of code and a server setting. Thus specifications, high level design or stories were tweaked in consultation with relevant stakeholders to best exploit capabilities of available technology of which I continually keep up to date. I collaborated with the Project Manager, System Architect and Developers to accomplish this.
  • When creating test cases in the context of traceability (requirements tracking), business requirements were organized in order to make validation easy to perform on manageable pieces while ensuring test cases were accountable to all acceptance and evaluation criteria. In agile environments, stories were broken down into smaller ones, elaborated upon or recombined. In the waterfall model, each tier was phrased such that it became the criterion for next in the cascade. For example, any numbered requirement in the business requirements document (BRD) became, at a high level, the first paragraph verbatim in the corresponding software design specification (SDS). In turn, detailed sub-specifications were phrased such that they became the first sentence verbatim in the corresponding test script. The whole process required a clear picture of everything which my method of wording and numbering in the cascading taxonomy tree made all elements easy to track. That is but one example where my Quality Management Systems experience was applied while working with Developers and Testers.
  • Where appropriate, SDS documents were authored using (since they are the target audience) developer-friendly jargons, techniques and tools such as UML, data models, data and process flow. Same held true of scenarios and use cases, functional and non-functional requirements, business rules, gap analysis, root cause analysis and other techniques of business systems analysis for their target audience. This did not necessarily require collaboration with other stakeholders (who really should not be distracted from their primary activities beyond minimal necessary) but employed a technical background that allowed one to independently produce useful, high quality artifacts of analysis, such as documentation and presentations, for consumption by other stakeholders.
  • In summary, each of these examples demonstrates a recurring pattern of clarified, enriched, novel and useful content forming a coherent whole - what a highly capable technical communicator and analyst should do - from the perspective I bring as a result possessing strong, diverse supporting technical skills.
  • How does one go about doing all those marvellous things, especially automated as much as possible? Please contact me so that I can show you how.
The following Questions and Answers reinforce or clarify concepts previously presented.
  • What advantage does your technical perspective confer? My firsthand work experience as various internal stakeholders of an IT project helps in simultaneously understanding various viewpoints and needs. For purposes of bridging various team members, jargons or ways of thinking are better inter-translated. This amplifies, not attenuate, other team members’ contributions as information is passed such that the whole increasingly becomes greater than sum of the parts. Project robustness is further elevated when I am able to add and enrich information content as SME in many technical areas.
  • What advantage does your professional experience confer? As SME in many technical areas, I am able to easily synthesize information provided by large number of people in order to define and validate solutions that rely heavily on IT to meet business needs, goals or objectives. Since skills that make it all possible are continually updated (which is particularly important in rapidly evolving IT) by having the necessary background to do so, I am able to align business needs to optimally exploit capabilities made available by the latest tools if evaluated to be useful.
  • What advantage does your broad industry knowledge confer? When a solid technical background is combined with business acumen acquired over the years in diverse industry types, I am able to bridge the gap between technology and business thus able to determine usable solutions that will have enduring high value and communicate those ideas. Business acumen includes ability to understand the perspective and jargons of external stakeholders, just as it is the case with internal ones. Thus I am someone with whom all stakeholders can relate and ideal as liaison.