WBS and Mind Mapping - planning resources, time and costs

One challenge with WBS and Mind Mapping is that the project’s big idea can get lost in the details. If the project concept changes along the way, it can be difficult to see the impact of those changes. Agile methods like Scrum, Kanban, PERT, and CPM share this limitation, as they often focus on smaller parts of the project, which can make it harder to view the overall picture.

In many projects, changes happen along the way due to input from stakeholders. Some stakeholders think at a high-level, conceptual level, while others focus on details. The project manager needs to translate these changes from concept to detail and ensure the levels align. Here, it's important for the project manager to keep an overview of the project and understand how the concept breaks down into details.

WBS and Mind Mapping have limited flexibility and don’t clearly show the dependencies between tasks. This can make it time-consuming to update the project when changes occur, and there’s a risk of overlooking important details, leading to mistakes and extra time needed.

For example, imagine a project to build a car. A change in the car's appearance might seem small but could have big consequences for the car’s construction. If the project manager can show these consequences to the designer, the designer is more likely to adjust their changes, rather than if the project manager only mentions some general impacts.

Proglar Project Modeling - the easy way to planing

A method for creating a clearer view of a project’s concept, while also breaking it down into manageable parts, is to use Proglar Project Modeling. At the start, a project can be described as a model of the reality one aims to create. A model is a simplified representation of reality, used to understand, analyze, and predict aspects of a system or process. The main goal is to simplify the project's complex structure and dependencies, providing the project team with an understanding of how the project should be organized.

A project model can consist of several sub-models, each describing smaller parts of the project. Each model can be described based on three components:

• Attributes: For a physical object, this might include fixed values like height, width, weight, color, material, etc. For an IT system, it could be constants like text, numbers, etc.
• Actions: A description of the actions the model performs. For example, a robotic arm might need to move in three dimensions. In an IT system, the model might need to perform calculations or similar tasks.
• Dependencies: Other models that this model relies on to function.

An example of a model could be the engine part of a hybrid car.

Figure 3 shows an example of a Hybrid Electric Vehicle (HEV) motor model, where the combustion engine and electric motor are mechanically connected, with a generator placed between them. The model consists of several sub-models, such as the "Generator" or "Transmission." The advantage of this model is that it breaks down the project concept into manageable models. Each model can then be broken down further until tasks, time, and costs can be assessed.

For each sub-model, attributes, actions, and dependencies are described. This allows tasks for each model to be defined. For example, the "Power Converter" model has attributes like frequency, power, and input/output voltage. Its action is the conversion of electricity from DC to AC, with dependencies on models like "Battery."

The "Power Converter" can be further divided into smaller models, such as:

The advantage of Proglar Project Modeling is that it allows a project to be broken down into smaller parts throughout its lifecycle while preserving the overall concept. For instance, in the case of a “Power Converter,” the project may initially define it simply as “Power Converter.” When work on the task begins, it can be broken down further, as shown in the figure, with each part representing one or more subtasks.

A subtask might involve designing the model’s attributes or defining one or more actions for it. For each model, it becomes clear how it operates in relation to the entire project, as it shows dependencies on other models.

Changes to the project can be implemented more easily by continuously maintaining and refining the sub-models. For example, the consequences of changes in an engine part can be identified through Proglar Project Modeling, reducing both time and potential errors if changes are needed.

Proglar Project Modeling also helps assess the specific skills required for each task, making it easier to assign tasks to team members based on known competencies. When using Proglar, you also gain insight into your team’s skills. Each time a user is assigned a task, it is recorded in the system, creating a competency matrix that assists the project manager in task allocation, showing when the team has the right skills and when skill updates might be needed.

Proglar Project Modeling can also track who has influence on and interest in each sub-model. If changes are proposed that affect a specific sub-model, the project manager knows which stakeholders to involve. This ensures that changes align with relevant stakeholders and prevents those with less influence but high interest from steering the project in a direction that may not be beneficial.

Summary

There are numerous benefits to using Proglar Project Modeling. Our experience shows that it can save significant time and reduce errors by continuously updating the project model. This method provides transparency, making dependencies and each sub-model’s functionality clear.

Task assignment is simplified, as competencies are documented within the model. It also offers clarity about who has an interest in and influence over each subtask, enabling changes to be made with all relevant stakeholders involved, ensuring changes are implemented with consensus from the appropriate people.