Information systems design for project management
a data modeling approach
Computer-based information systems for project management have become essential to managers in their project planning, control, reporting and decision making tasks. At first restricted to large organizations possessing a substantial computing infrastructure, these systems have now become available to all organizations and all managers through the emergence of easy-to-use project management software for the personal computer . As an alternative to existing software packages, organizations and managers can develop custom project information systems to suit their own specific needs, particularly in regard to prospective information as opposed to the retrospective orientation of many packaged systems. As defined by Cleland and King [4, p. 435], the basic function of a project management information system is to provide managers with “essential information on the cost-time performance parameters of a project and on the interrelationship of these parameters.” In addition, the structure of such a system should be
a) sufficiently flexible so it can be modified to suit the unique needs of the individual project manager,
b) adaptable to many differing projects,
c) adaptable to differing customer information requirements.
The basic effectiveness of a project information system can then be evaluated by its attainment of the preceding objectives. Often-cited problems with custom and packaged software include the inadequacy of standard report contents and formats for specific and varying decision making tasks, and the slowness and cost of the system modification process as new information needs arise coupled with the lack of understanding of the information system by managers, which results in low or improper usage.
In this article, presented first is a framework for understanding the nature and role of an information system within a project management system. Next, two approaches to the design of information systems are compared, one being the traditional approach based on determining the managers’ information output requirements, the other being the more recent data-based approach which focuses on building a conceptual data model of an object system. Finally, the use of such an approach by one of Canada’s leading consulting firms to provide for more effective management of its projects is examined.
Information Systems in the Project Management Context
As a subsystem of the project management system, the information system is subservient to the attainment of project goals and the implementation of project strategies. Thus, one cannot define the information system without first describing the overall project management system which constitutes its immediate environment. As shown in Figure 1, a systems framework for project management consists of three subsystems: the decision system, the information system and the project life cycle which constitutes the “object system” for the other two.
As organizational entities created to cope with the dynamic nature of systems, projects may be characterized by using a life cycle approach. This approach views project objectives, plans, concepts, solutions, specifications and resources as evolving through various stages. As the project life cycle progresses however, the behavior of the critical cost, time and performance parameters must be oriented and regulated throughout the various stages by a decision system possessing planning, organizing, controlling and leadership capabilities. In essence, the decision system is constituted by project managers who subject information to analysis and synthesis, utilizing techniques and methodologies, to evaluate alternative decisions in the light of project goals and strategies. Note that while the decision system is distinguished from its object system in Figure 1 to better identify the information system’s role, the first two are basically inseparable in project management. Also, not shown in Figure 1 is the human subsystem which permeates every aspect of a project through leadership, creativity and interpersonal relationships.
Figure 1. The information system within the project management system
In view of this, the basic role of the information system can be seen as that of linkage between the object system and the decision system . This role includes the following four primary functions:
- Capturing data as elementary information on project operations and on the status of the project environment;
- Storing this data for subsequent processing or transmission to the decision system;
- Processing this data into more elaborate information to assist the decision system in its task;
- Transmitting information in its elementary or elaborate form to the decision system.
This framework stresses the fact that the information system and the decision system are not the same, and that the former cannot act as a substitute for the latter, but rather as support. The type of support can also vary, i.e. from a more passive type based on transactional documents and printed reports to a more active type based on interrogation and analysis through man-computer dialogues (e.g. “what if’). Note also that this framework does not in any sense preclude all or part of the information system from being informal (vs. formal), manual (vs. computer-based) or even personal (vs. organizational).
Going back to the previously cited structural requirements of a project management information system, one can view the design of such a system as posing two basic problems. The first problem relates to the identification of the specific data to be captured and stored in order that the system be sufficiently flexible and adaptable to differing projects, managers and customers. The second problem relates to the logical structure and physical organization of the data so as to make it widely and easily available while satisfying security, integrity and efficiency constraints.
Traditional Approach to Information Systems Design
The traditional approach to information systems design has focused on the determination of the users’ information requirements. As indicated in Figure 1, this approach emphasizes the complete and detailed specification of the system’s outputs as the starting point for the design process. This can be accomplished in various ways such as directly asking the user, or indirectly by deriving the information needs from an analysis of the users’ decisions or critical success factors .
Once this is done, the information system is designed by inferring the data which must be captured and stored, and the nature of the data processing for the output specifications to be met, subject to the constraints of the technology employed. It appears more and more, however, that systems designed in this manner are not as effective as they should be, particularly in complex and changing environments ; the basic reason being that it is illusory to expect a manager to adequately define his information needs prior to the actual encounter of a specific problem . The fuzziness and instability of individual information requirements is compounded by factors such as the user’s cognitive style (analytic vs. heuristic) and past experience, and by having to coalesce these individual requirements into one common set of output specifications.
Thus, information systems designed in this manner are often not truly managerially relevant, leading managers to develop their own personal systems or to ask for frequent modifications to the existing system and for more flexibility , This in turn leads to higher operating and maintenance costs; in particular, as the input and processing depend entirely on the output specifications, changing these specifications often-times leads to inefficient and costly modifications of all related data structures and programs.
Data Modeling Approach to Information Systems Design
Returning to the information systems model presented in the first part of this article (Figure 1) suggests an alternative to the preceding approach. This more recent approach, often called a data-based or data-driven approach, focuses on the information system’s inputs rather than outputs as the starting point for design. The principal design task is thus to build a data representation or model of the object system; this can be done without having to know the data’s future uses in a complete and precise way, i.e. without having to first identify and synthesize the managers’ information requirements.
The selection of the data to be structured and stored is based on the examination of the project life cycle as shown in Figure 1. The evolving state of objectives, plans, concepts, solutions, specifications and resources through the various project stages generates transactions which constitute the basic source of data. Once this data is identified and structured, data capture and storage procedures are elaborated so that the resulting database can be kept up-to-date. Finally, data access and processing procedures can be designed on demand to allow decision makers to interrogate the database, obtain information in various forms (reports, terminal displays, graphics) and analyze this information (costing, scheduling, performance evaluation). Experience with this approach suggests that even though managers’ information needs change, these needs can be met by differing combinations of the same basic data if the content of the database truly mirrors the evolving state of the object system .
Data Modeling Methodology
The success of the data-based approach thus depends mainly on building an adequate conceptual data model of the project life cycle. We shall see in the next section how this was done at a leading Canadian consulting firm; however, the data modeling methodology used in this example must first be explained. The most widely used data modeling methodology is based on Chen’s  “entity-relationship” model and comprises the following steps:
1) Build and validate a conceptual entity-relationship data model of the object system (independently of any computer-related consideration);
2) Derive the logical equivalent of this model in terms of existing database management systems (“relational” and “network” DBMSs );
3) Physically implement the logical model through the creation of database “files” and “records;”
4) Implement the programs required to update and access the physical database.
The first step consists of analyzing the object system and identifying the nature of its data objects (entities) and of the interactions (relationships) between these data objects. A systems analyst could do this by various means such as interviewing managers, observation and analysis of existing files, procedures, forms, manuals, charts and documents. The result of this analysis is formalized by an entity-relationship diagram as shown in Figure 2. This data formalism is a representation of
- The individuals, objects or “entities” on which data is captured and stored (represented by a rectangle);
- The associations or “relationships” between these entities, pre-existing or created by the occurring of events, on which data is captured and stored (represented by a circle);
- The “attributes” of these entities and relationships which specify the nature of the data to be captured and stored.
Figure 2. Example of an entity-relationship (conceptual) model
For example, one can see that the EMPLOYEE entity is related to the PROJECT entity by the ASSIGNED-TO relationship. The attributes of EMPLOYEE are EMPL-NO, EMPL-NAME, EMPL-AGE, the first being preceded by an asterisk to indicate that this attribute is the “identifier” or “primary key” of the entity. The identifier is an attribute whose value is unique for each “occurence” of an entity or relationship. (BT410, Brown Tom, 46) being an occurence of the EMPLOYEE entity, i.e. a set of values describing a specific employee. The identifier of a relationship is always the concatenation of the identifiers of the entities who participate in the relationship, thus it is not shown on the diagram; for example, if (PN42, Hoover Dam) is an occurence of the PROJECT entity, (BT 410, PN42, 64) would be an occurence of the ASSIGNED-relationship, the last value refering to the PROJ-HRS-WORKED attribute of the relationship. Note that it is possible for a relationship to have no attributes other than its identifier.
The numbers in the diagram specify existence constraints on a relationship; they refer to the minimum and maximum number of times the same occurrence of a relationship. In the example, this means that at one point in time an employee can be assigned to no projects or at most to three projects, and that a project must have at least one employee assigned to it and at most n employees (n meaning greater than one). The arrow is meant to eliminate any ambiguity on the meaning of the relationship; in the example, the relationship should be read as “an employee is assigned to a project” and not “a project is assigned to an employee.”
While a complete exposition of this modeling approach is beyond the scope of this article, it is important to note that the formalism is simple enough so that managers can understand it within a few hours, and thus participate actively in the design of the database. Once the model is defined, it must be validated by testing to demonstrate that it can satisfy a representative sample of the envisioned uses of the information system. Past experience has shown that if all the properties of the conceptual model are exercised at least once or twice during validation, future uses will generally not require major changes to the model’s structure.
The next step involves transforming the conceptual model into a logical model appropriate for implementation with existing database management software. Figure 3 presents the logical equivalent of the example in Figure 2, in terms of the relational model, where each entity and relationship has been transformed into a “relation.” Each relation can be viewed as a table, where the rows represent occurrences ( or “tuples”) and the columns represent attributes. A relational database is basically a collection of such tables. These tables and tuples are then physically implemented as files and records through database management systems which are either end-user oriented and run on personal computers (e.g. DBASE III), or DP professional oriented and run on mini and mainframe computers (e.g. SQL/DS); in the latter case, data usage and volume constraints must be taken into account to optimize the system’s performance.
Figure 3. Example of a relational (logical) model
In addition to database creation and update capabilities (data definition language, data manipulation language, screen generator), these DBMSs also provide flexible interrogation and reporting facilities such as query languages and report generators which allow users to do ad hoc information searches and obtain custom-made reports. Finally, with a suitable interface to the database, information can be analyzed and presented graphically through the use of spreadsheet packages (e.g. LOTUS 1-2-3).
Data Modeling for Project Management: an Example
DMR Associates is one of Canada’s leading consulting firms, specializing in information systems development projects. To provide guidance to its project managers in their planning, organizing, control and leadership functions, DMR has developed a project management methodology using a life cycle approach based on the phases of information systems development (opportunity evaluation, preliminary analysis, system architecture, functional analysis and design, physical design, implementation). Starting from the principle that it is easier to manage something which is tangible, and that an activity is made tangible by the products it generates, this methodology is founded on a “deliverable” concept, which puts managerial emphasis on the actual products to be delivered throughout the project’s life cycle rather than on the activities to be accomplished in realizing these products. For example, if a programer’s objective is to code and debug three programs, the management of this programer’s work will be based on the three products he must deliver, i.e. the programs themselves, rather than on the required sequence of programing activities (obtaining program specifications, program coding, program compiling, etc.).
The data modeling approach was used to design the information system which supports this project management methodology. As defined by DMR, the system is based on a conceptual data model focusing on the various “documentation items” which constitute the products to be delivered at the various phases of a project. This model is presented in Figure 4. Note that these documentation items are considered simply to be tangible manifestations of the project management activities, and not the “deliverables” of these activities.
Returning to the preceding example, the programer has specific documentation items which he must produce for each program (program function, program coding structure, program data structure, program tests, etc.). The same principle applies for system-level documentation to be delivered by systems analysts and chief-programers at each development phase (phase reports, system charts, system specifications, etc.). Finally, DMR’s project management methodology specifies the project-level documentation items which the project leader and other team members must produce in accomplishing their planning, organizing, control and coordinating functions (project, group and individual plans, team structure, roles and responsibilities, important procedures, status review reports, etc.)
The information system to be developed in support of this methodology thus had four basic objectives:
1) Integrate project management information and rationalize its organization:
2) Store and update the status of each documentation item generated by the project management functions;
3) Facilitate the generation and upkeep of the documentation items, and make these available to all project team members, thus keeping them informed on all important aspects of the project’s planning, organization and evolution;
4) Provide tools and techniques to retrieve and analyze the information contained in the documentation items.
In accordance with the data modeling approach described in the present article, the first objective was attained by an analysis of the nature, content and interrelationships of the various documentation items specified by DMR’s project management methodology, resulting in the conceptual model presented in Figure 4. The next two objectives were achieved by using the conceptual data model to implement a physical database on a microcomputer, together with data capture and update procedures which can be used by all project team members. The last objective was accomplished by implementing an integrated software tool which, through access to the database, provides the following capabilities:
Note: The numbers in parentheses refer to the item’s description in the project documentation file.
Figure 4. Conceptual data model for project management at DMR (source: DMR. Information System Development Guide – Part 1: Managing the Project, 2nd edition. Montreal: DMR & Associates, 1986)
- management of work plans;
- management of cost, time and performance estimation criteria for progress status reports;
- graphical simulation tool for resource allocation, thus allowing managers to foresee potential problem areas;
- report generator for individual reporting needs.
DMR’s top-management claims that this approach has been very successful in projects of varying complexity and in varied organizational contexts .
It would seem that the data-based approach to information systems design is well suited to the project management context. Compared to the rigidities of output-based systems, either custom-made or packaged, this approach could insure greater flexibility and evolution capacity in satisfying information needs within an environment characterized by rapid changes and increasing complexity.
The data modeling approach could also reduce the need for the difficult process of exhaustively identifying and synthesizing project information outputs, resulting in information systems whose development and maintenance costs are lower. There should be greater manager comprehension and participation as it seems easier to describe the existing workings of the object system than it is to specify information outputs in advance. Additionally, information systems designed in this manner are generalized across certain classes of projects which exhibit similar life cycles, and thus can be represented by the same basic conceptual data model, with appropriate modifications for specific differences. The project database can also be linked to the overall organizational database to integrate the project information system within the strategic objectives of the organizational information system.
Finally, the availability of end-user DBMSs and the simplicity of the data modeling methodology allow the project manager to design and implement his own personal information system in a relatively quick and easy manner; this permits prototyping and shortens the development cycle (end-user computing as opposed to organizational computing). Data modeling thus becomes a viable alternative for the design of information systems which support project managers in their quest for more effective decision making through more relevant, timely, complete and accurate project information.
1. Ackoff, R. L. Management Misinformation Systems. Management Science, 1967, 14, 4, B. 147-B. 156.
2. Alloway, R. M. & Quillard, J. A. User Managers’ Systems Needs. MIS Quarterly, 1983, 7, 2, 27-41.
3. Chen, P. P. Entity-Relationship Approach to Systems Analysis and Design. Amsterdam: North-Holland Publishing, 1980.
4. Cleland, D. J. & King, W. R. Systems Analysis and Project Management. New-York: McGraw-Hill, 1983.
5. Davis, G. B. Strategies for Information Requirements’ Determination. IBM Systems Journal, 1982, 21, 1, 4-30.
6. Davis, E. W. & Martin, R. D. Project Management Software for the Personal Computer: An Evaluation. Project Management Journal, 1985, XVI, 5, 100-125.
7. DMR. Information System Development Guide — Part 1: Managing the Project 2nd edition. Montreal: DMR & Associates, 1986.
8. Fife, D. W., Hardgrave, W. L. & Dentsch, D. R. Database Concepts. Cincinnati: South-Western Publishing, 1986.
9. Landry, M. & Pascot, D. Conception de la base de donnees du systeme d’evaluation d’un programme social (Database Design for the Evaluation System of a Social Program). Research report, Faculty of administrative sciences, Lava University, Quebec, 1980.
10. Lemoigne, J. L. & Landry. M. Towards a Theory of Organizational Information Systems: A General System Perspective, in Information Processing IFIP 77, B. Gilchrist (ed.). Amsterdam: North-Holland Publishing, 1977.
11. Pascot, D., Mantha, R. & Blouin, C. La conception de bases de donnees: une alternative a la difficile synthese des besoins (Database Design: An Alternative to the Difficult Synthesis of Needs). Research report, Faculty of administrative sciences, Laval University, Quebec, 1980.
* * *
Louis Raymond is an Associate Professor of information systems in the Department of Administration and Economics, Universite du Quebec a Trois-Rivieres. He holds a Ph.D. in Administration (Information Systems) from the Ecole des Hautes Etudes Commerciales of Montreal, and an M.Sc. in Computer Science from the University of Montreal. His past experience includes three years as a systems analyst for Control Data Canada, and three years as an operations manager for a university computing center, during which he participated in large-scale computer projects. His articles have appeared in various publications such as the Journal of Systems Management, the American Journal of Small Business and the MIS Quarterly. His current research interests relate to the implementation of computer-based information systems in the specific contexts of small business and project management.