“The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes.” – Kent Beck (2000), Extreme programming explained: embrace change. p. 28.
If there are changes to the scope at the program level, understand how to manage the change. It is best to leave project level changes to be handled at the project level.
What is change management? Well, it is the process of understanding the need to re-align the program to a change in organizational strategy or a market need and analysing the impact of the change across the program on constituent projects and sub-programs. You have to decide if the RoI and benefits delivered warrant implementing the change and then drive the systematic implementation of this change across the program.
Ensure also that you are clear on what a program change is as opposed to a project change. There is no point in your worrying about managing a change that needs to be handled in a project by a project manager (unless of course, the project manager comes to you for help). And how would you judge whether a change is a program change or a project change? Is it a change in a strategic direction? Is the change to address a program level risk? Is it based on market / environmental factors? These are sure indicators that you are dealing with a program level change.
Change requests may come from project level (bottom up) or from an important stakeholder (top down). It is also possible that you may need to proactively initiate a change request if you assess that program objectives/benefits are jeopardised, say, due to the identification of new program level risks.
When looking at managing change you have to look at three dimensions: traceability, dependency and experience. Traceability is tracking the effect of and managing the change top down, that is, from the charter level to the requirements to the design and so on up to the testing and documentation levels. Dependency is tracking the effects of and managing the change horizontally, that is, between the different consistuent projects and sub-programs. Experience is using the organisations collective experience in looking at deciding the requirement of the change. Some of the aspects you may look at are: Does the change requested make sense vis a vis the organisation’s strategic objectives? Can the change be justified as a risk mitigation move? Will there be budgets available to implement this change and who will fund it? Why is this change being requested? What would be the technical fall-outs of the change (Would the overall performance of the system suffer?) Will program milestones be affected? Will you be able to ramp up the required resources for implementing the change? What are the risks of making the change? All these are important question you need to ask and get answers for before deciding that the change will be implemented.
It is very important that you keep a lookout for triggers that are sure to cause a change to be requested in your program. These triggers include:
- Environment in which the system is used is changing
- Customer’s competitor’s products changing
- Customer’s ultimate customer’s needs changing
- Customers funding being cut
- New technology (impacting the system) on the horizon
- Change of top-level decision maker / re-organisation in the customer organisation?
- Change in interfacing systems
If you see any of these triggers being set off, you need to prepare yourself for getting a change request. It is always easier to plan and implement a change if you are able to anticipate it and prepare for it.
The key learnings that I have imbibed from my experience are that you need to clearly be aware of the organisational (customer) strategy to understand the impact of the change vis a vis the strategy. You need to be technically (or technologically) savvy to understand the technical overtones of the change and to discuss the impact intelligently with the project managers and team leaders under you. You need to be proactively aware of possible developments due to “politics” in the organization.
You also need to reconcile yourself to the fact that sometimes you will be the bearer of evil tidings. You are the one who will need to communicate the effects of the change to the key stakeholders.
Question: What are the situations where you, as program, manager would proactively initiate changes in the program?
7 Tips for Effective Program Management (A practitioner’s approach)
Tip 1 – All the world’s a stage – Understand your role
Tip 2 – Don’t fail to see the forest for the trees – Understand the big picture
Tip 3 – They hold all the stakes – Map them out
Tip 4 – Use support structures and technologies to your advantage
Tip 5 – Skating away on the thin ice of the new day – Keep your eye on the program risks
Tip 6 – Dot your I’s and cross your T’s – Understand the program commercials and contracts clearly
One Response
Good article.
No picture, came here from newsletter.
also minor ” be clearly aware” or “clearly be aware”?
And font is not very readable, some kind of an outline font used, oh blimely it’s looking OK now, it fills up after sometime.