PM Interviews: Bruce P. Henry

This week I caught up with Bruce P. Henry, Director of Rocket Science at LiquidPlanner, to find out what he’s been up to, glean a little more information about LiquidPlanner and explore his views on the future of project management.

Q: Many people will already know you from your blog Bruce’s Brain and your involvement with LiquidPlanner. Can you give us a brief summary of your career to date?

My involvement with technology started in Hollywood. I ran a computerised teleprompting business out of my garage for a couple of years before switching to Macintosh consulting. After a year or so of 18-hour days, I left Los Angeles and moved to Laramie, Wyoming to pursue a degree in Physics. I took my BS in Physics and BS in Mathematics from the University of Wyoming and then headed to graduate school at the University of Washington. With my MS in Physics firmly in hand, I began testing software for Microsoft as a contractor. I went full-time at Microsoft but was lured away by Ed Jung and Nathan Myhrvold to join OpenDesign. Two years later I joined Expedia as a test lead and, over five years, worked my way up to becoming their Senior Director of Quality Management. I left Expedia and joined Charles and Jason at LiquidPlanner in 2007.

Q: I imagine LiquidPlanner has been the focus of your attention for the past year or so. How has that time been?

I think working at a good start-up is kinda like riding a hyperactive roller coaster. You have these huge ups and downs and sometimes they come just minutes apart. In general working at LiquidPlanner has been fantastic. I’ve gotten to do everything from writing some code (not much, but some) to meeting with investors and the press.

Q: Can you tell us about some of those ups and downs?

I’d say the real high points were figuring out uncertainty and launching at the DEMO conference. The “Aha!” moment when we figured out how to capture and treat uncertainty and first saw our models behaving like real projects was something else. Literally the hair stood up on the back of my neck when I saw the sheer magnitude of what we were uncovering. There is so much opportunity for improvement in project management. Similarly launching at DEMO: standing up on that stage and just laying everything on the line and then hearing that people “got it”. That was amazing and really gratifying.

The low points for me have been realising the sheer scale of the work we have in front of us and cutting beloved features in order to make our launch schedule. There is such a huge amount of stuff we could be working on that choosing just one or two is really hard. I always find myself second guessing our choices and asking “Is this really the most important thing we could be adding to the product?”. Cutting features to make our launch date was pretty painful, even knowing that in the end it was the right thing to do.

Q: What specifically are you currently working on?

I am:

  • Building demonstration videos for the product
  • Writing help content
  • Writing specifications for upcoming enhancements
  • Travelling to faraway lands (Austin, Mountain View, and Penn State) to spread the word
  • Building and integrating the analysis tools for our website traffic and product usage metrics
  • Consulting with our CEO on VC and pricing strategy
  • Keeping the fridge filled with soda
  • Blogging

Q: What techniques have you used for the development of LiquidPlanner?

We use a “kinda scrum” methodology. I say “kinda” because we don’t do things like daily meetings formally. But we’re all pretty much in one room so daily meetings happen whether they’re formal or not. We built all of our UI prototypes in PowerPoint believe it or not. PowerPoint turned out to be really great because we could iterate on a design in a matter of hours and really look at the result. There were well over 200 versions of the PowerPoint prototype and they were worth every minute we spent on them.

Q: Are you using the LiquidPlanner yet to manage further development?

We have been using LiquidPlanner internally since early in 2007. We cut our first lines of code back in February of 2007 and began using the tool to plan our work in early April. It was pretty primitive back then but we got enormous value out of that experience. We use it religiously today for everything from tracking our bugs to planning our marketing. We are always using at least one version ahead of what we’ve released.

Q: Can you tell us a little more about probabilistic scheduling and the LiquidPlanner scheduling engine?

The term “Probabilistic Scheduling” was actually born fairly late in our process. When we first started out we knew that we wanted to build estimates in ranges. We had been to a Construx estimating training course and were completely convinced that ranged estimates were the way to go. But there were no tools that we could find that supported them. Sure, there were some that did the PERT thing with best/expected/worst case. But they just boiled those down into one number and that lost all the richness that we felt was there.

We looked at ranges and said “Well this is really an expression of probability”. So we treated it like a probability. And then something magic happened. I had this model in Excel and when we got the thing working we got all these crazy answers out…

The amazing thing was that the answers seemed to be telling us what we’d always known as project managers. Like a project with 10 people working on 10 tasks of about one month duration will take more than a month to finish.

Yeah, like duh. Every project manager knows that.

But the tools we’re used to using don’t seem to get it. Try that schedule in MS Project and it’ll tell you that you’ll be done in one month. Then you’ll have to add a buffer and argue with the project sponsor about why the buffer is so big (or there at all).

But sitting there in front of us was an incontrovertible mathematical reason why this happens.

I was all like, “Oh yeah… that makes sense.” and then I was bouncing off the walls excited for a week. Realising how much work it was going to take to do the calculations in a rigorous way, in real time, for projects with hundreds or thousands of tasks and a buncha people sobered me up pretty quick though.

Anyway, we basically take the range and infer a probability distribution. Then we use those distributions and the relationships between the people and the tasks to calculate a distribution for the project as a whole. Simple. The scheduling engine itself runs in the background on our servers while the user continues to work on other things in LiquidPlanner.

Q: What do you see as the greatest current challenge facing software project managers and what approaches do you think are required to address it?

We not only expect the code to work but we want it pretty, with shiny buttons and drop shadows, and running asynchronously on a distributed network with storage “in the cloud” and servers that repurpose themselves on the fly as load patterns shift and built by a geographically distributed team so it is cheap. And we want it yesterday.

In short, complexity. That’s what I think is our biggest challenge. We’re still developing on the bleeding edge for the most part and that’s a good thing but the complexity must be managed.

To manage complexity software project managers must walk a narrow line between being so risk averse that they deliver boring obsolete software and burying the project under a mountain of failures. Complexity and newness introduce risk. And with risk comes failure, always. As project managers we need to be able to be open and honest about the risks and take them in intelligent ways. That also means that we need to have a pretty good understanding of the underlying technologies so we can explain them to our non-technical stakeholders.

Q: What do you think has been the most important change in software project management over the last 10 years?

Wow. This is a hard question. It is really hard to tell what is most important until it is a few years behind you.

I think we’ve come to understand a lot more about the dynamics of software development projects. Thanks to folks like Fred Brooks, Steve McConnell and a host of others we have much more insight into what is driving the interactions inside of our projects. That insight has driven us to re-examine the way we run our software projects.

So, I’d say that agile methodologies and the new culture of openness in software development will, with hindsight, be the most important. I think that’s because we’re starting to treat the people involved more like people and beginning to acknowledge their human motivations in our software development processes.

Q: What is your number one PM tip, trick or technique?

Get your estimates in ranges.

I’m not kidding. Even if you do nothing “smart” with the range it gets you in the mindset of thinking of your project plan as a forecast rather than a road map. Once that happens you can start discussing what ifs, best cases and worst cases in a constructive atmosphere. It completely changes the nature of the interactions between the people, be they developers, testers, stakeholders or whoever else.

Q: What characteristics do you look for when bringing people on to your team?

People who are smart, passionate, and get things done.

Q: How much programming knowledge do you think someone managing a software project has to have?

The smaller the team the more knowledge they need. But I think that to be a truly great software project manager you need to have a passion for software. You have to care about the thing that you’re building and relate to the people who are building it. People with a passion for software will naturally have some knowledge of programming.

I think of asking what programming languages a person knows as a quick test for actual software passion.

Q: What is your biggest bug bear/gripe/pet peeve?

It drives me crazy when people say they want a different outcome in their projects but they don’t want to change their behaviour.

Q: Indeed. I seem to remember a quote to the effect of “only a fool does the same thing and expects different results”. How do you see software project management evolving into the future?

Software development will become even more distributed than it is today. More of the social aspect of software development projects will begin to surface in our tool set. These social aspects will begin to let us see how people fit into our projects and how the people affect outcomes. Software, in the end, is a human-centric endeavour. Software is built by people, for people. It just happens to run on a machine and that often clouds our perception of what is important in software.

Software project management will have to evolve with that in mind. We, as project managers, will have to embrace the variability and uncertainty that comes from having humans “in the loop”. To help us do that, our tools will improve to enable more natural, healthy communication between all the members of a far-flung team. Projects, not just software projects, are fundamentally social in nature. The old way of viewing projects (particularly in software) as task lists executed by “resources” against a fixed and certain timeline is dead and should be buried.

Embracing uncertainty will revolutionise project management just as quantum mechanics and the embracing of uncertainty revolutionised physics.

Other PM Interviews:


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: