Ask anyone at a company the same question and you’re almost guaranteed to get widely different responses across the board. The gap grows even wider when you cross discipline groups from say − Business to Development. It’s a relatively simple question, which (depending on your role) can be difficult to answer and has a huge impact on a company’s ability to release their product.

What is a development process and why do I care?

In this case, the term “development” refers to more than just an engineer who sits in a dimly-lit room, staring at a computer monitor for 8 hours a day writing code and listening to Pandora (ah, good times). A development process is a game plan for planning, designing, implementing, validating, releasing and maintaining your product. Likely, each area of your plan covers different departments or resource groups inside your company that work on different portions of a project.

Key points in a development process:

1. Idea!
2. Some form of planning and requirements gathering takes place
3. Design
4. Implementation
5. Verification
6. Release
7. Maintenance

Just to make things confusing, you can then apply different development models inside your development process. Different development models (e.g. Waterfall & Agile) change the overall execution of your development process while the main points still exist to varying degrees. Each development model introduces different pros and cons.

The problem with Waterfall

Projects created using a Waterfall development model are typically executed in series. The project moves from one department or resource group to another with little or no overlap between the two. In this model (especially if the project is timeline-driven), the last department or resource group to receive the project has the least amount of time to do their work.

An example project process might look something like:

1. Client wants a sailboat
2. Requirements for a sailboat are captured and documented

• A few key pieces are missing, but there were so many requirements that they were easily overlooked

   3.  Design reviews requirements and an innovative sailboat is designed

• Requirements may or may not be updated based on new designs

   4.  Developers take specs plus designs and begin building

• Factory doors close to outsiders, crews begin work

   5. Sailboat is complete, inspector moves in for verification:

• Yes, it is a sailboat
• It does indeed float
• It hasn't been painted

   6. Sailboat moves to production for a paint job...

• "We weren't included in the planning and had no idea this was coming." Followed by a scramble to apply a paint job.

   7. Sailboat is presented to client

• Where's the mast?
• Are there anchors?

   8.  Repeat process

The problem with Agile

Projects created using an Agile development model are typically executed in parallel with a focus on lightweight planning and incremental development. The project is typically built via a collaborative effort between all project or resource groups working on pieces of the project at the same time. In this model, it’s easy to get caught up in “discovered” work as you make iterative improvements and lose sight of the big picture.

An example project process might look something like:

1. Client wants a sailboat
2. High level requirements and concepts for a sailboat are doodled on a series of napkins
3. Engineers think about a how to build a sailboat and begin
4. Design adds ongoing feedback during build
5. Inspector adds ongoing feedback during build
6. Client adds ongoing feedback at each phase of the build process
7. Production works on each section of the sailboat as engineering finishes
8. Sailboat is presented to the client

• Caveat* - We added many great features during the build process but are now at budget, so the ability to float will be available in V2

Conclusion

Each approach has different benefits and drawbacks and the reality is many businesses actually do a hybrid of both models even if they claim to follow one development method over another. What really matters is that your company defines a process that takes into account all groups that actually work on a project and provide some smooth method of transition and ongoing checks and balances for the project as it moves between different departments or resource groups.

One might…

1. Assign a key stakeholder to each project. That stakeholder will follow the project from conception to launch, constantly reviewing the project during the project lifecycle.
2. Leverage recurring project syncs between the groups actively working on the project that focus on status updates, reviewing the next chunk of work to be done and identifying any open questions and issues
3. Constantly update the requirements document as gaps are identified
4. Evaluate the overall timeline and budget as the project progresses to make sure the project is not only on track for work completed, but any “discovered” tasks and change requests are tracked appropriately
5. Allow the client to review the project at key development points and provide an appropriate level of feedback

Regardless of what your development process is, everyone needs to know what your standards are and when they will be involved in each project. Posting public project timelines, milestones and contacts can help alleviate lots of confusion.