A Familiar Process

Requirements -> Design -> Implementation -> Testing -> Documentation -> Delivery
This simple process is at the heart of all projects.  Though it may look slightly different depending on your team’s own process, it is a rather established flow of project work, and I think that there is a missing step.
Requirements -> Process Design -> Design -> Implementation -> Testing -> Documentation -> Delivery
For some projects, the method by which the work gets done is clearly defined.  For instance, a client requires you to copy a document ten times and deliver that document to a defined list of recipients.  The process for this could not be much simpler.
  1. Acquire document from client
  2. Copy document ten times using the photocopier
  3. Deliver copies to recipients through mail
Unfortunately, projects are rarely this simple.  In most circumstances, the best way to accomplish any given task may be indefinite, obscure, or altogether unknown.

Process Design

Before even starting to think about the technical design of the solution, it is important to first decide how you will proceed with the rest of the work.  
Does it make sense to design everything up front because of rigid physical construction requirements?  
Does the team have the ability to break up and design small pieces of the larger puzzle?
Can designs be iteratively improved or must they be set in stone before implementation begins?
Answering questions like these is a critical part of the Process Design step.

What Happens During Process Design?

This step is where your team will decide on big-picture process flows.  
  • Will your team be using agile, waterfall, or traditional engineering methodologies?  
  • How will the team work together to accomplish tasks?
    • Are there tasks that lend themselves to doubling-up of resources?
    • Are there tasks that can only be completed one at a time due to a software licensing or hardware constraint?
    • Will team members specialize in particular areas or work as generalists?
    • Are there tasks that only one resource is qualified to complete?
  • How will deliverables be created?
    • Is one individual in charge of compiling and distributing deliverables?
  • How will your team use version control?
  • Who will manage IT infrastructure like VM environments or physical testing equipment?
These questions are outside of the scope of Design, because they aren’t being conducted as an exercise on the client’s product or solution itself.  They encompass the commonly neglected stage of the workflow: Process Design.
Standby for Part 2:  How to get the most out of process design.