I am working on a new product development team, and I am struggling to keep the requirements straight. Not only am I working with internal clients, but I also have 7 actual clients. Each new client joining the coalition brings new requirements, which has been easier to manage than the changes that I am receiving from our internal clients. I recommended that I only work with one contact from the Marketing team, who should gather requirements from the other team members, but it just isn't working. I would appreciate ANY advice. Saving Changes...
Do your internal users understand the business drivers and scope for the project? Are they brining requirements that are out of scope? Are you still trying to define scope?
Your approach in getting one person was on the right track. That being, make sure you have the appropriate people involved in requirements. Do you think that is the case?
The manner in which the requirements are gathered can make a difference. If you are using formal requirements gathering sessions it can help focus the effort.
Sorry I have supplied more questions than answers!
As I said it could be many things. I would be willing to chat offline if you think that may bring this to a quicker solution. Saving Changes...
Do your internal users understand the business drivers and scope for the project? Are they brining requirements that are out of scope? Are you still trying to define scope?
Your approach in getting one person was on the right track. That being, make sure you have the appropriate people involved in requirements. Do you think that is the case?
The manner in which the requirements are gathered can make a difference. If you are using formal requirements gathering sessions it can help focus the effort.
Sorry I have supplied more questions than answers!
As I said it could be many things. I would be willing to chat offline if you think that may bring this to a quicker solution. Saving Changes...
Mike Cooper PMPPrincipal Project Manager (retired, sort of)| New England Project ServicesWestford, Ma, United States
I wrote a paper which you can get from my website (www.westfordconsulting.com) titled "Conflicting Priorities Between Product and Project Management in a Combined Product / Services Organization". Also attached it to this message.
It does not quite address your current issue, but might help you avoid some future related issues.
Saving Changes...
John ZacharProduct Dev Manager| Association for Project Management (APM)Brackley,, Northamptonshire, United Kingdom
Heather,
When I manage a project, the first thing that needs to be done is establish the requirements - not easy as you have discovered. A good place to start is making sure that you do understand the problem / opportunity in enough detail so that 'solutions' can be devised. Once you believe (and your stakeholders as well) that you have identified all the possible solutions, then idetifying the best solution (and this part of the discussion could go on for pages / days) identify what products / deliverables will provide / produce the solution you have selected.
Basiclly my project plan starts with what products do I have to deliver to provide that solution. Assuming you have a good handle on the problem / opporutunity then the product set once defined from the selected solution can be baselined. If others belive that the problem / opportunity needs to be revisited for what ever reason, then everyone (or representatives of the varioius groups) gets involved (again). Multiple visits to this area will quickly reduce the level of turmoil as it becomes a pain in the ______. And as you identify / define the products you need to deliver to 'fix the problem' / 'take advantage of the opportunity' you can also idenfity the acceptance criteria. Once this is done, then a change management process will help.
Finally, you should be able to establish a link between the products / deliverables produced by the project, and the benefits identified as a part of the CBA / justification process. If you can establish that link between the product(s) and the benefits(s) then all is fine. If anyone wants an enhancement (scope creep) and can't link it to a benefit, then it can't be justified / included in the project. The other side of the coin is if you can't connect a product with a benefit, then why are you wasting your money on it?
I've only scratched the surface here, but I'm sure you get the idea. If more detail is needed, do drop me a line. I'm in the process of changing jobs, so I'm not sure how often I'll have time to check here.
