Question: I'm about to enter a role as project manager. I have attended a lot of projects with quite a span of aspects, constraints, contents, parties and whatever and also had some technical leadership tasks but this time it would be the very first time to receive the label "project manager".

While I'm thinking about it (I have some weeks/months left, it'll be mainly about software and electronics) I oscillate between "this is incredibly difficult, I wasn't aware of that.." and "this is so trivial, what's the deal?".

Actually, the project constraints (time, budget..) have to be met by everyone, so what is the real task despite of having a kickoff meeting, distributing tasks and occasional meetings about the status?

What I especially wonder about are the followings:

* How do I "make" others do their work? I mean it's ultimately their job but when someone is slow, maybe due to reasons like it's more difficult than expected or whatever, what could a project manager do then?
* Projects always have some kind of uncertainty and in my opinion it is nearly impossible to check all possible risks and minimize them. I'm especially thinking about some projects in the past which involved chemical experiments (which were quite a hazzle and turned from 2-3 months to 12-18 months..) and also mechanical engineering where single pieces also took way longer due to occupied machines, limitd materials and so on. You can hardly make an external workshop work faster when it's simply not possible and replacing one with another will quite a while to discuss and set up everything so there would hardly be any acceleration.

Wanna' share some minds and/or experiences?

Answer: 
In addition to the good answers already given (T&M is the way to go) you should also put emphasis on customer expectation management. From the beginning, make it clear that you promise knowledge gain, not a finished product.

If the problem is one where it is known that solutions exist (for example because the big players in the field have them) and you just don't know how they do it, it's much more difficult. Your customer may expect you to build something they know can be built, but you may not be able to do that (as it requires R&D on your part, and you can't be sure that the R&D will lead to you being able to build the desired product). Your customer needs to be aware of those constraints before starting the project, as they may decide to look elsewhere, for example buying finished software, or contracting with someone else who already has experience in building such applications. Although that would mean you lose the contract, it might be better to be honest and spare the customer a disppointment.
I would expect any research project to be done on a daily or hourly rate. It's implicitly the nature of R&D that the work is what matters and the outcome is uncertain, so the work is what you should be paid for. A Kanban-style, continuous delivery approach makes sense for R&D: prioritise the items of value, inspect and adapt as you go.