The difference between Policies, Standards, Procedures and Strategies

Over the years I have written many policies, processes. strategies and standards and related documents.  These documents outline how a business operates and help when a team member requires a reference. so to answer a question: what is the difference between policies standards procedures and strategies?

The agony point for me is when a professional consultant does not know the differences between the document types and refers to one as another, the other as another and cannot grip the function of a specific document. In the meantime, steam billows from my ears while the consultant continues to sprout opinions on the various documents.

For the uninitiated here is my explanation of the difference between Policies, Standards, Procedures, Standards and related documents.

Policy document?

A policy sets out an agreed management policy which might refer to IT Security and Risks. However, it will not give any direction on how to execute this vision or strategy.

A set of policies are principles, rules, and guidelines formulated or adopted by a Business to reach its long-term goals. Policies are signed off by management and published in the Company’s preferred medium.

The writing of Policies is to influence and determine major decisions.

Processes and Procedures are the specific methods used to express policies in action in the daily operations of the Business.

What is a Process

It is a task, a procedure – it is NOT a Plan.

The ISO definition of a process is:

A process is a set of inter-related activities that turn inputs into outputs’

You MUST learn the process; know WHY you need it and How to perform the process end-2-end.

  • Process a high-level description of a series of inter-related tasks covering an entire business.
  • It is an internal, ongoing process that must be updated as per Policy guidelines
  • serves as a crucial guide for employees and managers.

Procedure 

A procedure contains more detail than a process but less detail than a work instruction. It tells users HOW to perform a series of sequential tasks to achieve a specific outcome.

Participants will complete a procedure from start to finish in one continuous time frame (no significant delays between steps).

Work Instructions (WI)

A WI contains a detailed description of a task. Its sole purpose is to explain step by step how to do a specific task.

Plan

IT IS NOT a Process

      • Organisations have Management Plans which outline WHAT you are going to do, it does not explain HOW you will perform a task.
      • The Plan determines precisely how resources are to be allocated and provides backup plans if resources are not available at a crucial time.
      • The Plan document outlines what components must be included to demonstrate How a process will work.
      • A plan is how you will move from A to B and should support your strategy by providing a method to reach B containing an acceptable balance of risk and reward

What is strategy?

A strategy document explains the strategy – how an organisation will move from point A to Point B

      1. How will you get there?
      2. Issues, problems
      3. Solutions and tools to get you to point B

A strategy is a solution to move from A to B taking into account any unforeseen issues and problems that may occur to slow your journey to B.

Your strategy is WHAT you want to do

Understanding the difference between a strategy and a plan allows you to make useful strategic planning decisions that separate the two.

What is the standard?

Standards are mandatory actions or rules that give formal policies support and direction. One of the more difficult parts of writing standards is getting a company-wide consensus on what standards need to be in place. This can be a time-consuming process but is vital to the success of your information security program.

      • Used to indicate expected user behaviour. For example, a consistent company email signature.
      • Might specify what hardware and software solutions are available and supported.
      • Compulsory and must be enforced to be effective. (This also applies to policies!)

Content and Documents | How Can I help you?

During this pandemic, were you in the process of hiring a technical writer to help with your content and document requirements? To support the work already completed were you were on the brink of hiring a technical writer.

When it comes to the documentation, I would advise you NOT to delay even now and start any discovery phase to identify which titles you need to prepare.

How can I make your project run with ease?

I have a vast collection of generic documentation covering PCI, ISO27001, GDPR, ITIL. Operating Document templates for migrations of hardware and also useful for audits. Hence, with some tweaks and by understanding your requirements, my generic documentation can be tweaked to suit your company’s needs which will save time and money.

Compliance projects

Compliance projects tend to generate more documentation than managers expect. If you have not already performed a discovery or due diligence phase, you could have up to 60 titles to write ranked in order of importance.

  • Payment Cards Industry (PCI)
  • ISO27001
  • ITIL and ITSM Policy and process documentation

Confluence and SharePoint

Do you use either confluence or SharePoint, or both?

Have you lost control of the content/documentation?

Has the structure in Confluence been overridden by numerous spaces that are no longer valid, filled with legacy content and no ownership?

Poorly written content and documents can hamper productivity and lead to mistakes. You may need an expert eye to look over your Content and documents and identify what is no longer needed and seek to slim down or bin the information contained in either.

Transformation

Are you about to start a transformation project and have discovered the documentation has no value? Stress not. With help from SME’s and a series of interviews, the documentation will soon be underway. I wrote a booklet on such projects. You might want to read it. To help start the technical documentation, I have the following templates:

      • Operating templates
      • Installation guides
      • Profile document
      • Technical procedures for management

Disaster Recovery and Business Continuity

I have a collection of templates that can help get a plan up and running after consulting with your staff.

Call Me 07534 222517

Email: [email protected]

Technical Writing | Hire a Technical Writer sooner, rather than later

As a Technical Writer with over Twenty Years of experience, I have a question for Project Managers and Subject Matter Experts. Have you ever been involved in planning a project (PCI, GDPR, ISO27001, ITIL) where documentation is critical; if so, how did it go? Crucially, did the project achieve its aims of delivering ALL the documentation? If not – do you know why the plan failed? It could be that you were unable to hire Hire a Technical Writer for advice and guidance.

Why Hire a Technical Writer?

A collective failure of technical / process documentation projects is the lack of knowledge and expertise during the planning and discovery phases. Many project managers and Subject Matter experts fail to grasp the reality of a documentation project. Many projects fail miserably because the planners do not understand the lifecycle of a document. From the initial draft through various reviews and sign-off takes much longer than expected. I regret to say I have met PMs and Consultants that do NOT know the difference between a written process a documented plan and the purpose of the policy. If that is the case, your project could be in trouble.

How long to write a document?

If you ask a Technical Writer how long will it take to write one document, their reply will be – “I do not know”. Technical and Process documentation depending on the project (PCI, GDPR, Operations, ITIL) will have many different requirements and factors which delay the information gathering, the writing and review stages before sign-off.

The likely reality of writing a 30-page document containing:

  • VISIOs (3 or more) comprising between 10 to 30 steps
  • Process narratives (3 or more) of between 10 to 30 steps
  • Appendixes (2 or more)

Will amount to – give or take – at least 8 – 12 weeks of effort before it gets to the review stage. However, the more content the document contains and the more complicated it becomes, the longer it will take.

My advice is not to plan such a project without professional help.

If you are wondering why it takes so long – it is worth noting that compliance projects such as PCI and GDPR generate a lot of documentation. TWs working on large projects could be managing a list of more than twenty documents and every document regarding size and content could be very different.

Hire a Technical Writer

My first word of advice is this – If you have such a plan on the horizon, where the Technical / Process documentation is the primary focus – hire a Technical Writer, not a Business Analyst, to give guidance from the start of the project, NOT when the end date is in sight. The TW can highlight issues, risks and bottlenecks. You will also know what you can reasonably expect to achieve within the allocated time assigned to the project.

The Technical writers will need:

  • a week (at least) to assimilate the project
  • Time for training on any tools
  • access to Subject Matter Experts (SMEs)

Add in contingencies for illnesses, holidays and unplanned absences due to personal reasons and the fact a TW could resign from the project at some point

If the budget and the timelines become fixed (in stone) with multiple documents to complete in a short period, then, consider producing Quality, rather than Quantity.

To ensure quality prioritise, or rank the documents to avoid inconsistency across the documentation set:

  1. Required
  2. Nice to have
  3. Not important

Or use The MoSCoW method.

    • M – Must have this requirement to meet the business needs
    • S – Should have this requirement if possible, but project success does not rely on it
    • C – Could have this requirement if it does not affect anything else on the project
  • W – Would like to have this requirement later, but delivery won’t be this time

Documentation

Who will use them?

  • Documents for external and internal users will require a different level of language
  • What level of information and detail will the audience expect?
  • Does the document need VISIOs?

Additional Points

  • Travel: Will the TWs need to travel abroad or Nationally, if Yes, are they available to go and do they have current Passports/Visas?
  • References: Identify any useable archived documentation.
  • Reviews: decide who will review and who will sign off a document
  • Scope: Could there be any changes which will add to, or change the scope of the project

In summary,

Documentation projects fail due to:

  • poor planning
  • the lack of experience and
  • not allowing enough time to complete the documentation.

Finally: If the success of the project depends on the documentation (Disaster Recovery Plan, PCI/DSS, BCP and ITIL) – why do PMs and SMEs allocate so much of the budget to non-documentation resources?