23

TL;DR What is industry standard of how many projects one PM should manage at the same time? There's no such thing; individual projects vary greatly in the level of effort required to manage the project properly. In addition, each project management framework varies in how much overhead is involved. Therefore, the correct question is "How many hours per ...


9

As you've mentioned, it needs to be an elevating vision or goal. In light of the latter, I think the SMART principle and Time Map philosophies apply here. Let's start with the Time Map (to learn more, check out Time Management from the Inside Out by Julie Morgenstern): You know you can't devote all your resources because client projects take precedence. ...


8

When projects and project managers are out of sync, this is an issue at the organizational level. The organization needs to resolve this problem if it chooses to advance in its project management maturity level. That said, it is quite common. Usually, you see this question from the PM point of view, who is trying to ensure its matrixed resources are ...


8

In our company we also face similar problem and I would agree to the post above that kanban is a good choice. Kanban board provides all the necesarry visibility and clarity for team, also we do stan up meetings for quick overview. During planning phase we take parts - if the planning is for first project, we invite only the members that are related. In such ...


8

So, it looks like, you have two problems: Clear priorities. Delivering various projects in parallel. First one can be addressed by creating a clear list of all features (not tasks!) from different projects you work on -- so called Backlog. And this Backlog is common for all projects. And you set policy that you work on this list from top to bottom no ...


7

Although I cannot fault CodeGnome's answer above, I feel like the question has not been fully answered and we circle back once again to the flexibility of the names Agile, Scrum, Kanban etc. Maxim, you have several component parts to your problem which; all of which we face in our department. Multiple Project Requirements (Backlog) Project Backlogs ...


6

The key phrases to remember with Kanban are 'visualise the backlog' and 'limit work in progress'. For this reason I think Kanban is best managed using a single board. Otherwise people find it hard to visualise the total amount of work that needs to be done or that is currently in progress. Multiple boards also make it harder to set hard limits on the total ...


6

From a PM point of view it is two separate projects. If the same developers work on both Android and iOS client, you could however run it as one project. You could achieve a reasonable feature alignment, by having two versions of the user stories (iOS / Android) and prioritize them one after the other. However, if it's two different teams you can't and ...


6

Issue Log & Risk Registry. (hat tip to @David Espina, without whose answer I would have missed this). You're responsible for your project(s). Anything that you can solve relative to those projects, you're obliged to solve. These are examples of things you cannot solve, because they are artifacts of dysfunctional organizational process assets. Things ...


6

I think this is totally possible as you need to agree on one and the most important rule. When you plan sprint backlog, you close it and there is no place for new "unexpected" work items. Because you will be forced to deliver value on each of the ongoing projects, in any other case you will fail not one project but all together. Also, it is important that ...


5

If you are talking about setting goals then go with TechWire's answer. I won't elaborate as I don't have anything of value to add. If you are talking about creating a shared vision for your team/organization it is a different kettle of fish. When you develop a vision you have to think big, aligning the vision to your core values and corporate mission. Take ...


5

We use Trello in a very similar setting and have indeed encountered the same issue. Our current approach to resolve it is to divide the planning into two phases: First, we distribute our velocity over the projects, to plan how much attention we give to each project in the next sprint. Everyone does this for himself, since different people participate in ...


5

Do your projects sequentially, one at a time. Period. And how do you prevent the fact that other projects/clients won't be waiting for a month... Think this one through: say you have three projects to do, and each one will take four weeks (with the entire team working on it). Further assume you wouldn't lose any time switching between them. If you do ...


5

I hope theres not too much redundancy to other answers, but I wanted to go in to some details about tools you might use in agile team with several projects. What we do (about 6 developers, on 2 bigger and upto 4 smaller projects at the same time) is as well combining tools from different technologies. We write specifications based on user stories, which we ...


5

You can't compare efforts between marketing and accounting; accounting is non-competitive. I suspect it is an error to try to compare efforts which are dissimilar. The problem set before you is difficult and potentially wicked. On the other hand the only option you can rule out is to do nothing. I suspect that if I were in your shoes, I'd ask the teams to ...


5

TL;DR My research is covering on how we could have 1 SCRUM board for 1 Team that works on multiple projects simultaneously. SCRUM methodology is not just for working on 1 project, it tells us what kind of work we have to complete and how we are going to complete it (and in what timespan). [Sic transit throughout.] Working on multiple projects ...


5

There shouldn't be any difference in the user stories or acceptance tasks\tests because both are explaining functionality, which will be the same for both apps. Having said that, it's recommended to create tasks for each platform (even if they are the same)as it will be easier to track the progress for each version because of the following reasons: 1.Time ...


5

That sounds like the perfect case for a board. I'm explicitly not saying scrum or kanban board, but a board. To visualize all the different modules as cards with their current status and additional information, maybe due dates etc. Personally, I like Trello a lot, it's online, the basic version is completely free of charge and you can create your board and ...


5

TL;DR In most cases, you should only have one project per product. The desire to split a single product into multiple projects is usually a sign that inter-team collaboration and iterative integration have become a central bottleneck for your process. I provide additional analysis and recommendations below. One Product ➡️ One Project ➡️ One Integrated ...


4

If you stick to a strict interpretation of Scrum, 1 story board = 1 team = 1 project. Could you use multiple story boards? Sure, but purists would probably argue you're not doing Scrum anymore. Are you doing Agile-Scrum? Yes, possibly... If the solution you choose (one or many story boards) is desired by the team(s) and improves their ability to deliver ...


4

I completely support Mark C. Wallace on his suggestions. Once you have the goals set though, you can't just let them go on "auto-pilot". If you set a goal for the next quarter, and then you don't check in with your teams until the end of the quarter, odds are those goals are going to be missed. It's just basic human nature and why, despite it being field ...


4

I think Kanban may work best in your environment. And with some people being remote, you're almost forced to use an online Kanban board. I'll try to address the two issues you raise one by one. Global View You can maintain a Global View of the multiple projects by: Having all projects on the same board, and indicate with a color what project the task ...


4

It sounds like you're operating in chaos, with purposeful loose change control. I am not sure a tool or method is the right solution but rather resetting expectations on what you are able to forecast and promise by way of delivery. If you are in constant flux in terms of your timeline and cost accrual against specific projects, there is no way you can ...


4

Generally, the question I would ask is: "What benefit do you gain from splitting them?" The risk in splitting them is that your prioritization loses focus on end value and, more broadly, that you could get a lot done, but not meet the success criteria of the project because some teams excel while others struggle and you erode focus on that. Many times I ...


3

In order of your questions.. How do you keep the iOS and Android developers on the same page? They are building different clients for the same product. I would treat this a single project. This is a scenario where you have to have a bit of union & separation at the same time Both iOS & Android Developers should belong to one scrum team ( Other ...


3

I recommend determining what you are trying to measure first, and then look at how you are organizing your project data. The answer is very likely that you'll need different groupings for different purposes -- financial forecasting, resource planning, etc. I've found people quickly tire of micro-categorizing and you'll discover everything in the "General" ...


3

Welcome to the community! As Vadim mentioned in his comment, your question is a little complex, so I'm going to try and break it down into bitesize chunks. We use it more as a todo list than a real project management system. First off, strictly speaking, Kanban is not a project management system or methodology. Kanban is a framework, or a set of ...


3

For anyone encountering this question, this is how I do it: Create an overall project file like allmyprojects.tjp Include all needed tji files with include "path-to-tji" {taskprefix sub1} By specifying taskprefix you can have the tasks with the same ID in subprojects. Schedule allmyprojects.tjp In allmyprojects.tjp you can specify reports just as in the ...


3

You need to build an integrated master schedule. You need to pull in all your separate projects' schedules into one schedule and link them. You can link the work packages from different projects directly or you can create major and minor milestones within a sub project and link those, or a combination. Based on Mark's comments below, I do need to add as ...


3

Scrum as a process is a good way of delivering a project which will take several sprints to deliver. It is also very fashionable. However it is not such a good process for delivering bugfixes and small change requests with near-zero lead times. Using a Kanban board on JIRA would be the ideal solution, as Daniel mentions above. Sometimes our estimation is ...


Only top voted, non community-wiki answers of a minimum length are eligible