Part 2 - How To Write Systems For Your Business
is the second of a three part blog on SYSTEMS FOR A SMALL ARCHITECTURAL PRACTICE Part 1 - What are Business Systems & Their Benefits Part 3 - Implementing and Using Systems for Maximum Benefit
Once I made my personal commitment to transition my small architectural practice into an effective, successful business by introducing systems, I faced numerous challenges. A major challenge was learning and writing systems. By the time I wrote my first system, I had been working in architectural practice for nearly 25 years. I had completed numerous projects and worked on every aspect of architectural service. I was recognized as a star performer within my architectural circles. Unfortunately this had given me an over-inflated feeling of self worth. I knew I was one of the best architects, designers, technicians out there – so of course - starting my own business seemed like the next natural step. With a little hard work, I thought, I’ll be just as successful at running a business as in all other aspects of architecture I had come across to date. But it was not long before I woke up to the reality that something was missing – a basic set of skills in business. A set of skills I had never before considered necessary.
Learning to write systems
Over the years, I half heartedly tried to add a few business skill to my repertoire. There were some moments of success but nothing sustainable. It took me 20 years before I came to the crossroad: either quitting the business altogether or learning how to do it properly. I chose to continue in business, so I found a mentor and an on-line business program to provide me with the necessary business skills.
Once I committed to this decision, I dove into the program that would give me what I for so long lacked. One of the fundamentals of my business education was to develop a systems based environment. Writing became my first major challenge. Learning to write the systems took a substantial amount of time. I was already working long hours; at first I thought, when will I have time f or this additional task. And once the systems were written, would they deliver the efficiencies and effectiveness that my business mentor promised? But, I had made the commitment to learn and apply my learnings to my business so I dove in with both feet, I would find the time for this priority task.
All the expertise I gained over the years had been stored in my head. All the ideas I wanted implemented were stored in my head. The manner I wanted the work done was stored in my head. So in order to get things done the way I wanted, I had to be where the work was being done, constantly. Each time I wanted a team member to do something, I had to tell him what and how. Usually after 2 plus years, team member were indoctrinated with my way of doing things, however they still sometimes wanted to do things their own way. And since there was no written document, no system for them to follow, they thought why not? That was always an annoyance for me. In order for me to get my team members to do things my way, I felt I needed to always be present and managing. Of course, my team members didn’t like it as I was always looking over their shoulders – micro-managing. And I didn’t like it because it was preventing me from doing the work that an owner/entrepreneur was supposed to be doing. At day’s end my team members went home and I stayed for 2-3 hour doing my own work.
As I said, I had all the expertise of completing all the tasks and work done in an architects office, but it was in my head. The systems were in my head. My mentor/coach implored me to get these down on paper as systems by which to run the office and do the work.
“Unless systems are written down, they are not systems only vague ideas”
Thus , I began to write my business systems. To begin with it seemed like a daunting task. I had never before written down instructions other than specifications in contract documents. Anyway, I pushed forward, drafted my first system, sent it to my mentor/coach forreview and critique. We went back-and-forth a number of times to get to where the system was understandable.
“A system should be totally self-explanatory, not needing any verbal explanation by anyone trained in architecture – technician or architect.”
The second system I wrote took less time and less input from my mentor/coach. By the time I’d written 5-6 systems, I felt very comfortable and confident that my written systems were understandable and helpful for the users. During the process of writing systems, it is imperative to get input from the future users. Input from the users will give them ownership and buy-in into the systems process.
The following is a guideline, a step-by-step on how to write systems for your business. Before you begin, assign someone to monitor and track the systems – this will be yourSystems Manager.
- make a 100% commitment to become a systems based business
- learn the skills necessary to write business systems
- notify your team that the business will from now on be run by system processes and ask for their input
- make a list of systems required for the business
- draft the systems
- test the systems and revise as required
- roll out the systems and monitor them until they become culture
- evaluate the system on a regular basis and update as required
Suggested systems in each centre of attention:
o Vision statement
o Strategic objective of the business
o Standard office procedures
o Recruiting and hiring
o Billing for work done and collections
o Annual marketing plan
o Marketing initiative
- Business Development
o Lead generation
o Lead conversion
- Client Fulfillment
o Small projects process
o Drawing standards
Each center of attention can have from 5 to 10 primary systems and any number of sub-systems. Systems should be written to tie to one another.
Systems are a living organism. They need to be constantly evaluated and upgraded. The success of a business can be assessed by its system culture. As the systems culture becomes stronger the company grows and succeeds.
WRITING SYSTEMS System
To create an easy to follow process in the course of designing and writing systems.
To minimize frustration in the course of designing and integrating systems into a business.
To design effective systems that will positively impact the business.
Identify the need for a system
- during the course of running a business a SYSTEM is a written process that will:
o create efficiency
o create uniformity of doing the work
o create an effective outline for new team members to follow (teaching tool)
o create an opportunity to evaluate team members
o to overcome a frustrating situation in the business
Assign system design
- Manager assigns the responsibility to design new system to a team member – this team member should have extensive experience in the details of the ‘new systems’
- Manager meets with system designer to set system parameters
o Reason for the system outlined
o Who will use system
o How will the systems be put into practice
o How will the system positively impact the business
o Who/how will the system be evaluated
o Who/how will the system user be evaluated
- based on experience, observation & good judgment – keeping in mind company goals and vision, draft a system
- a flow diagram will help with writing the system – this flow diagram may become part of the system document if system complexity will be better explained by a diagram
- a well written system is one that can be followed with little verbal explanation to a newcomer to the office
- draft system to be completed and reviewed with the Systems Manager
Assess draft system
- Manager to critically assess if the ‘draft system’ serves it’s intended purpose
- Manager may decide the system not useful or productive – abdicate system.
- review ‘draft system’ by getting critical input from colleagues
- present ‘draft system’ to Manager
- revise ‘draft system’ as required after critique and review
- re-review rewritten ‘draft system’ with Manager and acquire approval
Implement system after approval by Systems Manager
- arrange meetings with all system users to review how the system is intended to work
- Manager to transfer the system to the server file under SYSTEMS MANUAL
- depending upon the prescribed time, Manager to evaluate the system and adjust or rewrite as required to up-grade the System
- evaluate how the systems users benefit from system & if they are diligent in it’s use
system users’ evaluation can be used as part of any team members annual evaluation.
Part 3 Implementing Your Systems coming soon