We’re rewarding the question askers & reputations are being recalculated! Read more.
20

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

You can think of a "client" as just another variable to display on your board. Since it's just another variable, all you need is a way to distinguish one client from another visually. You can do this with (off the top of my head)... location shape color orientation size something else... You could put clients in their own swim lane. Or assign each a ...


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 ...


7

Some points from my side to add to the ideas already expressed: don't promise anything you will not be able to honor, or make it clear that is your intention and may be subject to changes. Even when this could seem very basic when dealing with mature adults, it can be surprising how not meeting these kind of expectations can demotivate someone. consider not ...


7

You may want to take a page out of Pharma's book when managing R&D projects. Although making drugs is far more heavily regulated than writing code, the key ideas are: Regular and frequent kill points. From 10,000 good ideas you'll get one drug to market, and the best way to do this efficiently is to kill the 9,999 ideas that won't work as early in the ...


7

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 ...


6

The Framework Answer From a framework perspective, each Scrum Team works from a single Product Backlog, and each sprint should have a single unifying Sprint Goal. If you have multiple projects, it seems unlikely that you can meet either of these requirements. Scrum Teams are Project Teams While a Scrum Team may work on multiple projects over time, and in ...


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

Experience is a weak indicator for future success (Hunter & Hunter, 1984). So feel free to remove time in chair as it will not hurt you. Age is a zero indicator for success (same study) so definitely remove that from the equation. Your best predictor is cognitive ability, to be able to think critically, to be able to analyze. Since all of your ...


6

A few ideas that might help to find you an approach which is suitable for your organization: 20% time. The approach used, among others, by 3M and Google. Of course it might be something different than 20%. The idea is that everyone can work for some predictable amount of time of their side project. With such approach you basically base on people ...


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 ...


6

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 ...


5

I did some experiments in the past and it seemed that those teams were successful, where the members where able to work together before. This setup were way better than the setup when the team setup was based on the necessary skill sets. My suggestion would be to setup teams based on the existing "small groups". People with the same understanding learn more ...


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

You are right, that setup is something hard to sell, and when you do A,B,C,A,B,C there is a chance that you won't finish anything. What happens if a user story of project B is not finished in its sprint? You have to shift it to the next. In this case you'll have to wait several weeks to continue, which has the risk of forgetting what has happened. My ...


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

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

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

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 ...


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

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

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

Drawing from the body and comments of a previous question, what is the best way to schedule simultaneous projects and resources to those projects? Ideally you will schedule your team so as to minimize the amount of time that they are working on more than one project at a time. This helps avoid the inefficiencies associated with multi-tasking. Failing the ...


4

If there are truly no advantages in people's existing skillsets, then you have to look at other factors. You need a good mix of solid developers and more wisened developers to ensure success, especially since this is out of everyone's comfort zone. I would first look at your more senior (company-wise) developers and chose the ones who are some of your more ...


4

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 ...


4

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 ...


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 ...


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