Since 1987 Xybernaut has been working with Department of Transportation (DOT) organizations helping them with program, project and resource management. Xybernaut Solutions is a small business located in the Northern Virginia area that specializes in designing, developing and implementing Program/Project Management Systems (PPMS) for DOT organizations. Our focus is on developing and implementing tools to meet the exact specifications of our customers at the different levels of the organization. We not only implement a new system, but we also provide customized training and support for all software and processes. This ensures the success of our clients and fosters long-term relationships. Xybernaut consultants have performed evaluations of program management processes, systems requirements definitions, and C/SCSC contract deliverable systems definitions. Our expertise covers the entire spectrum of process definition, application requirements analysis, database design and specification, programming, testing, implementation, training, documentation, and application configuration management. Xybernaut works to "augment" internal resources and skills, and to transfer our expertise to internal permanent resources as soon as possible.

The Xybernaut Approach

Xybernaut designs, develops and implements the PPMS around program, project and resource management processes that guide the organization to meet their business goals. Our conceptual design is based on the "Xybernaut Approach" to program management. This methodology is a consolidation of years of experience in developing, implementing and supporting management systems in both the commercial and government sector. Xybernaut resources have been instrumental in developing scheduling and planning systems ranging from the Alaska Pipeline project to the development of the integration management system used by the Space Station Freedom Program. A fundamental premise of the Xybernaut Approach is that in any DOT organization, there are three distinct layers of management, Program Management, Project Management and Resource Management, each with its own unique requirements and responsibilities. The objective of the PPMS is to provide the tools and controls necessary to manage these unique information requirements at the different levels.

Program Management

At the top of the enterprise scheduling hierarchy, is the Program Management layer. At this layer, senior management is coordinating and establishing the overall program goals and objectives. On a practical level, this typically translates into resource skill and funding management. Program Management users are primarily concerned with the key project milestones, interface points, and summary activities, across all projects with the desire to understand what skills are needed for the program to succeed and when will the money be spent. Program milestones typically correlate to funding obligations and/or work authorizations. When a project schedule is first created, the project milestone reflects an agreed upon set of target dates which are used to evaluate the progress of a project and to plan the funding obligations. When a project milestone slips or is projected to slip, the Program Management team needs to know on a timely basis, and needs information to help them assess the impact of a slippage. Interface points represent critical interfaces between projects. In the case where one project must provide some information or product to another project, there must be a cross project interface. By centralizing these interfaces, the program management team accomplishes two objectives. First, it focuses visibility on these critical scheduling items. Second, it provides a single channel or data source for all integration points for all organizations. This streamlines updates between the various multiple project organizations. Summary activities allow the Program Level to retain some visibility into the detail project schedules without getting bogged down in the details. This is usually required to maintain credibility for the detail schedule updates being reported by the various project managers. To support this type of conflict analysis and assessment, the management of the milestone data can only be effectively controlled using database functionality. While it is desirable to have a Critical Path Method (CPM) scheduling tool to plan or forecast the milestone dates, CPM tools cannot be allowed to automatically change program milestone dates every time there is a schedule update. Changing program dates (outside of established tolerance ranges) must be a conscious decision on the part of the project management team in concert with program management goals.

Project Management

Below Program Management is the Project Management layer. At this layer, Project Managers are concerned with the long term planning for all of their projects. The objective of this layer is to be able to forecast or plan the entire project scope, schedule, and resources at a skill level. Project work plans include the summary activities, logical relationships, and resource requirements required for strategic planning. Project Management is the most common area addressed by CPM tools. When a project schedule is first created, the project milestones dates reflect an agreed upon set of target dates for the project which strive to meet the program goals and objectives. These target dates, along with any thresholds, effectively provide the date range in which all project work must be accomplished. The individual project activity dates then provide the target windows for the next layer of scheduling described below.

Resource Management

The bottom of the scheduling hierarchy is Resource Management. The Resource Management layer is where work is actually being performed and controlled. What distinguishes Resource Management from Project Management is the level of detail and the functional grouping across projects. The level of detail in a project activity is intended to support overall project planning. The level of detail for resources is intended to support work control within the functional groups. As such, project activities are typically broken down by functional managers into multiple tasks, which are released to the members of the functional group for execution. Regardless of how many tasks an activity is broken down into, they are all constrained by the target window as established by the Project Manager. When tasks slip outside of the activity target window, the Project Manager needs to make a conscious decision to accept the change rather than have the CPM algorithm automatically accept the update, and potentially alter the project schedule. The other distinguishing feature of Resource Management is functional groupings, which reflects the fact that most projects require different functional resources over the life of a project. This requires communication between Project Managers and Functional Managers to understand the supply -vs- demand of resources. In a day to day view, Functional Managers need to understand what skills are needed by Project Managers and how long they are needed. They will need to have a view into the database to understand what resources are free to meet that demand. This view comes from the project plans with the task dates, so that there is consistent information flowing from Project Manager to Functional Manager based on the changes that occur to the project plan through out the life of the project. This allows the Functional Manager to set the proper expectation for Project Managers as to when certain resources with desired skills will be available. Tasks also tend to be non linear or limited sequential in nature. As such, while a CPM tool is desirable it is not a firm requirement. The primary advantage of using a CPM tool for task management is to support resource scheduling and to provide a graphical representation of the tasks.

Common Problems

Most planning organizations rely heavily on commercial-off-the-shelf (COTS) sequence-driven scheduling systems. These systems use the Critical Path Method (CPM) model for scheduling. All too often in large organizations, business procedures are modified or driven by the capacity and capabilities of the scheduling tool. The tool then becomes the driver for the business instead of the business being the driver for the tool. At the heart of this problem are three issues. First, a large portion of the program management model is not CPM driven. Second, most COTS packages do not address the control points between the different layers of management, or between different organizations at the same levels. Third, the COTS tools are the limited in their ability to group projects for either Program Management or Resource Management analysis. As such, an inordinate amount of time and effort is spent in trying to make the business and the tool sync together, often with unsatisfactory results. Another common problem is the misconception that aggregation of detail schedule data is equivalent to integration. This leads to two problems. First, it ignores the necessary control points between the levels of management. Second, managers tend to unnecessarily overload the active schedule database with long-term detail data. Scheduling all daily and/or weekly tasks for a project covering many months or even years is an unnecessary and mostly inaccurate exercise of planning due to the inevitable changes that occur during the life cycle of a project.

The Database Solution

The key to a successful PPMS is to support the program management processes as they guide the organization to meeting their business objectives. As described previously, achieving integrated scheduling in a program management environment is a sophisticated problem. The PPMS should integrate the information necessary for the different levels of management. This simply cannot be addressed solely by CPM scheduling tools. The only way to accomplish this is to develop a centralized core database designed to support the unique types of information needed at each level of management. The database must also support the ability to map the information points across the different levels. It must be able to support information roll-up/roll-down and conflict resolution based on these mappings while interfacing with the selected CPM scheduling tools to perform automated scheduling. In essence, an effective integrated PPMS is a database application supported by specialty tools like CPM schedulers and graphic and reporting engines. The systems architecture must be designed to address these enterprise requirements. Using this database approach accomplishes several key goals. It allows the system to maintain both data and functional security. This minimizes some of the key problems associated with closed code "off-the-shelf" scheduling tools. It allows for greater data security and integrity. Each import and export process would be tied to the overall system security scheme, and extensive validation is performed on the data prior to loading it into the system. Exception and date conflict reports can be generated and posted to the appropriate users. It makes the core scheduling system less susceptible to disruptions caused by new releases, or even replacements of the selected CPM scheduling tools. Since the database model is based on business requirements first, the primary data attributes associated with the management data are driven by business needs. Additional attributes are added to support selected CPM tools only if they are required to allow the tool to execute properly.

Conclusion

As the result of using the "Xybernaut Approach" to implementing a PPMS, both government contractors and commercial organizations have greatly improved their ability to manage work, cost and resources. Customer specific applications capture and maintain information necessary for managers at all levels of the organization, giving them the power to make the informed business decision. The net result is a better product delivered to their customer on time and within budget.