Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

Assumptions and project planning

Freshness Warning
This article is over 1 year old. It's possible that the information you read below isn't current.

When your assumptions change, it’s reasonable that your project 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.

Recently Written

A framework for onboarding new employees (May 15)
There’s no single good way to onboard an employee that works for every role. Here's a framework for creating a process that you can adapt to each situation.
TV hosts as a guide for software managers (May 10)
Software managers can learn a lot from journalists or late night TV hosts and how they interview people.
The Improvement Flywheel (Apr 29)
An incredible flywheel for the improvement of a development team. Fix a few things, and everything starts getting better.
Managers and technical ability (Dec 26)
In technical fields, the closer you are to the actual work being done, the closer your skills need to resemble those of the people doing the work.
Dysfunctions of output-oriented software teams (Sep 17)
Whatever you call it, the symptom is that you're measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.
Evaluative and generative product development (Aug 30)
Customers never even talk to the companies that don't fit their needs at all. If the only product ideas you're considering are those that meet the needs of your current customers, then you're only going to find new customers that look exactly like your current customers.
Product Manager Career Ladder (Aug 19)
What are the steps along the product management career path?
Building the Customer-Informed Product (Aug 15)
Strong products aren't composed of a list of features dictated by customers. They are guided by strong visions, and the execution of that vision is the primary focus of product development.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.