Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Management & Leadership

Assumptions and project planning

Freshness Warning
This blog post is over 5 years old. It's possible that the information you read below isn't current and the links no longer work.

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.

Recently Written

A Framework for Scaling product teams
Oct 9: The people, processes, and systems that make up a product organization change radically as you go through the stages of a company. This framework will guide that scaling.
My Networked Webcam Setup
Sep 25: A writeup of my network-powered conference call camera setup.
Roadmap Outcomes, not Features
Sep 4: Drive success by roadmapping the outcomes you'll create instead of the features you'll deliver.
Different roadmaps for different folks
Sep 2: The key to effective roadmapping? Different views for different needs.
Micromanaging and competence
Jul 2: Providing feedback or instruction can be seen as micromanagement unless you provide context.
My productivity operating system
Jun 24: A framework for super-charging productivity on the things that matter.
Great product managers own the outcomes
May 14: Being a product manager means never having to say, "that's not my job."
Too Big To Fail
Apr 9: When a company piles resources on a new product idea, it doesn't have room to fail. But failing is an important part of innovation. If you can't let it fail, it can't succeed.

Older...

What I'm Reading