Burndown
Big-Picture Project Management
To me, the key feature of Burndown is it's automatic scheduling. Add and prioritize your projects, add high level deliverables, assign your team, and it automatically and intelligently builds your schedule. As work happens, it automatically updates to show when projects are expected to be done, whether anyone has overtime, and more. Awesome!
But.
Our previous visualization, based on a burndown graph, didn't do a great job of showing you your schedule. It was focused more on total team capacity, and based on quick-to-implement off the shelf graphing tools.
We recently launched a brand new visualization that's focused on showing each team member's schedule. At a glance you can easily see:
- when every project is expected to be completed
- if anyone is underutilized
- if anyone is overutilized
- if any project is in trouble
- when everyone is on vacation
- and more!
This also included a much improved auto-scheduling algorithm. It's faster, smarter, and makes better default choices for you.
Exciting times!
Current Problem
We need to talk to prospective users who are actively feeling project management pain and are attempting to find a solution. The large majority of customer development interviews thus far have been more background and research-oriented. We need to know how many people are seeking solutions and if our current assumptions match their problems.
Actions Taken
I made a very basic landing page for the website that links to a Typeform-based application where visitors can apply to join our early testing program. I'll follow up with interested applicants to conduct deeper interviews and glean marketing information along the way.
Results So Far
3 Applicants
2 Interviews Scheduled
Asks
Share the site! Do you know anyone who manages projects and is frustrated by missed deadlines or time-consuming meetings? https://projectburndown.com/
We did our first user test of Burndown with Expected Behavior's CTO, Jason. It was his first time seeing or using the software since we started working on it. Burndown is not complete enough to use internally, but his goal is to start using it to maintain a basic roadmap (a prioritized list of projects we're planning).
We thought it was going okay until he said "Well, you obviously can't trust the dates". Not what you want to hear :)
After much discussion, we decided that having accurate delivery dates requires an in-app understanding of Company Holidays, Vacation, Work Days and Individual Capacity. We knew this would be necessary, we just hoped it wasn't table stakes. Turns out it is! Back to building!
You can see the full write up here
-
2
I haven't seen any organization achieve accurate delivery dates to where holidays and PTO would matter in over 25 years of coding except for small features and bugs. I think Jason is sending you down a rat hole.
-
2
Maybe! We made and used Burndown internally many years ago when Expected Behavior was a consulting company. Back then we had great success achieving accurate delivery dates, but product businesses are pretty different from consulting businesses. We'll see!
-
2
Hmm when I worked for a consulting company doing large projects we were also way, way off schedule. I'm sure you had great success and accurate delivery dates but likely it was for better defined requirements and deliverables similar to what you delivered before.
-
2
Thanks! As the project manager back when EB did consulting I like to think my requirements gathering and management played a part in our ability to be accurate :) I'm inferring (and maybe incorrectly) that your experience indicates the project management tools used don't make much difference when it comes to delivery outcomes. Is that right?
-
3
One of the big project misses I saw was ironically while working for Clarity PPM - project and portfolio management software. But that project wasn't using PPM but rather Scrum and burn down charts.
I've also seen a lot of Jira backlogs with estimates - sometimes filled in just by a team lead and sometimes using Scrum pointing.
Finally I've seen "dark side of the moon" product creation. Dark side of the moon in the sense that you either finished within your funding or finished enough to convince your backers to give you more funding.
So I guess I've seen project management and process sometimes make some difference to reliably predicting the rate of software delivery. However that's not the same as saying I have seen it have an impact on outcome. Outcomes are much more complex and depend on all kinds of factors.
-
-
-
-
-
1
We thought it was going okay until he said "Well, you obviously can't trust the dates".
Be careful how you interpret this response… also, 1 person is really not much to go on, I’d suggest you keep doing customer validation before you go off on a monumental building spree.
🍻
-
1
That's definitely true! The good news is that this learning has actually led us to a simpler data model that in turn simplifies the automated scheduling algorithm. All in all, this will be a relatively small building spree that I think gives us a better foundation moving forward. We'll see, though :)
-
1
Very true! We're doing a lot of customer validation and I'll have a larger writeup on some of our learnings soon. This was a user test of the actual product.
-
After a few weeks of building, we've just demo'd the state of Burndown for the rest of our team. Our main goal right now is to get everyone on our team using Burndown for project management and planning ASAP, and this demo was the first step. We got some good feedback and developed a short list of what's blocking our internal beta.
The original goal was 10-20 interviews. I think some of these potential users (mainly people with "project manager" titles) will be outside our target market for now so I plan to keep interviewing.
Current learnings/assumptions include:
- Many people spend 1-5 hours per week on high-level project management work, often in meetings with others
- Most people are okay with projects regularly going over schedule. They say they're not, but their actions prove otherwise. Few people actually tackle this problem.
- Some people don't write down their projects. It's all in their head.
In general, I feel good about pain validation, but I'm concerned about the number of people who aren't actively seeking solutions to their pain.
We have some fairly strong opinions about what's missing from project management software today. We've written those down (internally first, and then for public consumption) and now we've got them all published.
Keep The Big Picture Separate:
https://www.expectedbehavior.com/building-burndown/keep-the-big-picture-separate/
Schedule Important Work First
https://www.expectedbehavior.com/building-burndown/schedule-important-work-first/
Many Hands Make Light Work
https://www.expectedbehavior.com/building-burndown/many-hands-make-light-work/
Burndown is based upon strong ideas and opinions we’ve developed over years of trial and error as a consulting company and then a product company. We’re confident Burndown will help us, but we’re less confident anyone else will share our faith.
Describing Burndown’s philosophy and product choices provides an opportunity for others to provide feedback and follow along. If no one else is interested, then Burndown is probably just for us. But if others share our opinions (figuratively, in their hearts, and literally, via social media and whatnot), that’s a strong indicator we should grow it from an internal tool into a real product.
And while we're far from the first to build in public, we hope sharing our own unique takes on design, development, and product management will inspire others the way we've been inspired by others building in public.
Comment