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 blog post is over 1 year 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 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

The Components of A Developer Experience (Sep 19)
Making your API a well-rounded product will help developers decide if your API is right for them and help grow their usage.
Principles of Developer Experience: An Introduction (Sep 15)
You can create a great developer experience for everything you build. Introducing the six principles of developer experience.
The KPI that measures Product-Market Fit (Sep 9)
If you ask this question to a different small group of your users every week, you can measure trends over time to determine if you're moving toward product-market fit.
Don't use NPS to measure user happiness for enterprise software (Sep 7)
Measuring the satisfaction and enjoyment of end users is a key to unlocking product-led growth. Net Promoter Score is the wrong tool for this.
Ask One Question To Help You Reach Product-Market Fit (Sep 3)
Learn what adjacent problems you need to solve to become twice as valuable to your customers.
How to scale your product team from one product manager to an entire organization (Aug 25)
As your product management team scales, you'll have issues around redundancy, communication, and consistency. Here's now you might solve those.
Software engineering manager interview questions (Aug 6)
Here are some questions I like to use to get a sense of who an engineering manager is and how they work.
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.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.