No significant long-term project can run without at least one significant change. A change would be defined as a departure from the approved provisional plan.
Changes at the beginning of a project might bring some inconvenience, but at the end, disastrous consequences. We must understand, therefore, that the later the changes in the project life cycle, the more costly consequences.
Below figure, presents helpful understanding of the costs of change derived during the project life cycle.
Change can be requested from within contractors own organisation without any involvement from customer, or changes might be initiated by customer or client.
Below figure provides an information of general change sources to a project.
Labelling changes as "funded" and "non-funded" is a very useful way of change classification. This will allow to determine who takes the responsibility for the change, either customer or the contractor internally. Changes also involve updates of completion dates, therefore both should be communicated to customers.
Types of change
Funded changes often arise due to change of specification from customer. This would generally result in the increase of costs that customer shall be made responsible for. The delivery schedules are often affected, therefore those should be discussed, agreed and documented.
Unfunded changes occur within the contractors processes and customer can hardly be expected to pay. Unless, contingency provisions were made in the contract. The contractor must, therefore, take on board any additional costs and answer to customer of any schedule delays. This would start from issuing engineering change request or similar names document.
Both funded or unfunded changes can be either permanent or temporary.
Permanent changes will be embodied with the design or specification.
Temporary changes may be implemented until permanent solution is found.
Change approval
Any changes shall be approved before implementation. They could affect the technical, quality, time or cost and adversely affect the project. The approval, should be derived from all team members and managers involved. Discussion on any non-anticipated consequences need to be obtained. The approval process, therefore, is a great place to achieve it. Often, project change committees are formed for this purpose. The members should be able to answer for safety, reliability, performance, cost and timescale consequences, the effect on work-in progress etc. Often, quality managers with engineering staff play the key role in here.
In larger projects where change requests are often, regular change meetings are being held. Each member should review the consequences of change within their area of responsibility. Generally a formal meeting works in any types of projects.
Before making decisions each member should consider:
- Whether the change is possible to make?
- Is that a customer requested or self-developed change?
- What is the estimated cost of the change?
- Who will pay for the change?
- If the change is not customer requested, is it necessary?
- What will be the effect on the project plan timescale?
- How will safety, reliability and quality affected?
- At what point this change can be introduced?
- Will any waste or scrap be created?
- What is the status of the items affected?
- Will there be resources available on time to proceed with the change?
- What specifications, documents, drawings will have to be modified?
When all the aspects have been considered the committee might either: accept, give limited approval under conditions, ask for clarification or refuse the change, providing the reasons.
Below decision tree might be used for change approval (see figure below).
Change administration
Any requested changes should be put in writing. In some projects even customers are requested to do it. Change coordinator might be appointed. Their duties would be to register the change, distributing copies, following up to ensure changes are approved and then actioned.
A good idea would be to keep a change register. It can provide a basic information including: from which source change was requested, price the changes, and for traceability. Often serial numbers are allocated for different changes.
An example of change register is presented below.
After the change has been added to the register, the co-ordinator would arrange its distribution. It can be sent to relevant managers who will then communicate to their departments.
But, how do we estimate the true cost of change?
We know already that most changes will cause costs and, the later the change during the project, the higher the costs.
To estimate change we often might need to add additional tasks of re-work, replacements, preparations, charges absorbed due to the change, additional direct labour and overhead costs, additional materials, contingency allowances and mark ups to come up with the additional project price resulted from the change.
Sometimes, it might take several weeks to action the change and additional resources will have to be added. Additionally, other resources may suffer the knock on effect due to the change. The project might not be completed on time, loss of prestige might suffer.
We have to assess all possible cost factors.
In the ideal world we would like to include all possible costs of the modification. But some might be impossible to assess or they can be overlooked. Checklists can help with it:
- Do we need re-testing or additional inspection of the job?
- Will existing stock be affected?
- Will there be any purchase order cancellation costs?
- How the change will affect the product or service development in-progress?
- Do we have to scrap anything?
- How much will be the delay costs?
Nevertheless of the difficulties in assessing the costs of change, some estimates can be made.
Sometimes the change might involve scrapping part of a product already developed, which can be priced by the costs of the product already made.
Some change might require quicker delivery and the costs would involve the additional resources required to deliver order quicker.
Do we need a formal change procedure?
Generally, any internal changes before formal drawings are issued do not require formal change proceedings. However, changing the revision numbers will evoke formal change process. It can be difficult to define when a formal process should be started. It might help to know that if the proposed change will affect any instruction, specification, plan or budget that has already been agreed with other departments, the customer or other external organisation it would be reasonable to start the change process.
Changes requested by customers which affect price, delivery or other aspects of the original purchase order or contract should be documented.
The change should trigger an amendment of the purchase order or contract, it is authorised, funds and payments agreed and records any changes to the overall project deadline.
Changes to purchase orders will result with customer re-issuing the Purchase order. For contracts "project variations" are issued.
An example of project variation order is presented in figure below.
Sometimes in projects a number of changes are expected and the cost of change might be recovered in some agreed time against the agreed schedule. Sometimes small changes costing is out of the question, however, it would still be reasonable to document them. Sometimes, a set price is agreed for all those small order changes. Each detail of the change is than authorised by the customer and accepted for action by the contractor. Then, weekly or periodic invoices are set to customers multiplying the number of changes made by the set price. Many changes in projects are often managed this way. This saves valuable time for calculating the change costs and billed using simple set price procedure.
In design, the change would involve to request for description, formalisation and approval for formal design change. Those, might be either funded or unfunded. A typical engineering change order is sampled in figure below.
The reason on why this process should be used is self-evident.
In manufacturing environments often the operations team might want to "cut corners" (deviate from original specification) to meet project deadlines. The quality department would need to keep a close eye on those instances.
No unauthorised shortcuts should be ever taken.
Sometimes, for example, a part or material might not be available and operations team might seek to use substitution. If the operations might want to make the substitution without change in the design there is a risk of rejects during inspections. Someone has to decide to either authorise or reject the change.
The use of alternative materials, production with different tolerances trigger requests for concessions. They might present risks to performance or safety. Generally, concessions require a formal approval of the design authority.
Sometimes, temporary changes may only be needed without the need for updating the original design. Quality department would discipline such cases. Concession request is presented in an example below.
The reasons for using such procedure is self-explanatory and they can prove helpful in quality department processes. We need to keep those in records in cases of poor performance and failures in the product or equipment after handing to customer. If one part in batch fails, it is also reasonable to trace the remaining parts of the batch produced.
A good idea is also to maintain a concession register that can support the drawings, modification records, test and inspection records.
Design errors
When new design is issued it is often released untested. There are always risks of design errors or misinterpretation of the design. These can be resolved in correcting the design or training for the user. At times, when issues are faced an 'engineering query" is issued. An example of such query is illustrated in figure below.
The process allows to explain difficulty and submit to engineering department for investigation. These queries should be given urgent considerations. All queries can be registered to ensure none of them can be forgotten.
Sometimes, however, issues might not be easily resolved on a spot and temporary solution is needed. The temporary resolution hold the authorisation to deviate from drawing, therefore it becomes concession.
Often, in quality inspections non-conformances are issued if the final product deviates from the specification. These should always be discussed with the engineering team to avoid unnecessary scrap. A product can pass through inspection by authorisation of the engineer.
Figure below shows such inspection report example.
Version control
Mistakes can also happen when an engineer makes a change to a design without issuing new revision number. Unless there is a system to keep the versions under control there are high risks of such mistakes. These types of errors might cause embarrassments during inspections.
The best point of actions would be to always re-issue new revision number to avoid such mistakes. No exceptions should be allowed.
Sometimes a need for change in specification or design is required during a production. Engineer might be able to update the in-production design copy, sign and this way authorise the corrections. These urgent corrections are sometimes unavoidable to keep the project timescale on time. But, we must always remember to update the original drawing as well. This can be done through formal modification procedures. The copies of updated documentation must be passed to the design office for the changes to be incorporated into drawings.
Summary
Changes might creep up at any point of a project life cycle. Changes with scope might reduce or increase costs, other changes might result in scrap and exceeding a project timescales.
It is imperative, that both customers and the contractors keep eye and register or such changes, including the effect on price and delivery. Once both parties agree administration is required.
Comments