Planning and estimating large-scale software projects
Entire teams of people, who aren't software engineers, and are used to being held accountable for delivery dates in their fields, will expect you to be able to tell them when your part of a project is likely to be done. There's plenty of information about how to estimate velocity out there for a single team - whether that be through planning poker, story points, or backlog story tracking without estimates at all, but none of those work across huge projects involving multiple teams and departments. Top-left is the "Code" that can be used in planning software to refer to this task, when allocating it to a team. Now ask each team lead to go through their cards, referencing the source material, and assign an estimate in weeks for an entire team. We've got a dependency chart - which can double as a project plan - we know what team is likely to do each piece of work, and we've got an estimate, in weeks, for each item on it. In the easy case, you just need to make sure your total team-weeks is around 50% of your current staffing level, and you should be comfortable having a pretty easy conversation with your CEO. If it's not, you can have a conversation about hiring, taking into account the significant overhead and time-lag in onboarding new team members, and the diminishing returns inherent in growing your team. Don't fuss about detailing every requirement up front; get your engineering teams as close to the client/user/original source of requirements as possible, give them a few words on an index card, and urge them to demo often; trust your engineering teams to figure out exact user stories, acceptance tests, and the like.