Purpose of this paper
Being in IT since 2000, I have observed in every mission different processes, various meanings of "success" and various sensibilities to engagements, despite the use of common methodologies.
The definition of a "program" is no exception and varies from one company to another... Even worst, some of them mix project and program, leading to a confuse explanation of the position.
The purpose of this paper is to propose a quick overview of program management and its concepts in few pages, based on official frameworks. Notwithstanding my personal interest for this subject, all the topics are not covered but some of them are described to provide a synthetic explanation of what a program is about and some of its core components. A more complete description could be found in official frameworks.
Note that program management does apply to both agile and waterfall projects[1].
Existing frameworks
Main frameworks for program management are "Managing Successful Programme (MSP)"[2] and "Program Management Professional (PgMP)"[3]. Both frameworks have similar definitions:
A program is a group of related projects managed in a coordinated manner to obtain benefits not available from managing them individually. Program management is the application of knowledge, skills, tools and techniques to meet program requirements. Organizations with mature program management are far more successful than those without it, according to our research.
source: Project Management Institute[4]
Project vs Program ?
A project is a management environment created in the objective of delivering one or more business products to a specified business case. Its lifespan is defined over several months or years.
A program is a temporary organization whom role is about coordinating, directing and supervise its set of related projects defined to reach the company's strategic target objectives. Its lifespan is likely to last several years.
For instance: a project of digitalisation of one business activity of a company could be achieved through the delivery of a new software. However, a set of projects sharing, as a common strategic objective, the transformation of operations of a company is managed through a program of business transformation.
The Vision and stakeholders engagement
The vision is the future operating model of the company, usually defined by the top-level management of the company (strategic management layer), willing to apply some change in the company, for a better future.
This TO BE state must be promoted by management, from top to bottom (strategic, tactic and operational).
Ignorance is the mother of all evils.
The lack of communication from the top level management regarding its vision of the future and the resulting incoming transformation could make fear arise from ignorance, especially at operational level, and endanger the whole program over the long term. From this dramatic outcome, company would suffer financial loss, resulting in a loss of trust from the board members.
Stakeholders must be motivated and strategic roles distributed alongside the program, such as#pro:
- ambassadors: also called "evangelists", whom purpose is to spread the world about the positive outcome of the program;
- business change managers: this business representative have enough knowledge of the activity to define the change management plan with the program manager and ensure that the business-as-usual activity is not disrupted during the change;
- senior responsible owner: he is in charge of the program at its highest level and somehow has undertaken the role of referee for every strategic decision.
Program blueprint
Blueprints have their origins in other management disciplines such as Business architecture planning and Enterprise architecture planning. It contains working practices, required information, technology required to support its operations, etc.
Starting from the current ("AS IS") and future ("TO BE") operating model of the company, the set of capabilities identified to achieve the transformation and their related projects will be drafted and reordered to form the program plan.
Quickwins should be put along the way to keep stakeholders motivated and confident regarding the transformation.
Target objectives achievement tracking
As the program targets to achieve transformation of the organization, indicators must be identified, assessed, deployed and monitored accordingly to target objectives and monitor any deviation from the objective. Moreover, objectives must be set in concordance with business expectations and expected benefits.
Each indicator should be SMART based:
- Specific – target a specific area for improvement.
- Measurable – quantify or at least suggest an indicator of progress.
- Assignable – specify who will do it.
- Realistic – state what results can realistically be achieved, given available resources.
- Time-related – specify when the result(s) can be achieved.
Those Key Performance Indicators ("KPI") must be shared with all involved stakeholders in order to share a common definition and the same information at the same time. Otherwise, the ignorance of those indicators could lead to sterile discussion, tergiversation or even worse, to prevarication.
As I personally encourage proactivity, I would recommend for each KPI to define a course of action to perpetrate in case of deviation in a risk register, as much as possible. The action plan of this risk register should be validated by stakeholders.
Note that for better results, relationships with external suppliers should be put under SLA and based on KPI.
Those same KPIs should persist over time, beyond the program's lifespan to monitor any future deviation.
Assessing viability of projects
Even the most profitable business could be at stake by financing a future outstated nonperforming change, especially when in an era of a forecasted financial storm (MSCI world market indicator evolution is a valuable ally).
To ensure the viability of the program and avoid any sunk cost syndrome, assessments are mandatory at program and project level (each project has to be assessed separately).
Standard recommandations for project assessment states that it should be performed over 5 years, including initial and maintenance costs, discounted at the inflation/deflation forecast. If available, business benefits from project outcome should be included in the balance.
It is more likely that a project with a very distant discounted payback period may be either modified or canceled.
At program level, benefits resulting from combination of projects should be considered.
Beyond the financial aspect, each project should match the standard corporate quality criteria such as - amongst others - change management plan and KPI.
Figure 1 - Project delivery, transition phases and benefits tracking
Further information
The list of topics (governance, communication strategy, roles, risks management, stakeholder engagement, etc.) is too large to be addressed here but additional info can be gathered in the official frameworks, with much more details.
Source
Published at pmmagazine.net with the consent of the author
Jean-Paul LACQUEMENT
About author
IT Program Manager
Hired as IT technical assistant in 2000, I occupied various functions such as software developer, service delivery manager on an EMEA messaging high-availability platform (60M mailboxes), project manager, and program manager (>2M€ annual budget/15 people).
Notwithstanding a strong telco operators based experience, I am also interested in other core businesses such as - amongst others - insurance, banking, public administration.
I am customer centric, business-minded, and pro-active