What are Portfolio and Program and Project?
The vocabulary that includes projects and programs has a chequered past and arrived in the present without clarity. The heritage is a longer tale with lower interest level than deserves setting out first but I’ll summarise below for those interested.
Why are P-“f” and P-“g” and P-“j” confused and confusing?
This is the short explanation. Long ago (after World War I?) ‘project’ was an emerging term used by engineers to describe a package of work to develop something. Less long ago (around the emergence of IT as a entity and then later with publication of PMBoK-Guide) project was well known as the development work to build stuff. All very supplier and techie oriented.
Business managers though had the hassle of justifying, envisioning and aligning folk with the development (pre-project) and then making some benefits from the results (post- project), typically by integrating a number of changes coordinated in parallel to deliver together. It is hard to do SO suppliers noticed and said “HEY we want a piece of that pie! Let us help (for a fee)”. So now we needed a new name for doing stuff that isn’t day-to-day operations but nor is it just a project. Its a collection of stuff all aimed at the same benefits pot, a bigger job, a fatter fee.
Suppliers were happy to call all these changes together a project portfolio. It allowed then to pass back to the customer an overall accountability. You need an escape clause when you do stuff for others for a fee. Sometime later still the realisation dawned “HEY, we also have other activity stuff going on aimed at different benefits but resourced/ funded from the same overall source; we call it operations or business as usual. Its where all the benefits talked about in project and program really come from. Yikes now we need another label.
So Programme or Program became the label for a set of projects ‘linked by their strategic intent’ and Portfolio still suffers schizophrenia. In less enlighten circles it is the label for “all our projects“. In more enlightened circles where the phrases “RtO, CtO” can be heard portfolio is “all our activities” that both Run the Organisation and Change the Organisation. Its the supplier viewpoint that still confuses the issue. Perhaps it is legit. for them to see ‘portfolio’ as just the collection of stuff about change. For the customer portfolio is really all the stuff we do whether business as usual or change related and program is the smallest individual initiative of interest. Buried within a program is ONE or more projects. A project ALWAYS has surrounding activity to defines, injects investment and harvests benefits.
Further the parochial supplier viewpoint IS where trouble with definitions continues to reverberate because the managing of a project and a program BOTH encompasses building baselines, authorising work, tracking and reporting status. The PROCEDURES are 99% the same. (But yikes we’re trying to charge more fees for program managers! Better ‘big-up’ the role). So many authors with only a supplier’s viewpoint have tried to make project management and program management out to be different where they are not and fail to describe where the two roles do differ. It is in behaviours, it is in focus. The supplier ‘procedural’ focus leads to slanted writings and confused concepts – The PMI’s Guide to Programme Management and TSO’s Managing Successful Programmes are two prime sources of confused writing – good stuff mixed with confusion. IT IS THE project manager role and the programme manager ROLE that are different not the management of a project or program’s scope, budget, schedule, risk, stakeholders or communications.
So really there are activities to travel the journey of change, there are activities to operate the cyclic of just how we do business around here and the two sets of activity nestle together in total as the portfolio. Alternatively: there are development managers and there are operational managers. Where operational managers are less used to coping with disequilibrium while caring for capital in times of change then it can be very useful to have business transition experts in to assist; their role is rightly program manager. They can then be transitional coaches to their ops-managers and coordinating overseers to their dev-(project)-managers.
OK that is the short explanation. 🙂