Portfolios, Programs, and Projects, Oh My!

[#1]

In the process of developing new project methodology standards for a couple of teams within my department, I've been asked several times to explain the difference between a Portfolio, a Program, a Project, a Release and a Sprint. Currently, there is very little version control for development efforts, and I've been "voluntold" to address it in the new process. It makes sense for those that have worked in IT and software development, but in our case, several of the team members are not used to the terminology. And, since I've also noticed similar questions in the Community, here is how I break it down for my groups.

(A side note…I've found it best to use non-technical examples to explain technical concepts; it makes it easier to grasp. In most cases it works, my only failure was trying to use a receiver, amplifier, and turntable to explain Components in Jira. I forgot that I'm old and kids these days have never seen a "component stereo system.)

Portfolio

PMI defines a portfolio as "projects, subsidiary portfolios, and operations managed as a group to achieve strategic objectives. Helpful? Meh. The PMBOK also has an image that is better, for all of us visual learners out here (PMBOK Guide, 6th Ed):

Think, for a minute, of a growing suburb of a big city and picture it from the window of an airplane at 35,000 feet.

As urban sprawl takes over open land we can see that the city planners created residential, commercial, industrial, and agricultural zones within our suburb. That can be considered a portfolio, just as a company's full set of projects can be lumped together into a single portfolio, with sub portfolio and programs for departments within the organization. Looking at our fair city a bit closer, we can see that the Industrial Zone can be broken into sub-zones for Light Industrial, Medium Industrial, and Heavy Industrial, the Residential Zone is separated by Single-Family and Multi-Family zones, while the Farming and Commercial Zones are not yet big enough to warrant further definition. 

Programs

The PMBOK is a bit more helpful here because "a program is defined as a group of related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually." (PMBOK Guide, 6th Ed.) Coming in at 10,000 feet, our Residential Zone portfolio, and the two sub-portfolios for Single- and Multi-Family are now viewable as groups of residential housing developments and apartment complexes. Each of these is its own program; they are comprised of separate houses and buildings.

Project

Here's one we all get: a project is "a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources." (https://www.pmi.org/about/learn-about-pmi/what-is-project-management)

We've now landed, rented a car, and are driving by our new house. There are quite a few houses in this development, but since it is being built by one development company that shares builders between houses, each house is considered its own project. 

When our house was being built, it was put together as a series of Releases, Sprints, and Features in a previous project, called House.

In Jira, and in Scrum overall, a Sprint is a feature or set of features within a product release while a Release is the complete feature set for that particular version of the product. Both are considered "shippable" and able to be consumed by the end user, but generally speaking, the output of a Sprint is just the short-term part of the end product and cannot stand alone while the output of a Release is the long term, the strategic product itself. 

Since our new house is already there our new project is to add an addition to the House. The project is to go from House v1.0 to House v2.0 by adding on another room. The Release is the room itself, and the Sprint are the parts of the room. So, the sprints could shape up like this:

Sprint 1: Pour the concrete. 
Sprint 2: Build the frame
Sprint 3: Wire the room for electricity
Sprint 4: Hang the drywall

Release 1.1: Turn over to the Decorators

Sprint 5: Lay the carpeting
Sprint 6: Paint
Sprint 7: Add furniture

Release 2: Deliver House 2.0 to the Home Owner.

Each sprint is complete and verifiable in and of itself, but without the other sprints, it is not a complete project.

Each Release can be an endpoint to the project (like House 1.1), if that fits into the strategic goals of the owner, or it can be combined with other releases and delivered as a version update. 

OK, this example is getting tired, but it's not quite done yet. Part of the methodology is deciding when stories can be closed, and if they get reopened to correct defects.

Definition of Done

So…How do we, as the product owners of the House, know when it is done, and the builders can be paid? An Agile or Scrum methodology needs to include a "Definition of Done (DoD)," or put simply, a set of deliverables that meet certain defined criteria. When each is done it is marked "closed."

Let's say that Sprint 2 "Build the Frame" has 6 stories: Frame the Bar, Frame the Living Room, Frame the Second Bathroom, and Frame the Man Cave.

During the final inspection (UAT) we discover that one of the walls in the Bar isn't level so the ceiling is higher on one side than the other. We let the contractor know, and they come in, tear down one wall, then rebuild it...drywall, electricity, paint, the whole thing. 

Is this reopening the story "Frame the Kitchen" or is it new work to fix the mistake?

Under the Scrum or Agile methodology, the "Frame the Bar" story is done; the contractor has moved on to other things. If they were to reopen the story it would mean tearing the mistake down, fixing it, then reopening the subsequent stories to run the electricity, hang the drywall,  paint, decorate, etc. (Which, BTW..in a real-life situation increases the work effort for that user story during that sprint, which will overstate the team's velocity.)  

However, if it is counted as new work to fix the mistake the estimated cost of the work includes the frame, electricity, drywall, paint, and, once the punch list of "bugs" is finished in an added  "bug fix" sprint, the final inspection is redone, the project passed the DoD, and the builders deliver House v2.0.

[Marty]

This is a fun read - you chose a great metaphor!

[Ravi Kashyap]

I want to create a Jira template based on your methodology.
A company XYZ  has few portfolios like (Digital, Stores & Inventory, Merchandising, Finance, HR etc..) and each portfolio have multiple products/applications, e.g. Digital has mobile apps, POS systems ..say about five applications under the portfolio).
So each application would have various projects say Mobile apps would have - one for Android, IOS, API and each of those projects would be linked to a repo on SCM tool, and create task or subtask as an issue. 

XYZ -> Digital -> Mobile App -> Android -> Customer Enhancement

                                                  -> Android -> Bug Fix

                                                    -> Android ->  Task -> Sub-task

                                                   -> IOS - > New Feature

XYZ -> Digital ->POS -> Updating New Devices-> Task

                         ->POS ->building API interface-> Task

                          ->POS ->building API interface->intergration->issue

How would you do this on Jira?

[Scott Theus]

Using Jira with no other add-on apps I would probably set it up with Releases and Components to manage the portfolios. Using your example:

Project                                Release/Fix Version                                   Components
Android                              Android  Customer Enhancement             Mobile App, Digital

                                           Android Bug Fix                                        Mobile App, Digital

                                           Android  Task  Sub-task                            Mobile App, Digital

                                           IOS New Feature                                       Mobile App, Digital
POS                                    POS Updating New Devices                      POS, Digital

                                          POS building API interface                         POS, Mobile App, Digital

                                          POS building API interface integration      POS, Digital

This allows you to run the "Android" and "POS" projects as continuous release products instead of projects, report at the Program level by filtering on either the "Mobile App" or "POS" components,at the Portfolio level by filtering on "Digital," and it will show you dependencies between projects by filtering on issues with both the "Mobile App" and POS" components.

-Scott

[Vijay_Singh]

This is an amazing article, Today I got the difference between Portfolios, Programs, and Projects, Oh My!

I want to add here my own points for you, Why portfolios and Programs are interrelated or project and if this is so, Then why project management is too important for every business process. I have read one article over the web about What is project management, Can you please suggest me the difference?

[Nikhil Sehgal]

Project management is the application of processes, methods, skills, knowledge and experience to achieve specific project objectives according to the project acceptance criteria within agreed parameters.  Project management has final deliverables that are constrained to a finite timescale and budget.

To get some more insightful information check out What is Project Management?