-1

We have a product suite comprising four products and an underlying data structure. In the past, we've managed each product's work individually, from backlog to release (as, say, "XYZ Product July Release") and incorporated all work into that project under a single project manager. This is how we delivered minimum viable product.

Now that minimum viable products are delivered, we are bringing solutions to the market that leverage capabilities across multiple products. For example, we are releasing the "Retail Market Solution," which may involve a change in the XYZ, ABC, and 123 products. To promote consistency and interoperability, we're managing the solution as a single project that incorporates design and development for the solution as a whole across all products. Because of this approach, there is a prioritization that happens one level above the individual product backlogs (usually through strategic planning). So to that Retail Market Solution, we assign one project manager and that person works with the product managers and product owners to identify backlog items that support that solution...and from there, the project is born (and managed either in sprints or in a waterfall fashion, depending on size, project manager, and available staffing/organizational support).

My question is this: in a model where you're managing product backlogs that capture things outside the solutions list that are small yet still high priority (think defects or incidents...or even very very small enhancements, like a field label change), how do you work those into the project management worklist? If I have 7 project managers and each one is assigned a project that spans multiple products (ie, a solution), where do the smaller items fit into the cycle? How do we keep them from falling through the cracks?

Thanks very much!

  • Sounds like you need a weekly meeting with all PM's - and they should each come with their list of small things that can be prioritized. I would leave this as 7 projects working in parallel. (Gut feeling, so not an answer.) – Danny Schoemann Feb 29 '16 at 9:20
1

A project manager is responsible for ALL of the items that need to be accomplished, regardless of their "size". So there really isn't a "minimum threshold of work" before an issue should be tracked. The easy answer is to enter these small items in your issue tracking database.

I'm assuming that your "project management worklist" is your issue tracking database. (This can be an Excel spreadsheet or a tool like Jira or DevTrack.) It would be easier on you if you have a single issue database for all products, especially when you have to manage/review the to-do lists of multiple product managers. It gets more complicated if each product manager has a separate issue database. (Even more complicated if one uses Excel, another uses Jira, and a third uses hand-written note cards.)

Still, multiple issue databases or not, make sure each item is listed and has an assigned victim, er... responsible person.

Tracking all these details should make your team(s) and managers very aware that you are on top of everything. Plus, it almost always inspires others to create similar small issues to track that otherwise would never get listed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.