Program Management

Large organisations now have many projects in progress or ready to start. They range from small and cheap to large and expensive, with many different drivers. Some projects may be driven by survival, or regulatory requirements, or staying competitive, or reducing maintenance load. Choosing a subset of projects which guarantees long term survival and maximises the effective return to the organisation is a problem of Portfolio Analysis, complicated by the interaction among the projects - they are not independent, but are competing with each other for existence, for resources, and for life of their outcomes. We could visualise the interaction of the existing infrastructure with projects in progress and being planned as a diverse ecosystem, with many of the same management problems.

There is a whale of a project out there, which we will need to accommodate somehow, so better start producing the little projects - the krill - it will need.

There are predator projects - some large, some small - which will eat other projects or their outcomes. This is no more than obsolescence of systems and their replacement, but it gets complicated when we have multiple layers of infrastructure at various stages in their life cycle.

Some interactions are more complicated than mere gobbling up of another project outcome - one product may sting and drive away the market for another product.

Some projects are like flying fish - they lob into the mix from nowhere without warning and force re-evaluation.

Some projects are small and show a quick return, but their outcomes will be devoured by other projects - we could bring out a new highly competitive product, but the infrastructure it uses is heading for the scrap heap.

There are some projects which are so large that they require careful preparatory work - the acquiring of new skills, the slow buildup of infrastructure so the sheer size can be handled by the organisation.

The increasingly rapid changeover of technology is the main cause of the addition of a Program Management layer between Strategic Planning and Project Management. Waves of technology that were separated by twenty years are now separated by two years, so there are decisions to be made about which wave to miss. The other cause is the increasing globalisation of business, so even an organisation staying well inside its business area is confronted by an expanding range of possibilities.

Program Management acts as the pivot between the strategic objectives, the projects to reach those objectives, and the capital expenditure on those projects. Program Management is just as much about deciding what the right spend is on new projects as it is about allocating that spend effectively. This means the strategic objectives of the organisation should be in a time/cost plan that can be mapped against individual projects and clusters of projects, rather than the objectives merely being descriptions on paper.

Because Program Management has start/stop control of projects, its users are drawn into the preparation of project submissions, and may need to introduce a variability into those submissions so that appropriate choices can be made at the end of the select/cull cycle.

Different organisations have different emphases on various aspects of Program Management - case studies that cover Banking, Defence Procurement, Telecommunications focus on some of these aspects.

Why New Tools For Program Management

Program Management requires a flexibility of planning that both Strategic Planning and Project Management do not have. In Strategic Planning, usually only a few highly simplified scenarios will be evaluated, with complex interdependencies ignored as they would make the evaluation of the scenarios too difficult - the choice has to be overwhelming before it is adopted. The tools for Strategic Planning are spreadsheets and Financial Modellers, unsuitable when projects are moving around in time and being turned on and off.

The current tools for Project Management often have a multi-project capability, but assume that everything is to be completed, even if delayed for lack of resources. There is no facility to look at alternatives, or even describe them. The main emphasis in Program Management is to decide on which subset of projects is to be selected, so there is a need to describe alternatives, clusters of projects, cannibalisation of markets and other interdependencies relying on more than time and resource.

ORION Program Management uses a Constraint Reasoning approach (CRM for short). CRM can provide a realistic description of each project and its interaction with the organisation and with other projects. Any form of constraint can be modelled, not just time and resources. The basis of the program is a project represented as an activity, with its start date, finish date, duration, predecessors and resource usage. Ranges of values are used for start date, duration, resource use, and logical connections can be added between any of the elements of the plan. The CRM program plan extends to cover much more of the total planning function, planning that up to now was done on paper or in people's heads.

Alternatives and contingencies at multiple levels can be embedded, allowing the Program Planning team to model the complexity of the real situation, and the Program Manager to assess the outcome from current and future program budgets. The program allows viewing from multiple perspectives, and allows individual stakeholders to express constraints on the program from their viewpoint.

Do We Need Better Planning Tools?

One difficulty with plans only on paper is that inconsistencies creep in. If you look at one aspect, "We could do this or that". Look at other aspects, come up with alternatives that may very well be inconsistent with planning in the first area. During the evaluation of the program, an eye has to be kept on strategic imperatives, future choices, risks in current choices. Decisions can be made which close off alternatives other people were relying on to avoid problems, alternatives that existed only in their heads because the program could not accommodate or represent them. Mechanisation of more of the program makes things explicit, helps to eliminate inconsistencies and shows the effects on future alternatives that current decisions have. Just the fact that more of the plan is formalised and explicit allows more people to contribute to the plan and make it better.

The CRM plan will need more thinking about, but that forethought will pay off in avoiding dead ends and assessing costs of alternatives, or leaving decisions to be made later, when better information will be available - all elements of the CRM plan. A significant weakness of is the need to spell out everything in precise detail - unrealistic in a project where there is development as you go along.

The more complex aspects of the plan are easily expressed in terms of constraints using the ORION Textual or Drawing Editors. The Drawing Editor in particular provides the ability to point at elements of the plan, and connect them through assemblages of analytic operators to form constraints.

The environment that a knowledge network system can provide is exceptionally flexible, because all of the knowledge about the program is continually "live", and can interact with the user, as well as grow and change with user interaction.

The user has several graphical interfaces available to work on the plan, the main one being a Gantt chart of the projects involved in the program. Behind the Gantt chart, and controlling the positioning of the projects, is a knowledge network. It represents the complete logical structure of the program, incorporating all the projects with their costs, risks, resources, constraints and alternative ways of doing things that are in the current plan. The network is carrying tentative information through its connections, and the connections themselves can change as the tentative information changes.

Using the tools provided with the chart, the planner can push the projects around, or add or remove cash and other resources anywhere in the program, or switch alternatives on and off. The Linker allows you to play with predecessor-successor relations here to get the effects you want, after the obvious ones have been added in the Project Editing window.

After each user action, information flows through the new network structure added as a result of the action. The chart, resource plot and display of costs are updated to represent the new state of the network. If a logical error, or inconsistency, is encountered while updating the knowledge network, the user can examine the site of the inconsistency, work out ways of avoiding the problem, and the plan then reverts to the previous state. The user can see a list of the changes they have made, undo any of the changes, all of the details of the project plan reverting to the state before the change.

The Graphical User Interface, or GUI, to the project behaves as one would expect. The effects of any change are immediately shown to the user - the network represents the complete logical structure of the project, so no effect is overlooked, or delayed until a program runs. The planner is not limited to changing parameters for a program, but is here changing what in conventional terms would be the CPM algorithm. Instead of struggling with several versions of output from a program, and trying to reconcile the good features of several run outputs, here the network structure itself can be smoothly changed in the desired direction, while any missteps are simply undone. The planner can be sure that nothing has been done which will later need to be undone because it violates some contractual obligation or resource constraint.

The main focus of the planner's interaction is to add constraints that represent new limitations, and to fix gross resource hot spots that would prevent any plan at all from being obtained. When the planner is satisfied that the plan represents all of the projects to be planned, including alternatives where appropriate, and all of the constraints on the plan, the automatic program scheduler can be started. This has multiple goals, ensuring predecessors, minimising the cost, meeting ROI constraints, maintaining feasibility. It will normally begin by looking for the point of maximum resource overload, and attempt to reduce that overload by hard booking a project. Hints embedded in the network provide guidance as to when the project should start. The allocator can choose among several alternatives by trying each in turn, noting the cost and the severity of any new resource overload, and then choosing the best alternative. Hard booking will usually have the effect of making other projects undo their tentative bookings at the point of conflict, and reduce their start ranges. The automatic scheduler then searches for the new point of maximum resource conflict, and repeats the process. If hard booking causes an inconsistency, the program scheduler undoes the booking and tries some other alternative.

Automatic scheduling of the projects in the program is not being done through a clever algorithm operating on the data the planner has supplied, but instead is using the structure of the knowledge network, and allowing the interaction of the constraints, the resource usages, and any other logic the planner has implanted in the network. Its method of undoing its actions is the same as the planner achieves by pressing the Undo button. As the automatic scheduler progresses, the Gantt chart and resource plot are updated to monitor its progress. The scheduler can be interrupted, and changes made, even new constraints added to drive it in a particular direction. This ability, to interact with the user while in the middle of its planning, comes from the knowledge about the project program being expressed in a network of operators, instead of in a stack of procedure calls in a scheduling algorithm.

The graphical tools provided for manipulating the projects are used to add new constraints to the network, but they are relatively simple constraints, involving reducing the end points of a range, or linking starts and finishes of projects together, or dumping resources at a particular spot. To add more complex constraints or new alternative activities, the Drawing Editor or the Text Editor can be used. Either of these tools allows the planner to connect as many nodes in the network as desired, using simple or complex logic. Complete new potential projects can be created, interacting with the existing projects and resources. At the limit of interaction, the planner can even temporarily "hot wire" the knowledge network, to observe an effect or get around a particular problem without going back to the detail of the project plan's creation.

The project program network that you build using Constraint Reasoning has many more uses than a CPM network or simple planning board. The project planning network behaves much more like the real plan, and can be used as a simulation model to determine the response of the real plan to various effects, decisions, failures. Some of the uses:

You or others can use it as you would a CPM plan, just to add up the durations and level the resources.

You can switch alternative projects on and off manually, and observe the effect on the program time and cost, or run the Allocator to find a viable resource limited schedule for any combination of projects you have set up.

You can automate the switching on and off of alternatives, allowing the system to find a lowest cost/shortest time/lowest risk solution, where you have set up risk profiles, cost versus time relationships and resource costs and limits.

You can put in cost functions instead of hard resource limits, so the Allocator can "buy" extra resources at a cost, and find the lowest cost/shortest time within these more realistic limitations.

You can use a Monte Carlo analysis, where projects have a probability of success (20%, 90%, etc.), the system repeatedly throwing the dice to generate random numbers to determine success or failure of particular projects, and then solve the resulting network for the particular set of random numbers. With many runs, this becomes an excellent way of doing sensitivity analysis on a complex program that has many alternative paths and activities with completion risks.

If a new project has to be forced into the program, the plan can support "planning under pressure", where the snapping of alligators' jaws makes it hard to think clearly. Critically assessing the alternatives to dig yourself out of a hole is a good way to make sure the hole doesn't get any deeper.

An advantage of the knowledge network approach is that you can wrap more analysis around the program model at any time, and add more detailed logic inside the program as well. The model is extensible in any direction at any time.