Robin PearsonTechnical Program/Project Manager| tbdMonroe, Wa, United States
Does anyone here have experience with improving a new product development process? In theory, we subscribe to something like the phase-gate theory (generically, not the trademarked one). But in practice, to expedite time to market, everyone works concurrently as much as they can. As long as this is ad-hoc, it is extremely risky.
We've already managed many of the risks of acting on early design by agreeing that no one invests resources on design-dependent marketing or logistics activities without getting clearance from the engineering manager in the early phases.
We're still ironing out other risks, like when a fairly early design milestone morphs into a firm foundation for promising a ship date. The resulting pressure makes it hard for the design & logistics teams to do their jobs with quality, and puts marketing in a bad spot.
So, I feel the best approach is to model our process concurrently, drawing a sharp distinction between design milestones, internal deadlines, and external process dates. I can create the diagrams and write out the guidelines, but I wanted to get some perspective on this issue before I present that to higher management.
Part of what is needed is program management starting at least in the beginning of design, if not in the fuzzy front end. What they've been asking for is coordination at the back end, after design is finished. So I have to re-model not only the process, but my role within it. I believe a successful concurrent approach depends on strong and departmentally-neutral leadership (or at least facilitation) throughout the project.
Thanks,
Robin Saving Changes...
Sort By:
Robin PearsonTechnical Program/Project Manager| tbdMonroe, Wa, United States
Correction:
"drawing a sharp distinction between design milestones, internal deadlines, and external process dates."
That was supposed to be "external promise dates."
Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Concurrent actions will compress time, but you are right, it can be risky. I prefer an overlapping approach. Using a software development example, consider having the requirements team feeding the design team as requirements are developed. They can also be feeding the testing and user manual development team at the same time. This way, as soon as the pipeline is full, everyone is working at the same time and from a single point of controlling documentation. The real proof of the pudding comes at regression and integration testing. Saving Changes...
Robin PearsonTechnical Program/Project Manager| tbdMonroe, Wa, United States
Michael,
Yes, I see what you mean. An overlapping model makes a lot more sense than a strictly concurrent one, so that everyone's efforts start on the same page, from the same set of requirements.
Thanks!
About my role, I've decided not to address that concern in my model at all. I think it's a secondary issue at most.
I'm just going to recommend that as we do work with overlapping efforts, we all make sure to stay within agreed-upon boundaries based on the stage of the design project. So now my task is to outline the process & define the overlaps, risks & boundaries that I'm aware of. The group I'm with is excellent, and I'm confident that they'll be able to take it to a good consensus from there. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
