Background
When setting up business or project plans I always had a concern in my head: “Am I forgetting something”? “Is there going to be a topic I should have identified in my project but is not covered at the end, forcing me to postpone my deadline?” Or in some cases worse: “Is there something that I have not included in my budget”? Over the years I have developed a checklist which worked quite well, and each topic results in a document. The title of this blog focuses on the documents, which are the measurable results or ‘deliverables’ of this overview. (That this way the title sounds much more sexy than ‘checklist’ is only a collateral advantage, of course.) Not remarkably, this applies to both in-house departmental plans as to outsourced activities, the only substantial difference being the contract between client and provider and the (form of the) financial remuneration.
When entering the (business) world, a person has her personal values. There might be exceptions to the rule (the writer has his values standing framed in the window sill) but most people I have met do not have these documented. Still, they exist and are the basis of our actions. If my client – or employer – asks me to do something against those values I have no other alternative but to refuse – or resign. For me this is the highest level of expectations one can have, phase 0, like a project always needs to have a ‘Governance’ or ‘Project Management’-component how to ‘’Control’ the project. One famous example in this arena is the contact between Mark Felt and Woodward & Bernstein, which brought to light the Watergate scandal.
After that, we see an interrelationship between various topics which I will depict below and explain afterwards.
We have a ‘C’
Our interactions with other individuals are primarily guided by Culture. The very first thing to establish is (tacit) agreements on human interaction itself: do we shake hands when seeing one for the first time during a day, do men wear ties? This Culture is most visibly documented in the laws of the judicial system we agree to rule our interaction, this small but very fundamental section in most contracts.
The second set of rules of our interactions is established by the Corporation. My primary interest in business is to protect the interest of my employer. The relationship between myself and my employer is governed by the employment contract we have signed. Secondary documents might be a job description and maybe the values of the corporation (not every company has its values framed in the hallway).
‘Only’ then we get to the Client who has hired the Corporation to execute transactions on it’s behalf. The agreement between those two parties is documented in the (BPO) contract. For in-house departments one could argue that the strategic plan or mission of a Corporation might fulfill the same role. The discussion whether that document is a proper replacement for a contract or not I will leave to others, but I expect most readers will get the gist of the argument.
Sometimes I see that writers put the Customer first. In a sense that is correct, however, if the Customer wants something that either the Culture, Corporation or Client refuse, the service will not be provided. However, in everyday life most of the attention is justifiably given to observation and influencing the behavior of (potential) Customers. What exactly the Corporation is going to provide as a service to these Customers for the Client is documented in the Service Specification, an often undervalued document.
We have a ‘P’
Given the business of the Client, the Corporation will be processing certain Products. Of course, these Products are reflected in the Product Catalog or Price Catalog.
Depending upon the Products sold by the Client, certain Processes should be provided or not: throwaway plastic cutlery is not going to have the same technical support as a software program. These Processes should be documented in Process Flows. Most Clients I have met think their Products or market are incredibly specific or special. And they are. However, the Processes to ‘process’ their product usually are not. Here we get to the main ‘reason d’etre’ of the whole Business Process Outsourcing industry: because certain parties have developed an expertise in the Process-arena – and that expertise can also be to achieve a certain cost level – they can help the Client executing these Processes. The more one ‘masters’ a trade, the more one sees patterns in that trade. Once you see the patterns in the processes, you realize that fundamentally, it does not matter whether you ‘process’ one product or the other.
Depending again upon the Processes executed, one needs to hire the appropriate People, with the right skills and motivation. To assure that, these are written down in Job Descriptions. I am sure most readers will be impressed by the incredible insight of the previous sentence and therefore are prepared for one of the ‘tougher nuts’ to crack in this overview:
When the People are provided with Process Flows, they do not know yet how to execute their tasks, for that they need Procedures. Often, these are confused with Processes, but the difference is that Processes are written independent of systems used, where Procedures document how these specific systems need to be operated. They are then documented in Work Instructions, sometimes referred to as SOP’s (Standard Operating Procedures). Work Instructions often have a copy of the Process included to ‘see the big picture’ or because a visual depiction of a process flow often helps an employee understand what she has to do.
In this context, I use Work Instructions for both the documentation of procedures itself, the training (documents) on how they are explained and any impromptu checklists individuals might have used just because they are’handy’.
We have an ‘S’ and an ‘F’
The various (IT) Systems enable Procedures to be carried out. Though I am definitely not an IT expert these systems are documented in e.g. an IT Systems Design (the current design of systems), the Administrator Manual (how to manage the systems) and a Configuration Overview (where is shown how the systems are being used). In the IT Systems Design one would see e.g. which applications are being used and how these systems are connected, via leased Lines or ‘the cloud’; whereas in a Configuration Overview one might show on which telephone numbers/DDI’s a telephone line would come in, when which voicemail/night message is played, which choices the client are presented in the IVR, and in which order the call is sent to which agent or skill group.
Facilities are an area that is often overlooked, but also the IT-room needs airconditioniong to keep the systems running, and in BPO the Uninterruptible Power Supply (UPS) often is mandatory. Given the variety of fields under Facilities, there is a multitude of documentation covering it. The most prevalent one is of course the floor map, but do not forget the physical security plan and a whole slew of others that go beyond the scope of this blog.
Most professional Clients insist on a Safety Concept, which is reflected in an Emergency Plan or when done extensively, a Business Continuity Management-plan. The Emergency Plan documents what to do in case of a malfunction, incident or emergency. (One could argue whether an IT Support plan belongs here or under IT Systems, but I will not go into that).
The Business Continuity Plan consists of measures before an incident (like a risk identification, risk valuation, and security plans), measures during an incident (the – often overlooked – declaration of an emergency, communication lines and prepared responses or disaster recovery) and measures after an incident (how to return to normalcy, work away any backlogs etc.)
This all results into the financial impact of an activity of course. Finances is our last topic, which is reflected in both the pre-activity Price List (or Budget for in-house) and the past-activity Invoice (one might add Profit & Loss or Cost Overview depending on whether outsourced or in-house). As usual, the search ends up here, or as ‘Deep Throat’ used to say: “Follow the money”.
This leads us to an adjusted picture from where we started: per topic the relevant document has been identified, so the ‘Hierarchy of Documents’ becomes as follows:
(Originally posted on August 10, 2013 Pictures edited November 3, 2016)
Peter Alderliesten's Blog 