When a project is fully identified (depending on individual company policy) it is loaded into the Muli system. This could be when major estimating effort is intended or when  the project is won.

The first activity is to load the project master record, which effectively sets up all the controls that will  be imposed on  the project throughout its life.  Project Master Maintenance (2.1)

How the contract price was developed,  determines the way in which the budget is loaded, either directly from the Muli estimate, or utilizing a skeleton and then manually loaded.   Budget Maintenance Routine (2.4)

It is important that the budget is loaded with separate identified values for each of the individual orders and subcontracts that need to be let, and for major subcontracts the major elements. This leads to the: Detailed Budget Report (2.5)

1. Budgets may be established for Lump Sum or Construction Management.
2. All budgets are net [excluding] GST.  Overhead recovery and profit are grouped in a single allocation (9800) called Project Contribution.

Variations are the first of many documents that are produced by the Muli system to ensure that no commitment leaves the organization  that is not recorded as part of the project database.

Note: From a control perspective, Muli recommends the first variation written is the hand back to the client of any PC  Sums  and the raising of ball park values for the contract stated  PC values for each item. Thus the client has to approve the PC Variation  for a budget to exist and therefore to place the order. See Variation Master Report (2.7)

Variations are processed through 3 stages:

• Ballpark - change in scope by either changed documentation or client request - insufficient detail exists for firm price so a ballpark or indicative value.
• Submitted - A firm price has been submitted for client approval.
• Approved - The project manager has a formal approval of the Variation. (piece of paper with scope of works signed by the client)

Back to Overview