Let’s start with a hypothetical project about a product development team. The client hired a team to build two prototypes for a baby bottle that could keep formula or breast milk fresh for 24 hours without refrigeration. Preliminary design requirements were that the bottles should be 8 ounces, non-breakable, easily cleaned in a dishwasher, and work well for babies. The client was unsure about the choice between glass and metal and asked the team to pursue both options to the end in order to develop full testing results on both options. The prototype team was responsible for fully testing the safety of the bottle in a variety of conditions.
The project team, which consisted mostly of mothers, developed a clear scope and was completely engaged on the project. It identified the essential activities, some of which were:
- Requirements design for cleaning
- Requirements design for bacteria growth
- Requirements design for materials used
- Build glass prototype
- Bacteria testing on glass prototype
- Build metal prototype
- Bacteria testing on metal prototype
- SWAT analysis on glass and metal prototypes
As time went on, the team began running into problems. In this blog, I discuss three areas of discomfort and why a failure to properly define project activities led to conflict and confusion.
Activity Nickname
What are you going to call the activity? This may sound like a non-issue, but if you don’t agree on a nickname, people will default to various names, causing confusion after confusion. So, decide on a short, clear nickname for each activity. In this project, there were three activities related to design requirements. In communication after communication, someone would be very clear that the conversation was around one particular subject, such as bacteria growth, only to learn that others were confused.
Activity Description
The description of the activity is essential. It needs to be clear to everyone what needs to be done and how the team will know that they have been successful. What does ‘done’ look like? Think of your activity as a work package with some benefit that can actually be delivered to the client or to your management team.
Take for example, the activity called Requirements design for cleaning: Is this activity supposed to generate a one-page summary list of the requirements for cleaning? Or is it supposed to include the ‘how’ of cleaning? Let’s face it. We all know that until you have walked through the ‘how’ you won’t really know if you have considered all of the right questions.
For another example, take the activity called: Bacteria testing on glass prototype: Does this include having a baby actually use the bottle, or is this just laboratory testing? Does this include separate tests for formula and breast milk, which are quite different in the area of bacteria growth?
Getting project teams to think through exactly what is needed for each activity is time-consuming and difficult. It’s worth the effort though, because it will save you a lot of consternation and confusion later in your project.
One suggestion is to think of your activity description as a user story. In Scrum, stories are written like this: As a [who], I want [what] so that [why]. In traditional Scrum, project teams capture these stories on index cards or sticky notes. This forces users to think through exactly what they need and why in a very clear and concise way.
Writing user stories will help you understand the who, what, and why behind your project activities. Click To Tweet
Quality
It is cheaper to build in quality than to repair it. And yet, higher quality costs more money. So, clients may well choose to scale back quality requirements on some activities.
Take for example, the quality needed on the prototype bottles: If at this stage, the client expects the testing to be done with babies actually using the bottles, the quality of those bottles will need to be much higher. Keep in mind that the client has not yet decided on whether it wants a glass or metal bottle. Since introducing the germs in a baby’s mouth will impact your test results, at some point, that will be essential. To save money, the client may well decide to cut quality on the bottle prototypes, and simulate the introduction of germs from a baby’s mouth. The trick is to identify the quality needed early in the process.
Are your project teams struggling to clearly define project activities? Schedule a free call and see how we can help.
