How to Implement These 4 Program Management Best Practices
Program management involves sustaining on-going, interactive relationships between multiple projects.
Many separate development teams may work on distinct applications, but all of those applications serve a collective purpose. In telecom operations, that collective purpose may be to deliver software-defined networking, network functions virtualization or some other B2B service.
Just as DevOps has its own set of best practices (check out the tweet below for more information about that), so too does program management.
— CloudSmartz (@CloudSmartz) March 29, 2017
While you could argue that there are about a dozen or so, four central program management best practices stand out:
1. Clarify The Business Problem
The purpose of any program is to solve a specific problem. When a group of telecom executives say they want to upgrade the company’s OSS/BSS engine, the program manager needs to clarify why. Is it to support bandwidth-on-demand (BoD) services? If so, why is the telecom trying to offer such services?
Identifying the business value behind a program enables program managers to keep associated projects within scope. For example, instead of applying random features to the OSS/BSS engine, the developers can ensure the upgrade contains functions that support BoD services.
2. Attain Stakeholder Consensus
Each program should have a Product Owner who reports to the Program Manager.
While the Program Manager administers the resources necessary to support the program, the Product Owner defines how the product will function. That product could be a software-defined networking solution, an enterprise resource planning application or some other technology that solves a business problem.
The challenge is that the stakeholders (i.e. people who will either use or benefit from the product in question) may have different opinions as to what that product should do. It’s the Product Owner’s job to sit down with all the stakeholders and attain a consensus among them as to how the product will work. Doing so establishes expectations as to what the product will look like toward the end of the program.
3. Create a Risk Register
Of all the program management best practices you implement, establishing a register of all the risks associated with your endeavor will save you a lot of headaches down the line.
How you choose to configure your register is up to you, but many program managers recommend instituting a risk scoring framework that denotes the potential costs associated with a particular action.
For example, suppose the focus of your program is to update your legacy OSS/BSS systems. The obvious risk is that, in the midst of updating this legacy system, service disruption may occur. You’d denote this risk as “high” in your scoring model through either a numerical or linguistic expression.
This is a simple example, but it illustrates how risk scoring can help you effectively allocate resources. If a certain risk has a high score, your development and operations teams will have to structure sprints around mitigating that risk.
4. Establish a Change Management Plan
If the duration of your project portfolio lasts over the course of a quarter, there’s a good chance that organizational disruptions may impact the progress of your program.
Instituting a change management plan entails establishing change agents who keep themselves abreast of other initiatives across the organization which may affect the program’s execution. These agents must:
- Assess likelihood of specific changes occurring.
- Forecasting the effects of those changes across the organization.
- Continuously inform the Product Owner and Project Leads of any possible changes.
Also, speak with top stakeholders during the initial phases of the program to determine what sort of changes will occur over the duration of the program. Doing so will inform your risk register, ensuring Project Leads have the knowledge they need to navigate those changes if they occur.
Again, these are just four of many program management best practices, but they all have one thing in common: They require you to gather extensive information. Remove any barriers that would prevent your program members from obtaining data, and you’ll eliminate half the battle right there.