A project is conceptualised based on the location of the land, micro market characteristics and development control regulations applicable for that location (municipal guidelines).
Rule 6.2 DP Design optimisation
The endeavour of the designer shall always be to optimise the development without compromising functional supremacy of the development by following the development control regulations.
Rule 6.3 Lead Design Consultant appointment
As a policy, all the designs of the project shall be done by engaging a Lead Design Consultant (LDC) who in turn shall appoint the other packages (MEP, Facade, Lift etc) design consultants under the LDC agreement. Objectives/deliverables of the sub-consultants to be outlined clearly up front. Responsibility of the LDC to ensure performance of sub-consultants. Phoenix shall liaise only with the LDC for all the design deliverables.
One of the critical shifts between the way the project used to be executed earlier and now, is the discipline of following a development plan. This plan has been created as a sequence of logical tasks to be adopted from the start up to ground-breaking of the project, by keeping the operational constraints in view.
No project shall be launched for construction unless:
(a) The approvals are received
(b) Funding is tied-up
(c) All designs are concluded
(d) GFCs complete and are issued.
From our past experience we have realised that most of the delays in projects are attributable to 3 things:
- the change in design,
- delays in issue of drawings or
- delays in approvals.
Rule 6.4 Start of the construction
Effective as of this date, start of the construction shall happen only on completion of all the steps in the Development Plan and Gateways are concluded as per the Development Plan.
The Development plan is broken up into multiple milestones and each milestone is considered as the Gateway closure where a set of documents are handed over from one to another department. Via a joint handing over workshop, to confirm understanding of the information and its content, is transferred with common agreement of the event is complete.
Rule 6.5 DP Deviations
All the key stakeholders shall follow the steps given in the Development Plan without any deviations. In cases of deviations due to unavoidable reasons, it needs to be approved by the Group CEO with identification of the deviations in the process.
The development plan is given as Appendix 5. The same has been reproduced here for identification.
Rule 6.6 Practices for Development plans
Following additional best practices shall be adopted for Development plans.
- Change in design before Gateway issue to construction team (Before Stage B completion) needs to go back to requisite point of Gateway design and process needs to be started from requisite point again.
- Designs once concluded as part of the Gateway cannot be changed unless there are;
- errors in the plan requiring revised drawings
- change of government norms / regulations retrospectively and
- site constraints leading to huge cost & time impact.
- In case of requirement of change in the design due to stipulation by a potential client during the course of project execution or for reasons mentioned in the rule above, the change needs to be evaluated in terms of;
- Present status of construction
- Feasibility of the change with input from consultants and site team and
- Cost and time impact on the project, by the GM, presented to the management for approval by way of Review and Recommendation.
- Only after the formal approval, the change in design shall be agreed and adopted. Until the R&R process is completed, neither any commitment to the client should be made nor the contractor should be informed of possible change
- Under no circumstances construction of a project shall start unless the approvals are received, designs are concluded with GFCs and financial closure is achieved
In the table below we have listed out all the tasks within the Development plan. As a strategy, processes for all of these, will not be detailed out initially. We have focussed only on those critical tasks, which need to be detailed now and those which need to go online in the ERP, backed by a process flowchart. Our endeavour is to eventually move all of these tasks into ERP backed by a process flowchart.
Back to Top