Introduction
Although project management includes many mathematical concepts, theories, and formulas, no endeavor has hitherto been made to employ symbols in order to integrate the basic concepts of this complex subject. In this paper, the author has attempted to accomplish this difficult goal: He has, at times, chosen intuition over rigor in venturing in, as far as he understands, the first attempt of this kind, .Instead of trying to embrace everything in the first attempt, the author has focused on prototyping a definition of project management based on a smaller subset of basic concepts.
Basic Concepts
The Process
Official definition of the process describes it as a series of actions bringing about a result (Project Management Institute, 2000, p. 29), from which the following may be inferred.
- A process has an input and an output.
- Actions are performed on input resulting in output.
The two may be taken to mean that a process is a function mapping input to output.
Definition 1
process:Input → Output
Input/Output
The input and the output have been defined as “documents and documentable items” (Project Management Institute, 2000, p. 32). One may experimentally interpret this by defining everything that goes into—or comes out of—a process by input and output, respectively, and represent them as sets. It is conceivable that output from one process acts as input to some other process, which has been called linking (Project Management Institute, 2000, p. 32). Hence, it becomes important to have a common nomenclature for input and output, keeping in view that these are sets.
Team
A team can be either input or output but not both, vide Definition 2. However, such exclusivity is subject to entropy, vide infra.
Definition 2
Team = Input ∨ Team = Output
Team = Input ⇒ ¬Team = Output
Resource
A resource is a member of a team, vide Definition 3. From Definition 2 and Definition 3, it follows that a resource is an exclusive member of input or output, vide Theorem 1, one that includes people, equipment, and material (Project Management Institute, 2000, p. 34).
Definition 3
resource ∈ Team
Theorem 1
Project and process
The project comprises a composition of processes that can be categorized into project management or product-oriented processes (Project Management Institute, 2000, pp. 29 – 30), from which it appears that a project is a set of interrelated processes. Therefore, one can view a process as an ordering relation between two teams that act as input and output to it. In other words, if a team is the input and b team is the output to a process (designated by the symbol ‘≥’, which connects input on the left to output on the right) then Definition 4 would hold.
Definition 4
aTeam ≥ bTeam
Entropy
One may have various questions about teams before proceeding further: Can a resource belong to two different teams simultaneously? Can a resource be consumed even when it is not part of any team? If I assume that time is the default process that acts on all resources, even if these are not attached to a process, and that processes span over an interval of time greater than zero, then it would provide answer to such questions. . This would mean that even if the same resource appears in input and output, the occurrences are always ordered by time being the default process and as such different. This also signifies that a resource is always utilized by one and only one process, which could be easier to conceive if I assume that a resource has a predicate, entropy E, which monotonically increases such that entropy of a resource as input rInput is always less than entropy of the same resource as output rOutput. The next step would involve defining a resource ordered by its entropy: For example, it would be different if its entropy changes. To avoid confusion, it is better to reiterate that in Definition 5, I used the symbol ≥ to indicate a process and > to indicate greater than. When the input and output look different (e.g., a programmer and a computer being input, resulting software being output in a coding process), the software represents the entropy gain of the two other resources in course of the process. Similarly an unattached resource would still cause opportunity cost over time that justifies increase in its entropy.
Definition 5
Organization
It is inconceivable that Definition 4 could be reversed, that the input and the output can be switched under the same or any other process. Thus a programmer and a computer may produce software under the coding process but the software cannot produce programmer and computer under any process. At the same time, it is also necessary that input to a process is the output of some other process or the input to the project itself. Similarly, output from a process is input to another process or the output of the project. Since a team is not necessarily atomic (i.e., comprising of a single resource), it is conceivable that one part of a team behaves in one way while the other behaves in the other, such as that some resources of a team are input or output of the project while some others are not. On the other hand, a resource is assumed to be atomic (i.e., capable of being included to one and only one team), since it can be utilized by one and only one process, as mentioned earlier. (This is why entropy was introduced to refine the definition of resources.) If the same resource belongs to more than one team, then its entropies will differ. Sometimes it will seem that a resource seems is capable of being simultaneously used by different teams (e.g., the development team may use a design document to develop software and the test team may use it in creating test cases). The easiest way to address this apparent contradiction is by considering the two copies of the design document as different—as separate—resources. An argument in favor of this is that the two teams might want to draw inferences from—or make alterations to—the design document according to their own needs; thus, the same design document will have two different versions. This means that project managers must reconcile the two versions by taking into account the independent interpretations—or changes—that each team made while using it. They must reconstitute the document into a form that is acceptable by all.
Like chemical definition of the molecule, a team is different when broken down or reconstituted. Thus, a project gives rise to an order relationship, where all teams are interrelated by input or output to some process. Such order relationship takes the form of a lattice, with one initial and one final team representing the project input or output, as represented by the two extremities of such lattice. I would designate such lattice by project organization because this organization provides the project's underlying framework. The framework describes a static project or project comprised of project planning teams. The organization has defined roles, responsibilities and reporting relationships (Project Management Institute, 2000, p. 34), which essentially boils down to some member of input or output. For example, the role of programmer may comprise a member of the software development team, which inputs the process for development of software X. A role is an abstraction of some resource or sub-team. Thus an individual or a sub-team of individuals A—or a software program B that automatically generates codes—can realize the role of the programmer. Responsibility R is a predicate of an input-resource (e.g., programmer p) that is associated with an output-resource (e.g., defects d), which is represented by Definition 6.
Definition 6
Rp = d
Thus, responsibility is an input-resource. In the same way, a report is an output-resource with respect to the communications process, to the producer or sender of an input-resource and the consumer or receiver as another output-resource to it. A typical project organization may look like Figure 1, where the octagons represent teams and the directed arrows connecting these processes—head of the arrows pointing to the outputs and tails pointing to the inputs. The leftmost octagon represents the project-input and the other extreme the project-output. The following assumptions would help explain the concept of a project comprising a lattice of teams.
- Resources are subscribed with their entropy represented by whole numbers, starting with 0 when input to the project, and increasing by 1, with every process a resource participates in.
- A team of output or input may be partitioned, in order to obtain a team with finer grain. For example, a team being a set of resources can have mutually exclusive sub-teams that gives rise to the concept of granularity of teams—the atomic grain, of course, being the resources. Sometimes, it might be useful to have a team of finer grain as part of more than one process.), while applying to more than one process. It is necessary to have different teams as inputs and outputs to different processes.
- Since all the resources are released after a project, I presume that the lowest or rightmost level, which also represents the project output, is the null set ∅; however, for the purpose of computing the resource consumption, which depends on the nature of resource and entropy-gain, I suggest constructing the project-output like other teams.
a. Designating the lowest level with the null set will solve the problem of having an l.u.b. between any two resources, which is one of the preconditions of a lattice. The other condition of having g.l.b. is satisfied by having a project input. The hierarchy {a3, b3} > {a4} in relation to Figure 1, holds since the input can be partitioned into {a3| b3}, while each partition would act as a team. Since b3>b4, I would say that the relation holds. Similarly {a3, b3} > {b4, c4} is another relation in the same figure. The entropies, denoted by suffix, were considered while determining hierarchy (see Definition 5).
b. Example: In Figure 1, let a0 be a programmer, b0 computing resources, and c0 a design that produces a prototype of a software {a1, b1, c1} under preliminary coding process as well as a unit test release of the same software {a2, b2} under intermediary coding process and regression test release {a3, b3} under semi-final coding process. The regression test release becomes input to the final coding process that results in production software {a4} and, with input from another process, the user manual {b4, c4} was developed. The set {a4, b4, c4} forms part of the project-output followed by release of resources.
- While the scheme described here measures resources by their nature, e.g. a, b,…, and entropy differential, the stage of completion or componentization (e.g., prototype, unit test release, etc.) is not apparent. Thus the total resources utilized in the project can be given by aggregation of some function f of the set of planar tuples of resource and entropy differential ΔEntropy (see Definition 7). To include componentization, suitable input granularity of teams should be used. For example, a programmer with 6 years experience in Struts technology, as resource, and for 600 hours, as entropy, can be taken as the input to prototype. Here, the function would multiply the rate of the resource in $/hour with entropy, which essentially converts all resources with money as the common denominator and number of hours representing entropy-differential to find resource-utilization.
Definition 7
Figure 1. Project organization
Project and project management
The project has previously been described, albeit in the planning stage, as the overall process that realizes its goals, which also maps the project-input Inputproject to project-output Outputproject. The above definition of the project will essentially devolve into the following. Assuming a project would always comprise of a finite number n of teams, let us take all the teams Ti in a project and multiply them. Then we will get n-tuple product-sets like , where r's denote the resources—the first subscript denotes their team-affiliation and the second one their identity within their respective teams. If we take all possible subsets of the products like the one above, we will have the power set of such products. This would involve all possible permutations of the team-resources. One of these products will represent the project. Hence the project would be a subset of such Cartesian product. I didn't mention omission of the null set ∅ that can be regarded as the null project that does no conversion. Strictly speaking, the second one does not talk about organizing the processes and thus describes the project-set or the set of teams in a project rather than a project. These two definitions of project are shown in Definition 8. However, this would define a project with the plan teams. At execution time, a project will deal with risks, such as infra, when the project will resemble a random processi.
Definition 8
The official definition of project management says it is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements; that it is accomplished through the use of processes such as initiating, planning, executing, controlling, and closing; that managing projects typically involves competing demands for scope, time, cost, risk, and quality; that it involves stakeholders with differing needs and expectations and requirements (Project Management Institute, 2000, p. 6). Thus project management is—particularly in regards to planning—the inverse mapping of the project (see Definition 9). This covers such aspects as meeting project requirements that essentially requires the application of knowledge, skills, tools and techniques by mapping of project-output to project-input.
Definition 9
Risk
There are two types of teams: The plan teams that are conceptualized when a project is planned and the execution teams that are formed when a project is implemented. The execution teams, which will be called risks, carry certain levels of uncertainty. The official definition says a risk is an uncertain event that, if it occurs, has a positive or negative impact on the project objectives (Project Management Institute, 2000, p. 127). Execution processes are random variables in natureii. Since execution teams are the only eventsiii in the present scheme, as since these are also uncertain, these fit the official definition. However, I would like to further interpret the official definition by saying that each risk ρ is associated with a probability P and that there are, at most, a countable set of risks associated with a process. I also presume that risks are practically divided into a minimum of two (i.e., acceptable or non-acceptable) and a maximum of a finite number of quality-levels. Thus a risk will be defined as an execution team that is comprised of finite variations, in which a probability associated with the aggregate of the probabilities of all risks becomes a certainty (see Definition 10). While input and output both could be risky, risk is more commonly associated with output because input must already have happened, because past events have preceded processesiv while output hasn't. Again, eventually all inputs are output of some process except the project-input, which is the basic premise on which the project stands. If a process iterates, since many of them are of iterative nature (Project Management Institute, 2000, p. 6), one can determine the stochastic probability. In other cases one has to depend on history or estimates that gives a priori definition of probability of risks.
Definition 10
Metric
The Project Management Institute (PMI), in its PMBOK® Guide, does not define metric (Project Management Institute, 2000). However, it is possible to define a measurable attribute of a team a metric, since metrics are planned. Metrics, however, are applied on risks. Hence a metric M is a predicate of risk ρ (see Definition 11). The process or function that finds a metric is called measurement m. For example, a metric could be number of defects passed on to the customer per mille that can be measured by the cumulative number of defects reported by the customer multiplied by thousand and divided by the total number of items. Hence, there are two aspects of a metric, one being definition and the other measurement.
Definition 11
From the above it may be inferred that a metric defines a set Q of quality-levels, designated by variable subscript i, and measurements actually measures a risk to determine its quality level with subscript k. In our previous example, the quality levels could be less than 10, between 10 and 100, and more than 100. The quality-levels should cover all possibilities. Thus the quality levels redefines events and sample spaces (see ii and iii above).
Definition 12
Project management
At this stage, it may appear that while project management maps project-output to project-input, it involves planning the teams and the organization. It also appears that project management should also plan a finite number of quality-levels and associate a priori or stochastic probabilities of risks falling in one or the other of them. What is not apparent is that as the processes are progressively executed according to hierarchy, the output becomes more and more riskyv. This is because the project-input is assumed deterministic while the outputs from the initial processes are probabilistic, and such probabilities are multiplied and become progressively smaller when input probabilities are considered.
By more risky, I mean less probable. In order to control the project-output at the macro-level, one should control various process-outputs at the micro-level. Thus, the output from a process is measured to find its quality level, which could warrant the application of corrective processes to make such risk fit for input to the subsequent processes involving the project execution and control stage. The control mentioned here is essentially feed-forward (or proactive) and not feedback (or reactive) in nature: The project is not repeatable, thereby precluding any scope for reaction, as depicted in Figure 2, where the input risk ρ1 = t1 is assumed the same as plan team. But the output risk ρ2’ is different from plan team t2 of the process p2, whence instead of applying the output of p1 directly as input to subsequent process p2, as originally planned. A workaround process p’ is applied first to obtain risk ρ2 = t2.
Although workaround has been described as unplanned responses (Project Management Institute, 2000, p. 146), I would use the term to mean planned or unplanned responses. Sometimes these workarounds are previously planned, (e.g., invoking a contract to transfer the risk), such that the final output of profit of $x would become more probable: In other words, the expected net profit—the aggregate of the products of various planned profits and respective probabilitiesvi—increases. Since processes in a project are not completely predictable, avoidance of risk by replacing a probabilistic process by a deterministic process is not always possible. This is because a precondition of a project is to be risky in the sense of being probabilistic, which is corroborated by the official definition of project as “planned, executed and controlled’, of ‘temporary’ nature, and ‘unique product, service or result” (Project Management Institute, 2000, pp. 4 – 5). Mitigation is a pre-planned workaround; unqualified workaround is instantaneous engineering of corrective process; and accepting the risk is taking a chance.
Figure 2. Project execution and feed-forward control
Number 13 encapsulates the foregoing discussion of a project symbolically, as it relates to execution teams or risks rather than plan teams, where a project is conceived of as a dynamic lattice or organization of all risks, where the order relation is defined by the actual process—a composition of plan process giving risks from plan input, measure giving quality-levels from risks, and workaround giving plan output from risks. Each risk ρ can be measured, measure m representing a function that actually maps a risk to a member of the set of quality levels Q, which, in turn, may require some workaround, which is of the nature of a process or function and which maps the measurement of a risk to the corresponding (plan) output. Members of the set Q are qi's, where the cardinality of the set Q is finite. Each risk has an associated probability that is a member of the closed interval [0, 1]. Finally, the probability of the measure of a risk belonging to some of the quality-levels is certain. I might also note that the definition of project management remains the same as Definition 9 in relation to the revised definition of the project.
Definition 13
actual process = workaround o measure o plan process
where
Conclusion
The symbolic modeling of project management presented here is rather indicative. In the course of defining project management, I identified two types of project models: one for planning, one for execution and control. I believe that it is possible to create more inclusive and complex models of project management using this symbolic approach.
Epilogue
The insight provided by the theory can be useful in better understanding the nature of project management. This pure pursuit of wisdom is necessary before any application of such understanding can evolve. Drawing parallel from the sciences, one may find there are pure and applied branches of mathematics, physics, etc. Although it may be premature to applied aspect of the theory presented here, there could be criticism from certain quarters, which tends to lay stress on the practical aspect rather than theory. To satisfy their needs, the author has provided two broad categories of problems that apparently are direct consequences of the theory.
The theory points to the broader context of the project within which processes must be accommodated and not the other way round. Often businesses tend to focus on processes that have the effect of creating a straightjacket around the project. For example, even world leaders in software services broadly organize their processes around two major kinds of project, development of software and maintenance of software. While the processes relating to the former are designed more meticulously, with checks at every step, those in the later lack in similar controls in the hands of the vendor, which is not unjustified considering the much shorter turnaround time of maintenance projects. However, it is not uncommon to find a maintenance contract taking the place of a software department that had originally been created in order to continuously evolve one or more enterprise applications with ever-changing requirements. Clearly, such contract does not only undertake fixing problems but also adding new functionality, addressing issues relating to software performance against more demanding environment, etc. Evidently, the focus ought to be on development, too, as well as a completely new set of risks arising out of a group of experienced employees being replaced by relatively inexperienced staff of the vendor organization. In order to accommodate such risks, a new project model need be crafted, instead of invoking the maintenance mode by default. Thus, project modeling or engineeringvii gains importance over process engineering in such case. Another striking example of the concept would be brand transmutationviii, where the core expertise that differentiates a business needs to be strengthened by sacrificing some of the peripheral expertise. For example, a customer from India wants to purchase a Porsche car. Normally, such need cannot be fulfilled since the normal business model necessitates Porsche to deliver the car, which is uneconomic until the demand reaches a threshold. However, a new business model can be crafted where Porsche need to deal only with its differentiating strengths in design and innovation. The customer pays Porsche via Web portal and downloads specifications. Next, the customer approaches a local engineering workshop, reputed for its construction, and gets the specs converted into reality. Thus, the original Porsche that covers design and construction is retained in design but relinquished for construction to another brand.
Figure 3. Example of project engineering: brand transmutation
Another application of the theory could be a search to find the basic building blocks of all projects, i.e. elementary processes. Following the arguments presented in the discussion, if we assume that all complex processes and projects devolve into simple processes that can be part of many such aggregations, then it would make sense to create a cache of optimized and independent, elementary processes rather than such complex ones as development of software. Like distinct shapes made from the same set of building blocks, the same elementary processes can make distinct projects. Thus conceived, processes tend to become inherently generic and adaptive. For example, as part of a project, a process may consider ‘movement of goods from the first floor of north wing to thirteenth floor of east wing’. However, an elementary process may be thought of ‘movement involving both lateral and vertical components, over ramps, stairs and lifts, of goods that may be heavy, fragile or a combination of both, including their opposites’.
SYMBOLS
| Symbol | Meaning |
| = | Equals |
| > | Greater than |
| ≤ | Less than or equal to |
| ≥ | Process (as a relation) or ‘greater than or equal to’; the context determines the interpretation |
| → | Maps to (with respect to functions) |
| (..) | Grouping, with elements inscribed, delimited by comma |
| {..} | Set, with elements inscribed, delimited by comma |
| | | Such that |
| ¬ | Logical ‘not’ |
| ∧ | Logical ‘and’ |
| ∨ | Logical ‘or’, normally in the ‘inclusive’ sense, i.e. ‘and/or’ |
| ⇒ | Implies: the preceding statement implies the succeeding one |
| << ∞ | Finite whole number, i.e. the preceding quantity is |
| ∅ | Null set or a set having no member |
| ∩ | Set intersection or the common members of multiple sets separated by the symbol |
| ∪ | Set union or all members of multiple set as a single set without repeating repeated members |
| ⊂ | Set inclusion; the preceding set is a subset of the succeeding set |
| Σ | Aggregate or sum of succeeding (parenthesized) term(s) |
| | | | Cardinality or the number of members of the inscribed set |
| l.u.b. | Least upper bound |
| g.l.b. | Greatest lower bound |
| Function b maps set A to set B |