ORION Program Management provides tools to permit a flexible and effective approach to the management of a large organisation's portfolio of projects. ORION provides the ability to describe the organisation's overall strategic objectives, the complex interactions among projects, the changing cost and risk factors as projects move around in time or cease to exist.
The planning and scheduling of a diverse set of projects, all competing for resources and survival, is a complex and dynamic problem. Projects need to be monitored through their life, and their parameters changed or their existence terminated if strategic directions alter, or the current directions are not being met by the mix of existing infrastructure, running and planned projects.
Up to now, the information about complex interactions was kept in people's heads, because there was no place for it in the plan. ORION Program Management tools handle complex interactions simply and efficiently, greatly increasing the scope and effectiveness of planning.
The Program Management planning tools sit on top of the ORION Knowledge Network system, providing a direct representation of analytic and non-analytic language elements without the mysteries of programming a computer.
What Is 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.How Does ORION Program Management Work
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.
Some Constraint Reasoning tools can only move from one consistent state to another. This would be fairly useless for Program Management, where you often need to jump from one subset of projects to another, or change the constraints that forced you into the subset in the first place. ORION will support the decision-making needed to determine what new state you should move to, and then maintain Constraint Reasoning on that new state.
Some Ways That Projects Interact
The considerable modelling freedom provided by CRM allows the inclusion of many different interactions in the program, modelling which will allow decisions to be made by the time and cost logic embedded in the program. You may develop a preference for keeping much of the variability in the projects themselves, or keeping each project relatively simple, with the variability expressed in the program.
Sometimes you are not sure which projects will be selected, so cannot decide between two or more potential and mutually exclusive projects (perhaps different technologies to produce similar outcomes). One project might be shorter but more expensive, or involve development and have higher risk, but have longer in-service life. If other activities will cause the project to be delayed, there is no point paying a premium for a time saving that won't materialise. The logic deciding between the two projects can be built into the program, and draw on as many influences as you wish.
Some projects in the program may have risks associated with them - risks that they may not succeed, or that the duration becomes extended. Human rated equipment, such as cars and planes, has many parallel and backup systems, so it makes sense to have some backup and contingency projects when planning mission-critical projects.
Contingent projects are embedded in the program, ready to be scheduled if failure occurs on some primary project. As distinct from backup projects, the contingent project only starts if failure has occurred on the primary project, which may be an alternative of some other project. If the primary project succeeds, the existence of the contingent project is suppressed.
Interaction Of Capital Expenditure and Projects
With most planning tools, a cashflow can be experimented with while activities are fixed in time, or activities can be moved about with primitive cashflow output. Orion Program Management allows you to manipulate the projects and observe cashflow, or constrain cashflow and observe the effect on different projects as the cashflow pushes them around. Other planning constraints such as NPV may be added to the plan, coming into effect only when the variability in timing reduces.
The Planning Environment
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 User Interface
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.
Using The ORION Program Management System
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.
A good plan requires adequate planning detail, and appropriate behaviour built in so it responds realistically to change. As you work with the plan, a model of the program is also forming in your head. The more closely the plan simulates the strategic objectives of the organisation, the more subtle and sophisticated your mental model will be, so you can continually choose the right projects.
Complex financial analysis is easily embedded in the program description, not tacked on as a separate spreadsheet. You can constrain the cost of the program at each stage, and so constrain the duration, the system seeing through logic about penalty payments for late completion so that cost and duration are directly linked.
The transmission of tentative information through the financial analysis and the choosing between alternative capital expenditure scenarios to meet strategic objectives is another example of CRM adaptability.
The swirl of activity in the network model as changes occur mirrors the swirl of activity and change in the program. The ability to embed logic within the model, and have it participating in the swirl of activity, is unique to ORION.
Accurate and Responsive
A Program Management system needs to be accurate in terms of its assessments, and responsive to change. Sometimes the change is slight, a few project costs change, sometimes the strategic direction alters, necessitating the whole structure of the plan being hacked around. Without the Program Management plan, the Program Manager has to grope in the dark with virtually no useful input from the formal plan.
A CRM project plan, which is continuously "live" and interactive, and will immediately display any inconsistencies in it, allows the planner to make rapid changes to the plan, knowing that the changes are not introducing errors. The CRM plan is much more of a simulation of the program than a means of calculating the minimum total duration or cost in any time period.
The program environment is much more volatile than the projects being controlled. Delays in understanding the effects of changes increase the instability of the overall control and decrease the willingness of the planners to explore alternatives.
The ORION Program Management System can provide accurate and timely information, while allowing its planning model to be drastically changed to reflect new goals, priority shifts and other new constraints on the program. Application extends from the conceptual end of planning to the detailed monitoring of individual projects.