Planning and the Bungie-Boss
Dilbert has many strips about the bungie-boss. Our challenges and expectations about planning may be both the cause and effect of leadership curn. My experience at a Fortune 100 company was that in one year, everyone who started the year as a project lead exited. Perhaps this was due to the planning problem. Not sure if your former lead left for this reason, but when your role requires you make a plan with a commitment, if it does not come to pass, often, a deadline related exit is the result.
Organizational Context of Planning
If you are uncomfortable with planning, perhaps you are uncomfortable with being accountable for commitments made to marketing or other stakeholders before the problems to be solved are documented or understood. This is a good instinct.
Planning is an important tool. Don't neglect it. Don't misunderstand it.
Planning is integrally linked to commitments, accountability, and negotiating power. Agile planning has many merits. You should know its techniques, as well as the techniques of planned methodologies. Your organization may have its own approach and getting advice and working with someone who has survived leadership of many projects many be surprisingly helpful.
A Simple Planning Example - Must not be about software...
If a roofing company came to my house to bid on a replacement, if they bid too low, they may lose money on the job, but if they bid too high, they won't get the job at all. Either way, they are out of business. In your new role, if you bit too low, you will run the project until the accountability kicks in, then you will have problems. If you estimate a project with enough padding to insure success by the deadline, they many just pick someone else to lead. The kicker is that you are not like the roofer. He can see how big the roof is, and has historical data about how long that size roof takes.
Becoming a Better Planner
You may wish to consider some kind of training. In Agile methodologies, and most recent planned methodologies, estimation is a team wide activity. Consequently, you should consider getting training for your team as well.
From experience, I can tell you it can be frustrating to get estimates from team members who will put it off, give you estimates they make in two minutes based on the task name without reference to a requirement or feature description or the existing code, or who insist that several of the tasks you list can be done in some fraction of a day even though past projects have spent weeks on similar issues.
There are various project manager training courses and certifications, but I would watch for one that was independently accredited. It might be worth a second thought before choosing to certify with approaches based on planned methodologies if you expect to work with Agile teams (or the other way around).
SLIM is a method invented by Putnam after working at GE and other companies on DoD projects in the 1970's. SLIM is influential, and his company QSM offers a certification that seems to flow out of a tool that they make. Depending on whether your company has adopted their tool, it might have either no value or high value.
Steve McConnell (author of Code Complete) also wrote a book about software estimation, and his company Construx teaches two classes for PDU credits that are accredited through the Project Management Institute. I have his book, and if I wanted to learn about the topic via classroom training, I would probably pick Construx. They also do Scrum training and administer various scrum assessments accredited through Scrum.org.
Another source that could provide great academic training about software project estimation, would be Barry Boehm's group at USC, based on their extensive work on COCOMO and COSYSMO constructive cost modeling which has been used at NASA and other large contractors to estimate very large projects. I am not sure I am a true believer in COCOMO, but I like the empirical work they have done to correlate the effects of scale and cost drivers on schedule duration.
I also found a chapter from a textbook published by O'Reilly that briefly discusses major software estimation methods including Watts Humphreys PROBE and Kent Beck's planning game. PROBE includes a notion that engineers track metrics on their own productivity, then apply them to their assign part on new projects. Planning Game is very highly collaborative between developers and other stakeholders.