9

Agile/Scrum process can be used for projects with fixed unmovable deadlines Is it valid and possible to cope fixed unmovable deadlines into Scrum? Yes. We did a project related to the Olympics using Scrum. Naturally, the deadline is fixed unmovable. There is nothing wrong with this. We were able to adjust scope so that we fit in what could be ...


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


5

Besides for the regular "delays in schedules" which are standard risks, here are some ideas: You need to worry about interoperability. There's no way to know in advance how the deliverables from the various vendor will work together. Another risk is the responsibility of the inter-project connections? Which vendor is responsible for making these connections ...


5

Agile does support to concept of fixed deadlines. You prioritise your backlog and get as far down the list as you can by the time the deadline has been reached. What you can't do is fix both the time and the scope. You can, in theory, vary resources and keep time and scope fixed. However that ignores the difficulty of ramping up resources. As Brooks' law ...


4

The confusion here can sometimes come from people using the term "program" when we would technically mean "project" in the organizational framework (afterall a "program" could be your project!). You are correct in that strategy is the common linkage from project > program > portfolio. It's often thought of as a pyramid with projects at the bottom, but the ...


4

The key is here.... ...to obtain benefits not available from managing them individually A Project is the smallest element that has self-contained benefit. A Programme aggregates those benefits into a strategy. Building a hotel is a project. It has a benefit. You can create 'sub-projects' out of each floor but their benefit is not realised until the hotel ...


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 my experience a Programme is a collection of projects where each project delivers part of the overall programme outcomes (i.e the programme is like a super-project but with several substantial sub-projects), whereas a Portfolio is merely a collection of projects managed together (like a portfolio of stocks you may have invested in). I have also seen ...


3

It's a big question with a complex answer space. My favorite framework for working in multiple teams is LeSS. Their signature book, Large Scale Scrum, is the best book about Scrum (at any scale) that I've come across. Basically: cross-functional teams, single product backlog, single Product Owner, separate sprint backlogs, and planning and retrospective at ...


3

Program consist of projects that are somehow related or orchestrated to a common target. For example, in my company we have a customized SAP solution. We implement this solution to every country and cover that country' processes within this customized solution. Each roll-out project including tasks and developments for that roll-out is called a project. And ...


3

From the experience in my company (which seems to be aligned with the opinions here), a Program Manager is responsible for n Projects managed each by a Project Manager. Become a Program Manager is the 'career path' for Project Managers (PM). Some duties I'd list: Responsible for all non-project-specific paperwork / bureaucratic duties Responsible for ...


3

A Gantt chart is a scheduling and not a resource tool. It documents the planned order and inter-relationship of activities needed to develop project products, and from this you can identify a critical path, but not resource constraints. A program like Project will integrate resource calculations with scheduling calculations, but conceptually they are ...


3

Fantastic question; significant overlap with my situation. I've got a couple of disorganized observations in response. First, planning without the team violates the assumptions in the PMBOK. I don't mean to treat the PMBOK as gospel, but I've found that pointing out that a given practice is at odds with the PMBOK is enough to get the audience to listen to ...


3

It has been my experience that a Project Manager handles one project at a time from beginning to end. On the other hand, the Program Manager handles multiple simultaneous projects from pre-sales to post sales. For example, the Program Manager will work with the proposal team as content expert, trying to win the contract. He will be the main or sole ...


2

I know this is an old question and I'm just a newbie here, but this is a subject very close to my heart and expertise. The best way I have found to explain the difference between projects and programmes (and their respective managers) is by example. I'll use the London Olympics as an example of a programme (and please bear with me as I know the example is ...


2

Programme managers coordinate a functional (all projects needed to increase sales performance by 10%) or organisational (all projects within the finance division) group of projects. They have hierarchical power over the project managers whose projects fall within their programme and may require those projects to change their deliverables and timelines in ...


2

TL;DR I’ve been tasked with updating the business cases underlying several projects in a program that is significantly over-schedule and over-budget. This is corporate-speak for "the projects have failed." To address this properly, you may want to consider positioning the current program portfolio as a sunk cost so that the focus is not blame avoidance, ...


2

Mr. Espina has offered the textbook standard answer and I agree with his answer. That list is a bit granular, and I'd like to add a few more general metrics that would help me to understand and interpret the information collected. I'm looking for an "elevator speech set" - a set of numbers that can be presented intelligibly on a single slide/ ...


2

The core metrics are: Cost variance: current period, cumulative to date, and at completion Revenue Variance (if seller of services): current period, cumulative to date, and at completion Profit Margin Variance (if seller of services): current period, cumulative to date, and at completion Schedule variance: current period, cumulative to date, and at ...


2

TL;DR There are really only two possible answers to "how should we do things in our company?" The first is that the politics and governance of your business is an internal decision that will be unique to your organization, and can't possibly be answered by strangers on the Internet. The second is that, from a project management viewpoint, responsibilities ...


2

Your OP is slightly disturbing and appears to be a tail wagging the dog strategy. You indicate that you need to control the types and numbers of projects based on number and skill set of your PM. It's the other way around. Your projects for the year should dictate what you need by way of PM and should trigger either shedding those you don't need or hiring ...


2

Well, consider you as an IT service provider signed a deal (~size of USD 10 Million) with your esteemed telecommunication client. Assume this deal includes all the operations pertaining to Information Technology (IT) and Information Technology Enabled Services (ITeS). Now, how will you as a "service provider" identify this deal? Will you consider this deal ...


2

My definition is far simpler. A project has a defined start, defined scope, and defined finish. A program has an indefinite time and indefinite quantity. It differs from an operations in that operations are intended to be an ongoing concern in perpetuity while a program is intended to end but not known when or to what degree value and quantity are ...


1

I guess this is a question to fill a risk log initially. To do this, think in general categories and identify individual risks w.r.t. your programme. I like to use the PMI Knowledge Areas to think about risks, given e.g. here: https://www.projectmanager.com/blog/10-project-management-knowledge-areas E.g. Project Stakeholder Management: Errors due to bad ...


1

Why do you want to do a single scrum with the three teams together? Let them do their separate scrums, and afterwards do a scrum of scrums. Each team delegates one (or max 2) people for the scrum of scrums and they can discuss impediments between the teams for example. Do it also daily and it should last only 15 minutes extra


1

If your organization is following PRINCE2 and/or MSP or the whole P3O/P3M3 standards, then for project management using PRINCE2 there is a formal but optional role/department for Project Support, which may help in providing administrative services or advice and guidance on the use of project management tools or configuration management. However, for ...


1

Very, very subjective. To sell anything to anyone you need to understand the context in which it will help them. What pain points are they having? Those are the things you want to target with your pitch. Much easier to sell water once you know the client is thirsty. Having said that, PMI have a good whitepaper that outlines some of the points you could ...


1

You are not alone. Many companies call themselves agile but only few really are. What sounds weird is that your company requires universal story points that apply to everybody. Story points are a relevant metric useful when a team has some history and knows their velocity. Otherwise story points are just random numbers. I worked for company similar to yours ...


1

Adding to this, I highly recommend tracking amounts and sources of "emergent work" (whatever was not in the initial backlog vs. velocity calculation) as you go, and continually factoring this into your planning, or predicted scope. By this I mean points for "unknown unknowns" or new backlog items that come up every sprint, points for feedback, points for ...


1

You need to understand the context behind the task you have been given. If the expectation is that the programme is to be killed off, and all you are doing is to provide justification for that, then whatever else you do may be a waste of time and effort. On the other hand, if the question is being asked as a genuine "should we or should we not continue?" ...


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