Picture source: hdwallsource.com
Make an effort to understand how the program fits into the big picture of the customer. Normally programs are launched to implement or support the implementation of a strategic objective. Understand how your program ties to this objective. What is the time-frame and what are the outcomes? How does your project deliver benefits that can support the outcome of the objective?
Knowing this will help you when you negotiate with your customer and other stakeholders. Changes and other initiatives coming in midway can be measured against the yardstick of the objective. Any changes and other initiatives that do not directly benefit the furtherance of the objective need not be considered within the current scope.
Knowing the objective is also important for motivating the team. When the team sees the connection between the results of what they are doing and the outcomes of the objective, it gives an added impetus to their enthusiasm for the work.
The Program Charter is the key document that you should have in a program. This will tell you what your authority is and what your responsibilities are and what is expected of you. It authorises you, on the authority of the Program Governance Board (PGB), to execute the program on its behalf. You can wave this in the faces of departments like admin, HR etc. to ensure that they provide the right kind of support to the program. It also defines the scope of the program which (definition) helps you negotiate with the customer throughout the course of the program.
Many programs start out without this all-important document. When you take on a program, if there is no charter, insist that one is created and signed off by the PGB. (The PGB should include customer representatives)
The charter necessarily should contain the following:
- Scope of the program
- Justification, benefits and Return on Investment (RoI)
- Milestone based deliverables
- Indicatory time-based funding availability
- Risks and mitigation strategies
- Governance aspects (incl. reviews, reporting) and Key Performance Indicators (KPIs)
Observe the power of this document. In a few pages, it sets out clearly the parameters of the program. Once the program charter is available it can form the basis for your program plan and other documents and your dealings with your stakeholders.
Another key factor is to clearly understand the stage the program is in when you are called in to manage it. Is the program in the starting stage? Or is it in the on-going stage? Is your responsibility to successfully wind up the program? Have you been called in because the program is in a bad state and needs to be salvaged? Or is it that the program needs to be ramped up due to heavy business input?
The challenges of and the skills required in these different situations are very different. If the program is just starting you need to work towards setting up the program: acquiring resources, setting up the structures, getting the charter prepared, putting together the governance board, hiring key staff etc. whereas if you have been called in to salvage a sinking program you need to re-energise demoralised staff, maybe look at cuts in staff and consolidation of resources, relook at the benefits, plans and deliverables etc. If you are there to ramp up a program, you need to look at the scalability of the program and if it is not currently scalable, see how you can change the designs and structures to make it scalable and also look at accelerated hiring and acquisition of resources.
It is important that you understand the technologies and the technical aspects of the program you are dealing with. You may not be an expert in these technologies, but it is critical that you know the basics and the big picture of the technologies so that you can have an intelligent conversation with your stakeholders. This is important for estimation, for costing, for risk assessment and for change management. Some of your stakeholders will be highly technical people and they may not take you seriously if you are not able to understand, at least superficially, what they are talking about. It will be difficult to do proper reviews without some knowledge of the technologies you are dealing with. I will not go on too much about this, but I suppose you get the point.
Question: What kind of dashboard would you design (ie. what parameters would you look at) so that you can monitor your program properly?