Starting a product development project with an independently facilitated workshop is a great idea. Organising teamwork, and communicating a common vision to everyone avoids headaches later.
In his book Assessment and Control of Software Risks, Casper Jones tell us that facilitated workshops:
- reduce the risk of scope creep – continuous growth of requirements over a project lifecycle, from 80-10%
- speed up the delivery of early lifecycle phases by 30-40%
- increase function points by 40-85%
- provide a 5-15% savings in time and effort for the whole project.
These are not insignificant indicators that workshops have major benefits, however, Casper did miss a couple of extra points that they bring:
- Stimulate fresh ideas. At the workshop session, where all relevant knowledge is in the room, attendees will likely contribute to the problem from different viewpoints. The important thing is to make sure that each of the participants weighs into the discussion.
- Encourage involvement. In getting involved in hands-on product discovery, participants are more likely to engage and provide helpful support and ideas along the way. Close collaboration feeds team spirit.
- Boost communication. In any product development, the lack of proper communication from the beginning increases the risk of failure. It can lead to misunderstandings, over-interpretation, and missed expectations. Because of the level of interaction, workshops build trust, relationships and consensus. Ultimately, it improves communication among the participants. During these workshops, clients get to know the team and can communicate their vision of the product to make sure the team is on the right page. At the same time, the team gets a chance to specify the requirements, so there’s no place for ambiguities to hide.
- Get a better understanding of the whole project. The more detailed analysis is done before development, the less likely you’ll stumble on unexpected issues and incur extra costs. Here is where a workshop comes in handy. Сollaboration builds a shared understanding of what we’re delivering and why. Intensive discussions unveil uncertainties, risks, and weak points. They also allow for estimating time, cost, and framing the scope of work. Designers and developers get a clear picture of the product assumptions, their context, users, and business needs.
- Reach consensus on contradictory points. A workshop aims at coming to a conclusion that can be accepted by all members of the group. A single person can block consensus if he or she considers it necessary. In this case, the group will keep looking for the next most acceptable alternative for all parties. As the Russian saying goes, в споре рождается истина, or for us English purists, the truth is born of arguments.
- Speed up the project. Workshops are more efficient in managing time compared to one-on-one meetings. As limiting the time-to-market is crucial in gaining a competitive edge, the use of workshop concepts for product development becomes essential. At one meeting the team is able to achieve the results that otherwise could take weeks.
In his book The Unified Process Inception Phase, Scott Ambler highlights the speed of various example products created in facilitated workshops:
- In 75 minutes a workshop delivered and categorised nine risk areas and created 13 risk-mitigation strategies for the two major risks;
- In three hours a team validated a data model and decided on the scope of the data for the business performance metrics; and
- In just four hours, a project team defined the deliverables for the upcoming design phase, distributed responsibilities, determined the quality criterion, and mapped it into a timeline with dependencies.
What are the benefits of product development workshops?
- Boost participation and collaboration
- Get a better understanding of the whole project
- Reach consensus on contradictory points
- Speed up the project
What issues can be fixed in a workshop?
- Contradictory points e.g., conflicting requirements that have to be validated
- Unclear expectations e.g., when designers and developers have no idea about the product to be developed
- Incompleted decisions e.g., when the results of a decision need to be confirmed after a period of time has elapsed
- New requests from clients that come up during implementation e.g., when the client changes some requirements