This is more about what to keep in mind throughout the project than what you should technically follow. For that, you need to complete your PMP or similar certifications.
#1 - Planning
I know this sounds pretty obvious, but I don't mean just planning with approximate dates when all your tasks can be completed. The buffer time for things that might go wrong, possible delays in receiving data, project team members holidays (or even resignations) and that regression testing after system is ready. There can be many things that require adding to the plan which most beginner project leaders miss and get disappointed when the project is status 'red' and the blame game begins. To truly enjoy the project, make sure it stays within the timeline and there is always enough time to manage obstacles and unavoidable circumstances. The risk factors are actually easy to forecast, if you think about your last 3 projects, the only problem is you keep using the same project planning template.
#2 - Change Management
When you are implementing a software, the management will be excited in the beginning and the users will see you as a new villain in their work life who will only make their lives miserable. The management team's energy goes down when users keep complaining about your "bad service" and nothing is good or exciting about this new software. It is the duty of the project leader/manager to keep the audience engaged and excited about the new change.
Organize trainings, distribute well designed and well written process documents, share exciting news about similar technologies around the world and make them feel that they are part of the history that future generations will talk about. If users don't enjoy the process or feel that they are doing something meaningful, they will find it difficult to adapt to the new change and will resist going live.
#3 - Documentation
Make sure you keep all the documents of the project organized and well distributed. If the stakeholders find your documents shared inconsistently or do not provide all the required details, they will stop opening your attachments. Keep your documents well designed and make sure the users can easily identify which part of the project plan that document relates to.
Tell the users in advance what documents will be shared with them and in which phase, they will expect the documents and wait for them, follow them and keep them.
Documents are useful proofs of things done. They protect both parties of the commitments done before and during the project. The signoffs, user manuals, flow charts and minutes, if well written and shared with the right group of people, there will be so less chance of miscommunication.
#4 - Communication Log
Project manager needs to keep log of each communication related to the project. Which email was sent when, who raised a concern and when, if it was addressed within the expected timeline. With "what" is communicated, "when" it was communicated is also equally important. If we don't have the history of communication, the client or consultant might end up saying it was not communicated or not communicated when it should have been communicated.
If someone says, I said it sometime in March or I've been saying this since the start of the project, and you have to agree because you do not have a communication log or guidelines provided to the client or consultant of what is the preferred method of communication and how each communication will be logged for future reference.
