Assumptions and project planning

When your assumptions change, it’s reasonable that your plans and needs change as well. But too many managers are afraid to go back and re-work a plan that they’ve already agreed to.

A manager received a large project that was crucial to the success of the company. Shortly thereafter all the managers then went through a company-wide planning exercise to determine staffing and budget needs for the coming year. He devised a budget and agreed to a plan with his managers and peers.

The manager felt confident in his projections and requests. Then, a few weeks later, once the team had started building the product features, he started to realize that there was a lot more work than he’d anticipated. He could still get the project done in the desired time frame, but he’d need more people to pull it off.

How to communicate this back to the company? You’ve agreed to a big plan and a budget, then a few short weeks later you come back and say you were wrong. Won’t that look like you’re bad at planning?

Especially in the early stages of a project, software development requires making a lot of assumptions. You think the existing production infrastructure will be enough. You expect a certain level of usage and strain on the system. You believe the algorithms you’ll need are like ones you built two years ago. The user authentication model will support this with only a few safe modifications. We can probably re-use most of the data model we created for the previous product. Your estimates for a budget, scope, and delivery dates all rest on these assumptions.

Once you actually start working on the project, you’re going to find out that your assumptions were wrong. Every time. But most of the time, the degree to which they are wrong isn’t a big deal. You might have even assumed something was a lot more complex and difficult than it turned out to be.

In this case, the team was integrating its software with various third-party systems. Because all the systems do roughly the same thing, it the team assumed that the implementation would be largely re-usable between vendors. This assumption was wrong. The result was that there was a tremendous amount of repetitive work required to implement each system. The team did not expect the amount of technical analysis, testing, debugging, monitoring, and general vendor management.

The assumptions were wrong, so the estimates and budgets were wrong. This is something that the company leadership should understand. The manager should go back to the company leaders and show the assumptions and the issues with them, then negotiate an increased budget, a reduced scope, or an extended timeline.

What a lot of managers will do instead is try and make the original plan work, even though the basis of the plan bad data. Rather than worry that you’ll look silly by raising issues so soon, realize that the rest of the company needs forewarning, not perfection. It’s better to give bad news now and avoid surprises than it is to give bad news later when it’s too late to do anything about it.