Model Based Project Management
Managing many projects simultaneously is difficult. If a company has recurring product development processes in parallel, it can help to begin describing the processes formally as directed graphs. The nodes represent processes and various objects which processes can use, consume or produce.
Managing many projects simultaneously is difficult. If a company has recurring
product development processes in parallel, it can help to begin describing
the processes formally as directed graphs. The nodes represent processes and
various objects which processes can use, consume or produce.
When modeling each process its duration should be estimated. If the task is
too difficult the process should be broken down into smaller components. Its
representation in the directed graph can be hierarchical such that the user
never loses track of the bigger picture.
The designer should focus on requirements and deliveries of each process. This
way the flow of objects, such as materials, tools, personnel, and information, is
well documented. Each object should have a formal measurable specification such
that its meaning is clear for both the producing and the consuming processes.
In project management, a set of projects sharing common traits can be grouped in
programs. Likewise, a set of programs with similar properties can be grouped in
portfolios. Formally, there is no need to call these containers anything since
the depth of the hierarchy can be arbitrary. The interesting property of the
project hierarchy is that reusable objects can be found and resources can be
dynamically allocated globally over the whole organization when deviations
occur. If fundamental conditions of the projects change the organization can
adapt rapidly. There is a complete transparency on how corrective measures
affect other projects.
The project model can be used to predict future resource needs giving heads-up
on future investment needs. The management obtains information to act upon
whether to invest or change the scheduling of the projects to be able to execute
with the resources available.
When all participants report status and time spent on each process it is
straightforward to generate continuous status reports, and utilize previous
track records for each process in future scheduling.
The projects we are looking at are recurring. This means that they run over
and over again with changes in specifications.
In a broader context, several projects are running in parallel; some are more related to each other than others.
Programs contain several projects and are recurring in the same way as well.
Finally, the portfolio is cyclic as well, containing several programs and
As mentioned earlier we do not need to call each level of the tree anything. In theory,
the hierarchy could have infinite depth. Mitigation of
issues can be optimized over a given context. Choose if the correction should
be done within the given project, or at the program level, or maybe even at
the portfolio level. If a broader context is chosen for mitigations better solutions
could potentially be found concerning resource usage and scheduling.
Having all projects in a tree structure enables the possibility to build one
single graph representing the whole portfolio at once. Scheduling optimal
resource usage becomes easier since we have a full picture of all dependencies.
We might, however, violate the maximum available resources (black horizontal line).
The management could decide to either increase the available future resources or reschedule the project such that the limit is not violated.
Model-based project management gives the project management access to new
quantitative measurements which can be used to control the projects better.
The model is a state representation of the projects. The project management
can use business intelligence and data science to generate insights, dashboards,
and assist project managers when making objective decisions.
The maturity of the suggestions increases in six levels:
- How many, how often, and where?
Traditional reports with aggregated raw data.
- How did we do?
Reports showing historical data.
- Why did it happen?
Track audit trails to understand why a problem happened.
Quantify cause and effect.
- What happens if we continue like this?
Predict the schedule of the project if nothing is done.
- What results can I expect?
Given the current plan, what will the outcome be?
- What should I do next?
Obtain suggestions of actions and show a quantified analysis of the effect
of each suggestion. The user must accept not always to understand why the
effect is what it is. Combine insights with recommendations and the expected
All in all, this is an incredibly powerful way to work with projects. It removes ad-hoc mentality and adds well-founded decisions while equalizing the power among managers and project managers.