Many companies use a structured approach to project-management. Typically they use a documented method like Prince 2 because that makes it easier to hire new people who already understand at least the basics. But few small or medium-size organisations apply Prince 2 strictly, they usually take some shortcuts and use something that could be called "Prince Lite."
This usually works well enough provided whoever designed the shortcuts and the people that follow them understand what has been left out. Structured methods like Prince 2 work by splitting the task into a series of manageable chunks and documenting what questions you need answers to at each stage. As long as you have the right answers by the time you need them how and when you got them is not too important. The risk is that you may find that you missed collecting some information and when you eventually get it you find that some of your past decisions were wrong.
Structured project management does have overheads in the amount of time and effort needed to compile all of the documentation. But what this wins you is insurance against cock-ups. Make sure that the whole organisation knows and accepts this. Put some effort into communicating this to everyone. The message needs to come from the very top of the management tree. Every manager needs to understand that it is their job to make sure that there are sufficient resources, including the human kind, to cover that overhead.
Projects are like novels, they usually have a beginning a middle and an end. Unlike writing a novel you have to understand all three before you start.
When you plot out all of the tasks you may find that some of them make up a "Critical Path." This is the shortest possible path between the start of the project and its end. If any task on the critical path takes longer than expected then the whole project will take longer than expected. Keep an eye on these tasks.
You need to understand what defines the end of the project right from day one. There needs to be a list of all of the tasks that must be completed. Equally important is a list of the things that the project does not include. If you don't have that in black and white at the start of the project you risk people sneaking in additional tasks to meet their own objectives. This confuses the team, extends the life of the project and bumps up the budget. If anyone proposes adding in anything that is on the exclusion list make sure that they have authority to commit whatever additional resources that this takes. If it costs money only accept changes from people who have budget authority.
It's worth working backwards from your success criteria when you build a project plan. What are the pre-requisites for success? What are the pre-requisites of those pre-requisites? Hopefully the plan extending from the start will meet up with the plan extending backwards from the end. If not then you are in trouble!
The project isn't finished when you reach its objectives. You need to take some time to understand what went well and what didn't. What would you do differently next time? The technical term for this is "lessons learned." The lesson you usually learn is not to do it again. Teachers call this a "learning experience."