What

All companies must use some variety of process to run their businesses.  In early-stage start-ups, processes are usually lightweight and are often ad-hoc – which means that, while flexible, they are not repeatable.  For a business to run efficiently, processes should be at least minimally defined.  A balance is needed between the flexibility required to maneuver and the predictability required to produce a product on schedule, at cost, and at the right level of quality.

Why

Poor or incorrect process definition will eventually sacrifice quality, flexibility, growth, and employee morale.  To operate efficiently, a software development organization must identify the key processes and institute these processes at the right level, providing enough definition without too much weight or rigidity and ensuring that the processes can grow and develop with the business.

Lack of Consideration and Definition

Key processes must first be identified.  If the identified processes are not clearly defined they are not repeatable. (Clear definition does not mean rigidity or complexity, just a clear understanding of the steps and boundaries.)  Even if a given process appears to work and to be well-understood in very early stages of the company, new people and continued growth will quickly dilute this understanding to the point that no one really knows exactly how the process should work.  If key processes are not defined and broadly understood, at some point these processes will probably require retooling – an expensive proposition during rapid and/or sustained growth.

Process Too Flexible or Lightweight

If a process is too loosely defined it will be open to interpretation by each person involved.  The key is to  provide structure at the points where this type of interpretation will cause errors and confusion, while allowing more flexibility in the areas that will enable the company to maneuver easily as conditions change.  Solid definition at critical points in the key processes will ensure a common understanding, traceable actions, and the predictability needed to produce a quality product on schedule.  Such definition will also make it easy to grow and change the process as the company changes – the key areas will already be understood, and the less critical areas can be further defined as necessary.

Process Too Structured or Heavyweight

If key processes are defined in too much detail too early in the company’s history, the company will find course changes and corrections very difficult.  Teams will get bogged down in unnecessary detail, and the most creative members of the team – those especially critical to start-ups – will become frustrated quickly.  Additionally, extremely detailed processes can be very difficult to change as the company changes. 

It is important to note that some processes must have structured definition.  Processes ensuring quality for some types of software (financial or health, for example) must be very well-defined, understood, and followed in order to ensure a very low rate of errors in the field and/or to ensure compliance in certain industries. These same processes would require considerably more flexibility for other types of software, especially those with quick release cycles and adoption rates.

How

1. Articulate the corporate culture – processes must conform to and support the culture.  For example, if many engineers work offsite regularly, requiring in-person walkthroughs of all code would make either the culture of offsite work or the process of walkthroughs difficult to maintain.
2. Define the product lines and other corporate drivers for the foreseeable future.
3. Determine the key business processes.  For software development companies, these typically include the development methodology (waterfall, spiral, agile, XP, etc.), configuration management, architecture and design, code, build, review and unit test, quality engineering/quality assurance/quality control, release, and maintenance.
4. For each key process:
   1.  Gauge the level of structure required based on the corporate culture, product lines, and other corporate drivers.
   2. Define the basic process flow – the basic, generic steps required to complete the process.
   3. Determine the critical points of the process flow.  These are the activities that must be performed in the same way consistently by everyone involved in the process.
   4. Clearly define the required actions for each critical step in the process, preferably working with a team consisting of representatives from each group involved in the process.
   5. Working with the same team, define the required outcomes of each non-critical step in the process.  This allows flexibility in methodology while ensuring that the goals of the process and its components are well-understood by the team.
   6. Chart a growth path for the process based on the projected evolution of the company.  At a minimum, determine checkpoints for re-examining the process to determine whether adjustments are needed.
5. Document each key process in an easily accessible format and location. 
   1. Don’t over-document, or the documentation will be out of date almost as soon as it is written
   2. Depend heavily on pictures – charts are available in many different tools.  Add text where it is critical for understanding, but do this with the knowledge that most engineers will probably not read the text, especially under schedule constraints.  Start-ups are volatile environments; any process documentation requiring substantial time to read and understand will largely be ignored.  Provide clear, step-by-step instructions wherever possible.
   3. The best place to post process documentation is on the company intranet.  Everyone can access the intranet easily even over VPN, and it’s an easy medium to update.
   4.  Consider use of a Wiki for people to post hints on how they’ve implemented the more flexible process areas in different situations.  This often evolves to the next stage of the process through common use, with very little upheaval.
6. Review each key process regularly, updating as necessary.  Because the environment is changing, the key processes will require regular adjustment.  A good time for process review is immediately after a product release, especially during the project post-mortem.  With a cross-functional team, note what worked well with each process and what requires adjustment, then determine the appropriate adjustments.  Be sure to update the documentation with the changes, and communicate the changes broadly across the company.