Process of Creating a Process

The particular process to which I refer is the infamous PDP, PLC or SDLC. For those not intimately familiar with corporate software development these stand for Product Development Process, Product Lifecycle and either Software Development Life Cycle or System Development Life Cycle. All involve a consistent methodology that cross-functional teams follow as product ideas are defined, developed and rolled out to the marketplace.

When the size of your engineering group merits formalizing the development guidelines it is tempting to get a-hold of some other company’s product lifecycle binder and adopt its contents. However, inflicting an existing process out of context doesn’t work well. This is not to say that you can’t leverage existing processes as a starting point, adapting it to the needs of your group. You’re actually championing the process while you create it, involving people within the company to customize decisions on terminology, fine-tune the processes and very importantly, to convince the rest of the team as to the benefits of using a consistent methodology for all projects.

Corporate culture is a huge consideration when instituting a development process. Just as with PDP vs PLC vs SDLC there are numerous terms for the same concept (checkpoints vs gates vs milestones.) Some terms will resonate more than others with the team. The communications style of the company needs to be factored in and another consideration is the amount of acceptable risk. Depending on the issue at stake and the consequences of making a mistake then the process should have varying amounts of checks and balances.

A “one size fits all” process and mentality leads to maximum bureaucracy. A set of guidelines that encourages more scrutiny of the complex projects while fast-tracking the less complicated projects is preferable. Simple, well understood “rules” enable people to consciously decide to take appropriate short-cuts without radically increasing the risk of failure.