We are also just starting out with JPD and have decided to use Project start as the date when engineering resources will be applied to the idea (decomposition starts on a JSP project). This allows us to sequence ideas while keeping capacity in mind (don't want to start too many ideas at the same time). We are using Project target as the date when we would like whatever the idea is describing to be done. This can inform the engineering team as to controlling the scope of what the idea is describing. Note the use of the word Target. The team creating and triaging ideas should not be spending so much time as to fully specify, decompose, and estimate the work (not agile). Once the engineering team has done the decomposition, we discuss what we can get by the target date, and if necessary, adjust the target date based on engineering feedback. Among the things we could do: phase the idea into multiple releases, shrink the scope of the idea in order to meet the target, or shift the target date "right" (right is always later - think Gantt charts).
Once we have come to an agreement, then we use the Due date field to document the current proposed date for coordination with marketing, qc, customer support, etc.
That Due date and Target date may shift as engineering uncovers more work (progressive elaboration + change) - but the stakeholders know where to look to see what's coming and when.
I don't plan to link the Start and Due dates in JSP to JPD as the dates in JSP are "more firm" than those in JPD. The dates in JSP inform the dates in JPD but don't constrain them as JPD encompasses more stakeholders than JSP thus coordination and collaborative efforts not directly associated with engineering works are consumed within the JPD dates. I try to keep marketing, education, and training timelines distinct from engineering timelines. :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.