SM working on Fixed price project v/s Variable price project

Is there any difference in the working approach of SM when he works on Fixed or Variable price projects?

Could you elaborate what makes you feel the Scrum Master should work differently in either type of project?

@Steve - Could you elaborate what makes you feel the Scrum Master should work differently in either type of project?

Most of the time I keep hearing that have you worked on a Fixed-priced projects? 

So that made me think if there is really any difference in working on both type of projects.

Is there any mention in the Scrum Guide about a funding model and how it impacts the Scrum Master's role?

The Product Owner may be impacted as they determine the priority of the work, but I haven't been a PO so that's just an assumption.

I had the same question as @Steve Vb.  Not speaking for him but you didn't really answer the question for me.  Given the role of Scrum Master and their responsibilities to the Product Owner, Development Team and Organization how would anything be different regarding whether the project is fixed or variable priced?  Does the price associated to the project in any way impact your duties as a Scrum Master?

I will say that in my opinion a variable priced project would be much easier for the entire organization to undertake using an agile mindset and that Scrum would be better fit in that situation.  But the circumstance of cost seems more problematic for the Product Owner than for any other role in the Scrum Team.

I'll add to this in echoing the challenges that a fixed price can create when it comes to complex project and emergent design / work. 

The challenge is helping the business / stakeholders to understand the impact that emergent work may have on sticking to the timeline. They will either need to be much more ruthless when it comes to leaving scope out or decreasing the robustness of certain functionality (think MVP) in order to get a valuable project out within the timeline. 

This can be a huge mental hurdle for stakeholders especially if they come from a culture where leaving scope on the table means they'll never get it. 

What could happen is a push for all the functionality within the time frame at the sacrifice of quality and/or sustainable pace for the development team and others involved.