Project Management Modeling Language -PROMOL

We have developed a project management modeling language (PROMOL) that helps us to plan, understand, analyze and document management of software projects. PROMOL is a formal and visual modeling language. Here, an overview of PROMOL is presented.

In the core of PROMOL, there are two concepts: Activities and Entities.


An activity is a named process, function or task that occurs over a limited time.


An entity is something that has a distinct, separate existence, though it does not need to be a material existence.


Notice that these are commonly used terms defined in the broadest sense. Examples of activities include requirements analysis, hiring and staffing, meetings, code reviews, testing etc. Even social events like parties may be considered as activities if they are believed to have a positive effect on the project development. Examples of entities include problem statement, project plan document, stakeholders, design, code, prototype, test criteria etc. Even abstract concepts such as teamwork, leadership, communication etc. may be considered as entities. Management of projects is complex in nature. It has many aspects. Not including mechanisms to represent such influential aspects of managing projects limits our ability in understanding and analyzing project dynamics. Therefore, we believe such broad use of these terms increases the representation capability of the modeling language.


PROMOL consists of relations defined on activities and entities. a() represents an activity while e represents an entity. Activity and entity names can also be used such as testing(), prototype. Activities are followed by parenthesis distinguishing them from entities.


Create: When an entity is created as the result of an activity “create” relation is used. For example, project staff may be created as the result of a hiring activity. The mathematical representation of this relation is:


Transform: Most activities in project management take entities and transform them into other entities. This relation is represented with a “transform” relation. For example, a testing activity takes the code and test oracle and transforms them into test results.


Divide: An activity or an entity may be divided into its smaller parts. Such relation is represented with the “divide” relation. For example, a design activity may be divided into high-level and low-level design.


Aggregate: Activities or entities may be aggregated to represent a certain activity or an entity.


Next: Arrangement of various activities and entities in a time or logical sequence is of particular interest to project managers. In order to represent ordering relation between activities and entities, the “next” relation is used and depicted with a right arrow.



Previous: When an activity or an entity has to precede another entity or activity, relation “previous” is used. It is represented with a left arrow.


Require: The relation “require” is used when an activity or an entity requires other activities or entities to happen or exist. This relation helps us to model various dependencies among different aspects of project management. Such one important aspect is the relation of different stakeholders to different activities. For example, a project sponsor may be interested in the planning phase of a project while the end user is interested in participating in the requirements or testing phase of a project.


Decision: Decision-making is another important aspect of project management. Documenting the rationale and activities following the decision is essential. To capture such issues, the relation “decision” is used. The decision takes various entities (one of them is the decision criteria) as inputs and it provides the next activity to go based on a particular decision (which is another entity

Exist: The relation “exist” provides us a mechanism to conduct formal analyses. In order to question a model for a certain practice, structure or even the existence of an activity or an entity, we use “exist”.

The relation takes an input and check the model for that input. If there is such an instance, it outputs true otherwise false.


There are also some reserved constructs. START and END denote the beginning or an end of a model. When they appear in small letters, they illustrate the start or an end of a specific activity under a hierarchy, which is detailed with the “divide” relation.


We put special effort and emphasis to limit the number of relations introduced. According to Miller’s law, short-term memory is limited to 7±2 chunks of information. Even though, it is possible to introduce many different concepts and specialized relations for specific purposes, the ideal is to make it simple, usable, and as optimal as possible while maintaining the capability to be applicable and scalable. Therefore, the modeling language has a limited number of relations.

Graphical Notation:

The figure below presents the graphical notation in PROMOL (Figure 1).

Figure 1. Graphical Notation in PROMOL

To illustrate the concepts, a very simple example is provided. We only show the scope definition of the project, developed with a waterfall life cycle approach. Scope definition (a2( )) is an activity at a higher-level model in the hierarchy. The activity (a2( )) is detailed using the “DIVIDE” relation. The visual model is shown in Figure 2. The model of the scope definition in this project is as follows:



a9( ):  Identify Problems and Opportunities

a10( ):  Negotiate Scope

a11( ): Develop Schedule and Budget

a12( ): Present Project Plan



e3 : Project Team

e4 : System Owners

e8 : Project Request

e9 : Problem Statement

e10 : Project Vision

e11 : Project Budget and Schedule

e12 : Department Managers

Figure 2. The visual model of Scope Definition activity in PROMOL

Analyzing Practices with PROMOL

Visual aspect of the modeling language is for the use of practitioners, while mathematical aspect of it is for the development of automated tools and conducting formal analyses on project managements. For example, the relation “exist” does not have a visual counterpart. Since it is only needed for conducting analysis. Analysis of certain best practices in projects particularly interests researchers. It is possible to formally describe some of the best practices with PROMOL and investigate them in the models. Assuming that, there is a model developed by the project manager during project development, it is possible to verify the mathematical model for the existence of certain practices. For example:

“Are requirements development conducted before design?”

“Is there a prototype before low-level design?”

“Are code reviews conducted after module coding activities?”



Strengths of PROMOL

 Project management is complex in nature and building models helps us to simplify the complexities.

 ·         The tool helps with the project planning activities. Project planning is one of the major responsibilities of the project manager. Using the models, a project manager is able to plan the activities in the project and to investigate alternative solutions under different resource constraints during project planning phase.

·         It is possible to track the inputs and outputs of activities. Thus, it helps with managing the project artifacts and deliverables.

·         The tool helps with stakeholder management. Stakeholder management is a key issue in project management. The modeling tool allows us to relate various stakeholders with activities.

·         The models developed with the tool easily adapts to changes. The project plans change during execution. Therefore, it is important that a project management tool reflect this inherent aspect of projects. Using the modeling tool, it is possible to build high-level models at the beginning of the project and later add detail to the model using the “divide” relation. The tool allows hierarchy and dynamism in planning. Change in some part of the model does not necessitate change in other parts.

·         It is formal. Communicating the project plan is important. The modeling tool eliminates the ambiguity in communicating the project plan to different stakeholders. Everybody understands the same thing. It allows for development of automated tools and formal analysis of management of projects. We can investigate whether certain best practices are being followed. It is also possible to develop project management metrics.

·         It is visual. Diagrams are easy to understand. Lots of information can be presented with just one diagram. It also helps with documenting and communicating project plans.

·         The tool allows visualizing various aspects of project management at once. The models include activities, developers, inputs, outputs, stakeholders, and the relations among them.

·         It is possible to create templates. Process standardization is an issue in big organizations.  Achieving a certain level of quality in different projects is important in these organizations. It is possible to create model templates to ensure that certain practices are followed.

·         The modeling tool allows for extensions. As long as it does not conflict with the preexisting relation definitions, it is possible to extend the tool. However, there is a trade-off. Over-specification may defeat the purpose of keeping it simple.

Back to Projects Page

Last updated: 07/15/2008 13:07:28