Project Management in maestro*

Most Enterprise Resource Planning (ERP) systems are designed primarily around the concept of managing accounting transactions in the General Ledger (GL). The common approach to project management within many of these systems is by means of GL account segmentation, by project. This approach, although easy to understand for those who have an accounting background, goes against generally accepted approaches in project management. From its beginnings, Maestro Technologies Inc., decided from the outset to develop an ERP system that was designed to be project oriented, in which project transactions would be recorded and then transferred into a recognized accounting/financial management structure. Over the years, our approach has evolved to allow comprehensive financial management within the project management system. The latter is based on the Work Breakdown Structure (WBS)1.

The use of an enterprise resource planning program such as maestro* offers many advantages. Other than information being available in real-time, participants of an organization need only work with one software, no matter their position in the company. All information is grouped and available, when needed.

 

What is an enterprise resource plan?

When we say enterprise resource plan, we mean a program which allows to manage and follow, on a daily basis, the financial AND operational data of a company. This type of program reduces the quantity of entries to be made as well as the risk of errors; users do not need to transfer information from one system to another.

Thus, maestro* is composed of modules dedicated to the management of financial data, others devoted to the management of operational data and, finally, so-called intermediate modules, dedicated to bridge the gap between financial and operational data. The sharing of data, for example, will be done systematically between material requisitions (maestro* operational component), inventory management (maestro* intermediate component), and the inventory financial management (maestro* financial component). We call transferring the action of pushing information from an option or module to another, through a transaction.

summary

 

a project approach

In maestro*, any entity for which we wish to establish a budget and/or monitor income and costs is considered a project. The transactions created and generated in the software therefore always relates to a project. They can be of any kind: construction, activity, layout, etc. The administration, which has associated maintenance costs for a building or head office, for example, is also a project.

We must, therefore, see a maestro* "project" as a revenue and cost centre, a concept much more general than a concept limited to construction projects.

 

Since maestro* uses projects for entering all financial transactions, it will, therefore, be necessary to create at least one project that will represent all of the balance sheet accounts.

Thus, in addition to projects specific to the activities and assets of a company, all companies must, as a basic matter, have a "balance sheet" project, an "income and loss" project, and an "administration" project.

 

N ature of Projects in maestro*

As mentioned earlier, the concept of projects in maestro* is very broad. We can find in maestro* associated projects with the following entities:

  • Event, business unit, or project requiring close monitoring of income and expenses (construction and others).
  • Administrative costs (management costs, building maintenance, equipment maintenance, asset maintenance, etc.).
  • Internal profit centre or department (management of internal tools and rentals, departmental management, engineering department, etc.).
  • Balance sheet (i.e. all accounts not related to income and expenses).
  • Income Statement (i.e. all accounts related to income and expenses).

 

PAG Structure (project - activity - group)

The project structure in maestro* provides almost unlimited flexibility related to the monitoring of revenues and expenses. As we separate the project structure from the financial constraints, it is then possible to tailor the project tracking structure to align to the individual project requirements.

To the concept of a project is added the activities and groups concepts, which allow the breakdown of project revenues and costs. Indeed, in maestro*, users do not make accounting entries by entering the general ledger account numbers. When entering a transaction, they identify and select the project, activity, and group. Maestro* is responsible for carrying out the accounting entries corresponding to the user's selections. In addition, the use of this nomenclature/structure decreases the number of general ledger accounts to be created, since it is possible to view income and expenses from all levels of detail.

 

The more varied the projects, the more complex it can be to manage transaction entries. It is therefore important, at the outset, to define the desired level of detail in the structure of the projects, keeping in mind the real needs in terms of cost monitoring. In addition, very detailed project data can be obtained without having to create multiple general ledger accounts.

Implementation specialists support all new customers in the development a project structure corresponding to their business needs and realities.

 

Activities

Each project can have an unlimited number of activities, that details said project.

For a construction site project, for example, the following activities could be created:

  • Foundations
  • Slabs on grade
  • Basement excavation
  • Basement walls
  • Floors
  • Roofs
  • Exterior walls
  • Exterior windows
  • Exterior doors
  • Roof coverings
  • Roof openings
  • Etc.

For an equipment project (such as a company car), for example, the following activities could be created:

  • Fuel
  • Maintenance and repairs
  • Insurance
  • License
  • Amortization
  • Rental (which could constitute rental fees or rental income)
  • Etc.

Finally, for the administration project, we could find the following activities:

  • Office equipment
  • Office supplies
  • Representation expenses
  • Telephone
  • Internet
  • Heating
  • Electricity
  • Administration salaries
  • Administration social advantages
  • Etc.

Since activities, in maestro*, are displayed and/or ordered alphanumerically, it is important to code activities with care. The 3.05 version of maestro* allows codes having up to 20 characters.

 

Groups

In addition to the activities, groups make it possible to compile the financial values according to their natures. Each of these groups is associated with a standard type of expense or income.

If the activities can differ according to the projects, the groups remain the same from one project to another.

 

Upon installation, maestro* includes by default a group for each type of expenditure, managed by the software package as well as for revenues. The six groups (expenses or incomes), for which groups with corresponding names are instantly created, are the following:

  • Material
  • Subcontractors
  • Miscellaneous
  • Labour
  • Equipment
  • Revenue

However, it is possible to define your own groups or additional groups. These additional groups must evidently be linked to a group type that will determine their nature (income or expense, material, subcontractor, miscellaneous, salary, or equipment). Some example of alternative groups consists of:

  • Salary groups for the administration and work sites.
  • Groups for internal equipment vs rented equipment.
  • Material specific groups. For example, a bricklayer could want to follow the costs of bricks and other materials more closely.

Do not hesitate to discuss this with your implantation specialist!

Know that it is also possible to restrict the access to certain groups, in project, in order to control the financial and data transaction entries. For example, two different approaches could be considered in the case of an installation containing two different commercial activities, and for which the costs management would be very different. The first approach could consist of defining particular activities for each project. The second could be to have target groups and to limite the use of these groups in accordance to each project.

Anyhow, and for the sake of simplicity, Maestro recommends, most of the time, to standardize project activity structures.

 

Example - Civil engineering

In the case of a civil engineering company, for example, the construction of route x could constitute a project. This project will consist of different activities such as clearing, excavation, asphalting, etc. Then, for each activity, we will find the following six groups: wages, materials, equipment, subcontractors, miscellaneous and income.

Example - General contractor

In the case of a general contractor, the construction of a building could represent one of his projects. This building project may be composed of several activities, such as excavation, foundations, framing, electricity, finishing, etc. Then, for each of the activities, we could also find the following six groups: wages, materials, equipment, subcontractors, miscellaneous and income.

 

PAG Example in maestro*

Here is what a construction project structure could look like2:

Phase and Activities

Activity Code

Material

Subcontractors

Miscellaneous

Labour

Equipment

Revenue

PHASE A -Substructure

 

 

 

 

 

 

 

Standard Foundations

A1010

5001

5002

5003

5004

5005

4001

Slabs on Grade

A1030

5001

5002

5003

5004

5005

4001

Basement Excavation

A2010

5001

5002

5003

5004

5005

4001

Basement Walls

A2020

5001

5002

5003

5004

5005

4001

PHASE B - Shell

 

 

 

 

 

 

 

Floor Construction

B1010

5001

5002

5003

5004

5005

4001

Roof Construction

B1020

5001

5002

5003

5004

5005

4001

Exterior Walls

B2010

5001

5002

5003

5004

5005

4001

Exterior Windows

B2020

5001

5002

5003

5004

5005

4001

Exterior Doors

B2030

5001

5002

5003

5004

5005

4001

Roof Coverings

B3010

5001

5002

5003

5004

5005

4001

Roof Openings

B3020

5001

5002

5003

5004

5005

4001

PHASE C - Interiors

 

 

 

 

 

 

 

Interior Partitions

C1010

5001

5002

5003

5004

5005

4001

Etc.

C...

5001

5002

5003

5004

5005

4001

 

Phase, Division, and Section Notions

Companies who wish to obtain even more detailed data than those available with the use of a PAG structure can divide their activities in additional hierarchical levels. Thereby, it is possible to regroup a project's activities in a phase (for example, project development, conception, layout, procurement, construction, and delivery). Other sections can also be added to, for example, dissociate work done on historical buildings from regular construction work, or to divide in parts a road in construction. Finally, the division notion can be added, as well, to further compartmentalize the activities of a same project.

In short, the phases, sections, and divisions notions can be added to the already established structure of activity creation and can be used in the following increasing order: activity, phase, section, and division. They will allow customers to have access to three additional levels to manage a projects expenses, for which the structure is very complex.

We can also say that phases, sections, and divisions allow the sectionning of a project and the compartmentalization of its activities.

 

Project Type, Category, and Department Notions

Type, category, and department notions will allow the grouping of projects at the discretion of customers and for different purposes. This could be done to:

  • Apply a security management to make sure that access to certain project types, or categories, be limited to specific user groups.
  • Have reports by project type or category, according to a company's needs.
  • Apply a default projection calculation method to project types.
  • Regroup projects in departments for the production of financial statements.

Furthermore, regrouping projects by type, category, or department can make it possible to:

  • Indicate, by project type, the advancement entry percentage precision level by default.
  • Create, or not, a dispatch project for particular project types.
  • Associate a project type to a PAG, to which discounts will be deduced during revenue transfers.
  • Establish a history to link the different department expenses.

In short, it is important to define types, categories, and departments with care and think about the security to apply to each project, as well as how we wish to select them.

 

In maestro*, the three options in which these groups can be created are the following:

  • Define Project Types
  • Define Project Categories
  • Define Project Departments

 

Master Projects and Sub-Projects

When creating a project in maestro*, it is possible to associate the project with a so-called "master" project which oversees the newly created project. A master project is, therefore, a project in itself, to which other projects are attached which then become sub-projects.

Based on the nature of the company, the master projects' and sub-projects' nature may vary. For example, in the case of a mall construction, the following sub-projects could be created: preparation of the site and excavation, parking, infrastructure, roofing, etc. These sub-projects would therefore form cost centers; they would be linked to the master project, the construction of the mall. Based on the needs of the company responsible for this construction project, global costs could be redistributed to each sub-project or attributed to the master project, so only development costs would appear in the subprojects. Another master project example could be the construction of an office tower; each floor of the building would become a sub-project. Since it is possible to create multiple sub-project levels, each unit of the floor could constitute the sub-project of a sub-project. Finally, it would even be possible, in maestro*, to manage the ground floor differently than all other floors, because of its commercial potential.

 

In maestro*, it is possible to make configurations so that the determined percentage of an expenditure or income from a master project is redistributed to subprojects. Thus, a promotional expense can be allocated to the master project in a single entry instead of having to make five entries of 20% to apply the expense to the five condominium towers.

 

Standardization of project structures

Although each project may have its own list of activities, most users prefer to standardize this list, either globally, for their projects, or, at the very least, for the same type of project or cost centre.

The standardization of project structures facilitates data entry and the comparison between project incomes and expenses:

  • Over time and by dint of using them, the user comes to know the activity codes. In addition, several of these codes are configured by default and appear automatically on the first line of an order or purchase entry. The user comes to know which activity of a project should normally be charged for each type of expense.
  • This standardization can also allow the comparison of income and expenses between the various projects. This is particularly important for a company with several projects and whose performance may vary. Thus, with an identical activity structure, it is possible and easy to visualize the costs of various projects and identify the differences. It then remains to find the explanations for these differences. This is particularly interesting for residential entrepreneurs. Indeed, for the construction of the same model, an entrepreneur should expect very similar costs.

 

Several companies, including general contractors, use the National Master Specification for Building Construction (NMS). Built in 16 separate sections, the latter standardizes the various activities for the monitoring of a construction or renovation project.

In the past, the activity structures used by project managers often differed from those used in accounting. This had the effect, in addition to the double-entry, of complicating the comparison between what was happening on the site and the financial data. In addition, the project structure was often determined by the way the estimate was made. This made it more difficult to compare the actual financial costs to the estimated costs. With a project approach, it is possible, and even desirable, to use a cost activity structure similar to the one used to prepare estimates. The budget can therefore be easily transferred from the estimate.

 

The analysis of a company's actual or wished financial statement helps define the project structure to put in place in maestro*, since a great flexibility is allowed. The established project structure must also allow linking project costs to the project's starting estimate, so as to allow feedback.

 

Creating Project Templates

To facilitate the standardization of project structures (and, thereby, project costs), maestro* renders possible the creation of project templates. Project templates are standard project structure models, created by the company to answer to its needs. The creation of new projects is facilitated since all general ledger accounts, activities, groups, etc. are simply replicated and automatically copied from the project template. Various project templates can be created. Furthermore, many customers decide to create relatively elaborate project structure templates. Once the template is copied to create a new project, the latter is pruned, and unnecessary activities are simply deleted.

 

PAG and General Ledger Account

All maestro* transactions (each entry line, to be more precise) must be linked to a PAG, to then find themselves transferred to the corresponding general ledger account that will receive the incomes and/or expenses. This method allows for a greater project costs diversity and simplifies the financial aspect. This is the action of a transfer generating an accounting entry. Therefore, all non-transferred transactions are not yet taken into account financially.

Maestro* offers various methods when comes the time to link PAGs to general ledger accounts. Furthermore, it is possible to use more than one of the proposed methods and associate general ledger accounts on different levels. For example, when a transaction is done in maestro* and an accounting entry must result from it, maestro* verifies account configurations in a certain order. When an account is not identified on the project level, maestro* uses the configured default account for all projects.

A general ledger account can be linked to a group only. When this is the case, the expense related to this group is automatically carried over to the group's general ledger account, and not to the activity's. For example, the RL - Revenu Location group will always be carried over to the account number 40510, whatever the general ledger accounts defined in the project or default accounts defined in the General Settings are.

 

REMINDER

  • Maestro* is an enterprise resource plan, which allows to manage and follow the financial and operational data of a company.
  • We call transferring the action of pushing information from an option or module to another, through a transaction.
  • In maestro*, any entity for which we wish to establish a budget and/or monitor income and costs is considered a project.
  • All companies must, as a basic matter, have a "balance sheet" project, an "income and loss" project, and an "administration" project.
  • To the concept of a project, in maestro*, is added the activities and groups concepts, which allow the breakdown of project revenues and costs.
  • In maestro*, users do not make accounting entries per se. When entering a transaction, they identify and select the project, activity and group. The software is responsible for carrying out the accounting entries corresponding to the user's selections.
  • If the activities can differ according to the projects, the groups remain the same from one project to another. They make it possible to compile financial values based on their nature.
  • Companies who wish to obtain even more detailed data than those available with the use of a PAG structure can divide their activities in additional hierarchical levels called phases, sections, and divisions.
  • Type, category, and department notions allow the grouping of projects with common values, which makes it possible, in part, to apply security rules, limiting access to the data used to produce reports.
  • It's possible to group projects under a so-called master project, facilitating the distribution of incomes and expenses.
  • The standardization of project structures facilitates data entry and the comparison between project incomes and expenses.
  • Maestro* allows the creation of project templates to speed up the project creation process.
  • A company's desired project cost reports help determine the project structure to create.

 

FOOD FOR THOUGHT – PROJECT MANAGEMENT IN MAESTRO*

o

Are your projects or mandates diverse, in term of activities? 

o

What is your current project (budget) structure?

o

Do you follow up on your work estimate costs vs. your real work costs?

o

Are your project activities standardized?

o

How do you redistribute project costs?

o

What comparison do you wish to perform between your projects, and for which projects? 

o

What do you wish to view on your project costs reports? 

o

How could your projects be ordered?

o

What is the magnitude of the projects carried out by your company? Are they long-term? 

o

How are your project activities currently coded? 

o

Does a link exist between the coding and estimating? 

o

Etc.

 

Last modification: June 25, 2024