My experience tells me that knowledge issues in schedule management fall into a number of broad areas:

• understanding the concepts,
• understanding the tools,
• long term versus short term planning,
• estimating and measuring, and
• risk.

Scheduling Concepts. In my time, I have struck numerous situations where people are expected to just "know" scheduling and get given the tools to do it but get no training in scheduling, let alone the scheduling tool. As extraordinary as this may seem, it would seem it is not unusual. If we accept this as a reality in some situations then the implications are that any training will need to cover general scheduling concepts, not just the tool. When this is done then training on the tool will have more impact. If it is not done then training on the tool could be wasted. Furthermore specific support should be provided to assist in the development of a schedule and the on-going analysis and maintenance of the schedule. This will reduce the need for staff to have in-depth knowledge of scheduling principles and will provide a ready base of knowledge for what is an appropriate estimate for the production of each product/work package. This support might also provide management with more confidence in the schedule in the first instance.

Understanding the Tools. But....even if staff have an understanding of the basic concepts there is still the challenge of understanding and using the tools and getting experience in those tools. Now not all projects need a high end scheduling tool. Indeed a table with a series of milestones can be sufficient, perhaps supplemented by duration data as well. The Agile Software Movement has a plethora of tools for managing the schedule elements of a project from the very simple to the slightly more complex. Whatever the tool is though, it should be accompanied by training, robust templates and on-site support and coaching (at least for a while or at least for the start of the project).

Long Term Planning. This is pure conjecture, but my experience is that there is a dearth of people who can plan "long term" because most are experienced in short term planning. (I would hope strategists or strategic planners would be better at this long term planning than project managers). People tend to plan a task, conduct a task and move onto the next task where they plan and then conduct it and close it. Any longer term planning is generally part of a cycle such as that which operations management often requires, apparel sales cycles aligning with the seasons or the annual budget cycles. However, in the project environment, there is no "cycle" as such, as planning often looks forward many years and then a project stops. This is quite a different paradigm from many contexts. This is perhaps also exacerbated by the fact that some projects suffer from a "staff cycle", where people move in and out of a project. Consequently, concentrating on "the now" rather than the future would need to be countered and the work experiences of many people are not necessarily transferable to the project environment. I guess the implication is that a change in planning "culture" might be required within your program of projects or the planning requirements need to fit the existing culture in some way.

Estimating and measuring. Estimating and measuring are two quite different terms but they have a common thread in the scheduling environment. If you don't keep historical scheduling data, you will find it difficult to get better at estimating as an organisation, because unfortunately the lack of historical scheduling data means that few consistent lessons can be drawn as most evidence is anecdotal. Accordingly, whatever scheduling system is implemented should contribute to the longer term objective of scheduling metrics which should permit your program to get better at estimating.

Schedule Risk. Risk in schedule management. I suspect there is a sort of "maturity model" type situation here in that the more mature and resourced the organisation, the better risk management is done. If you have the time and resources to commit to scheduling then you still may not have the time and resources to investigate and probe the risk inherent in that schedule. (As an aside though - that is a risk in itself of course.) Further, if schedule risk is considered then mitigation strategies are often not actually pursued or executed. Risk management often stops at the "listing in the Risk Log". Additionally, if you don't have historical data as I explained above, your margin of error on a schedule is likely to be larger as you are forever "reinventing the wheel" and forever starting from scratch. From a corporate or organisation perspective, this is a true "corporate risk". I also claim that risk management and schedule risk specifically, is something that the Program Manager should oversight. In a previous blog called Allocating a Vehicle (03) I discussed an example of a program level decision. Well, oversighting the schedule risk is another Program Manager function. That is different to oversighting the schedule. The schedule risk is about identifying the likely delays to the schedule and dealing with them (dealing with them should be the responsibility of the Project Manager of course). But the other side of the coin is to take advantage of the opportunities that will permit you to get ahead of schedule or to catch up at least to some degree. There are lots of techniques to give you these insights and a modelling tool like Risk Simulator (which I have used) will provide you with a sophisticated tool suite to identify these sorts of risks and opportunities.

The upshot of all of this discussion is that knowledge on schedules is not universal. Even trained and experienced project managers often don't get the chance the do scheduling properly, let alone the "accidental" project manager. But if your organisation expects scheduling to be done properly, then the commensurate knowledge needs to be developed and retained.