Well, talk about cratering a schedule and resource plan!
Layoffs in the middle of a project will do it for you.
But wait!
There may be a silver lining here:
- Communication complexity in and among project participants decreases as the square of participants. That could be a winner
- You may be able to select the departees. That's tough in any circumstance, but it's also an opportunity to prune the lesser performers.
- Some say that if you want to speed up a project, especially software, reduce the number of people involved (the corollary is more often cited: adding people to a team may actually slow it down)
- There's an opportunity to rebaseline: All the variances-to-date are collected and stored with the expiring baseline. A new plan according to the new resource availability becomes a new baseline. Unfavorable circumstances can perhaps be sidestepped.
Of course, there are downsides:
- If your customer is external, they may not relent on any requirements. You're stuck trying to make five pounds fit in a three pound bag.
- There may be penalties written in your project contract if you miss a milestone, or overrun a budget. That just adds to the fiscal pain that probably was the triggering factor for layoffs.
Did you see this layoff thing coming?
- On the project balance sheet, you are the risk manager at the end of the day. So, suck it up!
- And there's the anti-fragile thing: build in redundancy, schedule and budget buffers, and outright alternatives from the git-go. And, if you didn't do those things in the first baseline, you've got a second bite at the apple with the recovery baseline.
