Standard Operating Procedure Tips » Process

10 Step Plan For Writing Standard Operating Procedures

admin — Wed, 01 Sep 2010 16:09:49 +0000

This week we start a series of articles on how to write Standard Operating Procedures (also called SOPs). The aim is to introduce the key concepts involved in:

Designing
Writing
Formatting
Testing and
Maintaining Standard Operating Procedures (SOPs)

These tutorials will look at how you can put together a team of writers who can write procedures to an acceptable level so that your company is better organised, both internally and customer-facing.

Is it for experts of beginners?

We’ll start with the fundamentals and then work our way up to more complicated areas. For example, we’ll look at how to get funding for your project, how to write technical writers and how to use naming conventions so that you can find document more easily once they have been archived.

10 Step Plan to Writing Standard Operating Procedures

The process of developing Standard Operating Procedures (SOPs) involves ten steps.

The approach we will use is to assume that you are starting from scratch and want to develop your SOPs in a structured manner. This means that along with writing the SOPs, you will also have them written in a way that allows others to find them, update them and share them where necessary.

Organise the Procedure Writing Team
Get Support from Management
Define Team Procedures, Templates and Style Guides
Information Gathering Phase
Examine As-Is Processes
Explore To Be Processes
Write the Standard Operating Procedures
Test the Standard Operating Procedures
Sign-Off the Standard Operating Procedures
Release the SOPs
Maintain the SOPs

How about Style Guides and Templates?

We will also look at how to setup style guide, templates, and adopt naming conventions for all procedures.

What else will the course include?

Some of the other topics will include:

Role and Function of SOPs
How to conduct a Needs Assessment
How to implement SOPs
How to Evaluate SOPs
How to create SOP templates
How to format SOPs, Process, and Flowcharts
How to define a SOP

At the end of the course, we’ll share some free sample SOPs and other resources that will help you write your procedures.

That’s it for now.

From tomorrow, we will begin to walk you through the entire process and look at each step involved in creating your procedures.

If there is something that you’d like us to clarify or expand upon then please share it in the comments section below.

See you then.

PS – you may want to add this site to your RSS reader or subscribe to the Newsletter. That way you’ll get all the blog posts to your inbox and won’t miss any tutorials.

Business Process Design Tutorial # 1: Why, What & How?

admin — Thu, 12 Aug 2010 10:39:00 +0000

At the end of the workshop, our client confessed, ‘I didn’t know our business worked like that’.

We’d come onsite and over three months mapped out the processes in his Finance, Sales and Operations Depts. For me, one of the most rewarding aspects of Business Analysis is discovering how a business works and then mapping it out in Visio.

Business Process Template – MS Word

Definition: What is a Business Process?

We write the process narratives in Word. In simple terms, business process design is a way of gathering related, structured activities (tasks) that serve a particular goal, usually for customer though it can also be for an IT system. The best way I’ve found to capture the business process is in flowcharts, which show the sequence of activities and where each task inter-relates.

I’ve learnt so much how business models work by taking a business apart, process by process, and seeing where it’s working best and where it needs some fine-tuning.

One definition of a business process is that it’s a ‘set of coordinated tasks and activities that will lead to accomplishing a specific organizational goal’ TechTarget’s Definition of Business Process. In addition, business process management (BPM) is a systematic approach to improving those processes.
The Business Process Management Initiative (BPMI) promotes the standardization of common business processes, as a means of furthering e-business and business-to-business (B2B) development. To realize end, it developed the Business Process Modeling Language (BPML), an Extensible Markup Language (XML)-based meta-language for modeling business processes.
A business process diagram let’s you illustrate activities that are designed to produce specific outputs. For example, if you worked for a bank, you might have a Credit Card application process.That shows what the customer needs to give in, what happens when the application is received, and what results are expected. The customer gets a new credit card or is rejected. You need to design processes for each these scenarios.

Visio Business Process templates

Business Process Example

Let’s look at an example of creating a process flow diagram for a Credit Card application. Like we said, business processes show how to capture (record) the order in which activities occur.

For example.

Customer applies for credit card on the bank site
Or
Customer applies for credit card in the branch
Or
Customer applies for credit card at promotional event
Then
The credit card application is received electronically, but the email is wrong (separate process flow)
The credit card application is received at main office, but address is missing (separate process flow)
The credit card application is received at branch office who send it to head office (separate process flow) Then
The customer gets a new credit card in the post
The customer is offered a new credit card but has to come into the branch (with ID) to pick it up
The customer is offered a new credit card but it send to the wrong address (printing error)
Or
The customer is rejected online.
The customer is rejected at branch.
The customer is rejected at sub-branch.

All of these scenarios need to be mapped correctly and, if necessary, form part of a new process. For example, the credit card rejection process. As a Business Analyst, you need to design business processes for each these scenarios.

Business Process Analysis

A process must have a start, inputs (documents or information) and outputs (reports/forms/results). At its most simple level, every process has a:

Start – what triggers the process into action? I want a credit card.
Middle – what goes on in the process? The different steps, including variations, business rules, and possible exceptions.
End – what conditions are necessary to close the process? I got my plastic friend. Woohoo!

Business process modeling involves designing processes that add value by showing the transformation of inputs into useful outputs.

What inputs go into the Business Process?

Inputs are whatever enters something into the process, for example, the customer (a human resource) submits a credit card application. In another process, a HR system (equipment) may submit a report to anther IT system, maybe the SAP or Oracle databases. Inputs can be resources (people), materials, energy, and equipment (software).

In UML, a resource is an input to a business process and is consumed during the processing. For example, as each daily train service is run, the service resource is ‘used up’ as far as the process of recording actual train times is concerned. When mapping business processes, an Input link indicates that the resource is consumed in the processing procedure. For example, when customer orders are processed they are signed off and used only once per order.

What are Business Process Analysis outputs?

Outputs are the result, the end product, in the business cycle. Outputs may be a physical product (possibly used as an input to another process) or a service. Outputs are whatever is produced as a result of this action. While this seems obvious, remember that in complexes there may be two or more outputs. You need to decide which is the main output and relegate other outputs to sub-processes. More on sub-processes later.

As a Business Analyst, this means that in the credit card application, the outputs will be the Acceptance of the Credit Card request or a Rejection of the request. When designing the process map, make sure you cover all scenarios so the process flow and all intermediate activities are mapped.

Conclusion

A business process will typically produce one or more outputs to the business, either for internal use of to satisfy external requirements. Outputs may be a physical object (such as a report), a transformation of raw resources into a new arrangement (a daily schedule) or a business result such as completing a customer order.

Remember, business process A’s output may feed into business processes B, either as a requested item or a trigger to start new activities.

Next week, I’ll look at how to use Business Process design techniques for large Software Development projects. You might want to read this if you’re looking at ways to improve your department’s performance, outsource projects, or to improve your knowledge of process design.

Do you enjoy process design or designing flowcharts? Please share your thoughts or lessons learnt below.

About the Author: Ivan Walsh is a contributing editor to the Klariti Small Business Centre. Ivan also shares Business Plan Ideas for SMEs on his business blog. Follow him on Twitter

ProcessCapture Tool Delivers Documentation & Virtualization

admin — Tue, 26 May 2009 00:42:00 +0000

: Image via Wikipedia

There are already a number of tools which use pictorial imagery to increase this ease of use for the mainstream business user.

Examples include the new “Problem Steps Recorder” in Windows 7, “Google Maps” now showing small map sections when giving directions and “Skype” bringing ease of use to the VOIP market.

ProcessCapture allows a user to automatically capture, as a series of pictures and actions, any process or procedure that they are running.

This capture is from a User Interface (UI) perspective only and is totally independent of where the underlying application/data is being served from. This makes it one of the few tools that already supports Virtualization, Software as a Service and Cloud Computing initiatives.

ProcessCapture then uses this same asset to deliver Documentation, Training and Automated testing. Getting these multiple benefits from one easy capture gives a ‘No Brainer’ ROI.

So, who’s behind this?

The founders of Raltus software where the original authors of Compuware’s QARun testing tool with sales in excess of $90m,

Process Capture Tool – Automated Testing of Virtualization, SaaS, and Cloud Computing Initiatives – PR.com

The Requirements Bill of Materials: A Walkthrough

admin — Sat, 16 May 2009 05:56:00 +0000

: Image by Ivan Walsh via Flickr

Bill Lewis describes a model for application requirements based on a bill-of-materials metamodel.

In it he shows how “the imprecise and ambiguous nature of business requirements as a major factor contributing to the high costs and low success rates in system development efforts.”

He adds that while it’s easy for narrative descriptions of business processes to be imprecise and ambiguous, and business requirements documents usually focus on business processes. Data requirements, often an afterthought, are usually relegated to an appendix. The Requirements Bill of Materials

Download MS Word Template Business Requirements Template

Procedures Writing Guidelines

admin — Fri, 20 Mar 2009 04:50:41 +0000

: Image via Wikipedia

A Standard Operating Procedure is a set of instructions having the force of a directive, covering those features of operations that lend themselves to a definite or standardized procedure without loss of effectiveness.

Standard Operating Policies and Procedures can be effective catalysts to drive performance improvement and improve organizational results. Most quality systems are based on its standard operating procedures (SOPs).

With that in mind, you might want to consider the following points when writing your standard operating procedures (SOPs):

1. Purpose

Explain the objective the procedure is intended to achieve. This should be a brief 1 or 2 liner which makes it very clear to the reader what will be covered in this document. Avoid any ambiguous terms. Strive for accuracy. Use short, concise words. Avoid jargon and ‘industry speak’. Remember that the auditors review and evaluate procedures on a scheduled basis.

Highlight any exceptional occasions when users are allowed to ignore this procedure and the alternative procedures they must follow.

2. Scope
Identify the range of activities the SOP applies to, as well as limitations, exceptions, and pre-conditions.

3. Responsibility
Identify the personnel, departments, and contractors responsible for performing the procedure. Highlight the person responsible for training personnel.

4. Procedure
Explain the procedure with clear unambiguous steps. Identify who performs each step and any technologies or systems that are required to perform these steps.

5. References
List other related SOPs, supporting documentation, and applicable regulations.

6. Definitions
Define any words and acronyms used in the document.

7. Attachments
Attach any documents referred to in the SOP, e.g., flowcharts, work instructions, other procedures.

8. Version Control
Identify any changes that were made to the SOP; include the date, author and type of changes that were made.

9. Content
Write the procedure and then test it to make sure it is 1) correct, 2) concise, 3) complete, and 4) comprehensive.

Use language and a level of detail that is appropriate to the level of the user. Don’t talk above the user or switch writing styles in the middle of the procedure. Aim for consistency. Changes in language, style, formatting may undermine the reader’s confidence in the procedure and make them question its authenticity.

10. Tables
Use tables to display information that is best suited to a tabular format; matrices mat also serve the same benefit as readers can quickly extract the information without having to trawl through the entire document.

11. Voice
Write in the third person, use the present tense, and stick with the active voice. This gives the procedure a sense of directness and authority. Procedures written in the passive voice often come across as weak, vague and lacking conviction. Ensure that your material resonates with the reader and encourages them to follow the necessary steps.

Tip: Avoid references to gender (“they, their” rather than “he, she”) unless this helps to clarify an instruction or part of the text.

12. Document Maintenance
Ensure that each page displays the procedure number, title, page number, and release date. Many readers will print out the sections that apply to their task only. Placing this document information in the footer helps ensure that the reader can retrieve and locate other similar information when necessary.

Process Design – Tips for Helping Your Team Adapt

admin — Fri, 20 Mar 2009 04:44:55 +0000

: Image by Geodog via Flickr

So you have decided to adopt a more formal process for getting your projects done, congratulations.

It is a good decision that will help you better manage your projects, make your team more efficient and improve your chances of coming in on schedule and on budget.
Most process methodologies do a fine job at covering the process; however they rarely address the real world issues encountered when a formal process collides with a team.

Each team is as unique as the individuals that comprise it and each will react differently to the new changes a formal process will require. These changes can often be viewed with skepticism or even outrage by team members comfortable doing things “their way”.

Sure you can force it on them but without true buy in from the team the process will at best be ineffective and at worse create chaos.

The following tips will improve your chances of success in any process you adopt and provide a solid foundation for maturing it.

How much Process is enough?

While considered heresy by some process gurus this is a legitimate question. The risk of trying to do too much too soon with a process can be as risky as not doing anything at all, especially if you are a more agile team trying to make the transition to being more process oriented.

Overloading your team with a new set of responsibilities and methods they are not accustomed to or prepared for can easily derail you. Here are some tips for finding the right balance.

– Risk Factor: What is the project’s risk factor? Obviously making software for an artificial heart is much more risky than deploying the third generation of a web site and the process, initially anyway, should match the risk. The former would need extensive, redundant and exhaustive QA checks and balances while the latter can be easily adjusted on the fly after deployment with no loss of life.

Be realistic about what your risks are, how expensive they will be to address downstream, and use this as a basis for deciding how much is required. No one knows your environment, project and team better than you, so use some common sense in deciding what feels right.

– How much can your team handle and what does it need most?: Any process is only as good as what your team can manage and regardless of the ultimate benefits, initially it will cause additional effort in training and new tasks your team is not accustomed to.

To be successful you must achieve buy in and commitment to the process from everyone, this is key. If you don’t your team will simply go through the motions and roll their collective eyes in project meetings. To overcome this find their pain points in how they work now and start with the areas of the process that directly address these.

– Start Small: Start with a few areas that you feel are critical, again including pain points so your team sees immediate benefits. It will be easier to add more process layers later when they see it as a benefit and not simply extra layers of bureaucracy. If you start small your team will have a chance to get their collective heads around this as well as see the benefits, making more maturation downstream easier.

Team Environment

Each team has a different dynamic and will respond very differently to various aspects of what you are trying to do. Too often, out of frustration with problems a new process is forced on a team.

This doesn’t mean your team should dictate your process, but as mentioned above your team’s buy in to what you are doing is essential for your success. Processes are never successfully steamrolled over a team. So tread carefully, get your team involved in discussions about what you are doing and why, it will pay dividends.

– Roles and Responsibilities: Any process will have roles defined for each individual and it is critical that each person clearly understands the role they will be playing and feel they are comfortable in that role.

Spend some time here and ask people if they are comfortable in their role, ask questions and listen! Once your team is set, make sure they are empowered to do what they need to do and make sure everyone on the team is aware of who has a gun and a badge.

If your developers refuse to tell your project manager the information they need you will have a problem. If the project manager reacts by dropping soft milestones into your project plan you have a problem you won’t even know about until it is too late.

So make sure roles are clearly defined for everyone and that everyone knows who has power on the team.

– Full Disclosure: Enough cannot be said about this. The purpose of any process is to address problems as early (cheaply) as possible and this can only be done with visibility at every stage to accurately assess the status of the project.

Developer egos, team infighting, and defensive posturing all create an environment where no process can be effective. It is critical that team members are willing to admit mistakes, call out problems and do so in a way that does not create a hostile environment.

To do this you must bring the parties together and openly discuss this issue. Address the fact that issues are brought up for the overall good of the project and organization.

Reward those who find fault in themselves and point out mistakes. Often the tension can be cleared by starting with admitting your own mistakes first, others will follow, so lead by example and you will see that you can create an open environment were people feel free to view mistakes and even criticism constructively.

– Visibility: Similar to the above, visibility is all about people feeling comfortable disclosing information to the group. Developers will want to sit on code until the last minute because they know it is not ready, designers hate people seeing unfinished work.

So understand why your developer or designer may be twitching as their early work is paraded in front of a group and tread lightly at first with criticism until they become more comfortable with this. Phrases like; “This is really great but how about…” are invaluable, use them!

The fundamental goal of any good process is catching issues as early in the process as possible. So you must discuss this with your team and make sure everyone understands that this can only be done with full visibility on all aspects of the project.

Post Mortem Meetings

The Post Mortem is a meeting to get together after the project has completed. This is not a post release party although depending on the success it may have that atmosphere. It is a chance for some straight talk on what went wrong and more importantly how to address that in the future.

Everyone lines up for Post Mortems when things went well but you can learn more from you failures than your successes. So if you had problems do not miss this opportunity to address them when they are still fresh in everyone’s mind!

Also, Teams need a sense of closure and this helps them do that as well as vent so you can clear the air before you next project starts. Do not let anger and infighting fester into your next project.

– Leave your ego at the door: No where are straight talk and the ability to provide and accept constructive criticism more crucial. This meeting cannot be about egos, or CYA, it has to a frank discussion about the mistakes made by everyone (we all make them) or areas in the process that need to be improved.

Again to set the tone try leading off the meeting by the most senior person in the room discussing mistakes they made or things they learned. It really helps set the right tone and ease the tension.

– Take Notes, Then Action: This is the time to learn and too often people discuss the issues then go off and do nothing. This is the chance to take corrective action to save you time and money on the next project. So take copious notes and put them into action while the iron is hot.

Follow these steps in any process you adopt or any project you manage and you should find it really will improve your chances at success.

About the Author
Randy is the CEO of Reel Logix Inc., developers of easy to use and powerful calendar software like The Calendar Planner for general business and Reel Production Calendar for Film and Television production.

Acceptable Use Policy Template

admin — Fri, 20 Mar 2009 04:39:36 +0000

: Image via Wikipedia

This Acceptable Use Policy is intended to support culture of openness, trust and integrity.

This policy is designed to protect employees, partners and the clients from illegal or damaging actions by individuals, either knowingly or unknowingly.

1. Overview

This Acceptable Use Policy is intended to support culture of openness, trust and integrity. This policy is designed to protect employees, partners and the clients from illegal or damaging actions by individuals, either knowingly or unknowingly.

Internet/Intranet/Extranet-related systems, including but not limited to computer equipment, software, operating systems, storage media, network accounts providing electronic mail, WWW browsing, and FTP, are the property of .

These systems are to be used for business purposes in serving the interests of the company, and of our clients and customers in the course of normal operations.

Effective security is a team effort involving the participation and support of every employee and partner who deals with information and/or information systems.

It is the responsibility of every computer user to know these guidelines, and to conduct their activities accordingly.

2. Purpose

This policy outlines the acceptable use of computer equipment at . These rules are in place to protect the employee and . Inappropriate use exposes to risks including virus attacks, compromise of network systems and services, and legal issues.

3. Scope

This policy applies to employees, contractors, consultants, temporaries, and other workers at , including all personnel affiliated with third parties. This policy applies to all equipment that is owned or leased by .

4. General Use and Ownership

1. While Network Administration desires to provide a reasonable level of privacy, users should be aware that the data they create on the corporate systems remains the property of . In order to protect network, its management cannot guarantee the confidentiality of information stored on any network device belonging to .

2. Employees are responsible for exercising good judgment regarding the reasonableness of personal use. Individual departments are responsible for creating guidelines concerning personal use of Internet/Intranet/Extranet systems. In the absence of such policies, employees should be guided by departmental policies on personal use, and if there is any uncertainty, employees should consult their supervisor or manager.

3. For security and network maintenance purposes, authorized individuals within may monitor equipment, systems and network traffic at any time.

4. reserves the right to audit networks and systems on a periodic basis to ensure compliance with this policy.

5. Security and Proprietary Information

1. The user interface for information contained on Internet/Intranet/Extranet-related systems should be classified as either confidential or not confidential, as defined by corporate confidentiality guidelines. Examples of confidential information include, but are not limited to, company private data, corporate strategies, competitor sensitive, specifications, customer lists, and research data. Employees should take all necessary steps to prevent unauthorized access to this information.

2. Keep passwords secure and do not share accounts. Authorized users are responsible for the security of their passwords and accounts. System level passwords should be changed quarterly; user level passwords should be changed every six months.

3. All PCs, laptops and workstations should be secured with a password-protected screensaver with the automatic activation feature set at 10 minutes or less, or by logging-off when the host will be unattended.

4. As information contained on portable computers is especially vulnerable, special care should be exercised.

5. Postings by employees from an email address to newsgroups should contain a disclaimer stating that the opinions expressed are strictly their own and not necessarily those of , unless posting is in the course of business duties.

6. All hosts used by the employee that are connected to the Internet/Intranet/Extranet, whether owned by the employee or , shall be continually executing approved virus-scanning software with a current virus database, unless overridden by departmental or group policy.

7. Employees must use extreme caution when opening e-mail attachments received from unknown senders, which may contain viruses, e-mail bombs, or Trojan horse code.

6. Unacceptable Use

The following activities are prohibited.

Employees may be exempted from these restrictions during the course of their legitimate job responsibilities (e.g., systems administration staff may need to disable the network access of a host if that host is disrupting production services).

Under no circumstances is an employee of authorized to engage in any activity that is illegal under local or international law while utilizing -owned resources.

The lists below are by no means exhaustive, but attempt to provide a framework for activities which fall into the category of unacceptable use.

7. System and Network Activities

The following activities are strictly prohibited, with no exceptions:

1. Violations of the rights of any person or company protected by copyright, trade secret, patent or other intellectual property, or similar laws or regulations, including, but not limited to, the installation or distribution of “pirated” or other software products that are not appropriately licensed for use by .

2. Unauthorized copying of copyrighted material including, but not limited to, digitisation and distribution of photographs from magazines, books or other copyrighted sources, copyrighted music, and the installation of any copyrighted software for which or the end user does not have an active license is strictly prohibited.

3. Exporting software, technical information, encryption software or technology, in violation of international or regional export control laws, is illegal. The appropriate management should be consulted prior to export of any material that is in question.

4. Introduction of malicious programs into the network or server (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.).

5. Revealing your account password to others or allowing use of your account by others. This includes family and other household members when work is being done at home.

6. Using a computing asset to actively engage in procuring or transmitting material that is in violation of sexual harassment or hostile workplace laws in the user’s local jurisdiction.

7. Making fraudulent offers of products, items, or services originating from any account.

8. Making statements about warranty, expressly or implied, unless it is a part of normal job duties.

9. Effecting security breaches or disruptions of network communication. Security breaches include, but are not limited to, accessing data of which the employee is not an intended recipient or logging into a server or account that the employee is not expressly authorized to access, unless these duties are within the scope of regular duties. For purposes of this section, “disruption” includes, but is not limited to, network sniffing, pinged floods, packet spoofing, denial of service, and forged routing information for malicious purposes.

10. Port scanning or security scanning is expressly prohibited unless prior notification is made.

11. Executing any form of network monitoring which will intercept data not intended for the employee’s host, unless this activity is a part of the employee’s normal job/duty.

12. Circumventing user authentication or security of any host, network or account.

13. Interfering with or denying service to any user other than the employee’s host (for example, denial of service attack).

14. Using any program/script/command, or sending messages of any kind, with the intent to interfere with, or disable, a user’s terminal session, via any means, locally or via the Internet/Intranet/Extranet.

15. Providing information about, or lists of, employees to parties outside .

8. Email and Communications Activities

1. Sending unsolicited email messages, including the sending of “junk mail” or other advertising material to individuals who did not specifically request such material (email spam).

2. Any form of harassment via email, telephone or paging, whether through language, frequency, or size of messages.

3. Unauthorized use, or forging, of email header information.

4. Solicitation of email for any other email address, other than that of the poster’s account, with the intent to harass or to collect replies.

5. Creating or forwarding “chain letters” or other “pyramid” schemes of any type.

6. Use of unsolicited email originating from within networks of other Internet/Intranet/Extranet service providers on behalf of, or to advertise, any service hosted by or connected via network.

7. Posting the same or similar non-business-related messages to large numbers of Usenet newsgroups (newsgroup spam).

9. Enforcement

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

More Downloads – Click here for more templates at the Klariti Template Shop