Archive of Project Management Articles

Is your product successful because you were lucky, or because you were methodical and intentional?

Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide 3 of your presentation to a venture capitalist should not say “And then we get lucky!”

We’re dedicating our “blogging time” this week to doing some infrastructure upgrades - we have to address some security issues on the site. Until we get through these changes, we’ll be recycling some of our existing content. For our recent readers, it will be “new to you” and for our long time readers, we appreciate your patience. Today we look at one of our most popular articles - on using Timeboxes to manage your project plan.

Bill Miller, who writes You Want it When?, a blog focused on improving the way you manage software development and I had a debate over email about outsourcing. We looked at pro’s and con’s, and our discussion centered around the best outsourcing model, and what the ramifications of outsourcing really are. Read on to see the back-and-forth.

We create cost estimates at many times in a project. From budgetary estimates at the start of a project all the way to PERT estimates of tasks in a work breakdown structure. Creating a budgetary estimate seems impossible - you have to make many assumptions, your estimates are based on the unknown - they can’t be good. There are ways to make budgetary estimates easier to generate and refine - but they can create a sense of false precision.

You’ve written a project plan. Your team is ready to start. Here’s the bad news - you’re going to fail. But why? How can you avoid failure?

What can you learn about your agile project from this Gannt chart? The one above looks out two years. It shows task dependencies and concurrencies. If you’re iteratively developing software, do you really expect to know what you’ll be doing two years from now, to know if you truly have a dependency? You may understand the dependencies with a two-month time horizon. But how much effort are you investing in creating a detailed, two-month Gannt chart? And how much value are you getting from it?

Why don’t more companies and teams use agile development techniques? We know some teams just aren’t aware of them - although that list is getting shorter every year. The benefits of iterative development over waterfall development are pretty well established. I don’t believe I’ve seen a study that shows that waterfall is more effective. Do people refuse to believe in the data? Or maybe they are unable to believe.

Your project is almost finished. Last week, it was almost finished. And you suspect that next week, it will still be almost finished. Why does this happen, and what can you do about it? In some ways, we’ve known about this problem for almost 2500 years But the solutions are still far from widespread.

We all know the story about the emperor’s new clothes. I’ve been thinking about prioritization and scheduling, and as far as I know, no one is promoting that we maximize value - they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest. In this article, we show why not.

You expect analysis to happen before design, and both to happen before implementation and testing. But how much should these activities be staggered? When a project is being run with monthly releases, it might seem logical to have each group working on a different release. For example, the test team working on the current release (3), the developers on the next release (4), and architects and analysts working on releases 5 and 6 respectively.

If your team is this staggered, you have a problem. It takes four months for a requirement to be released from the time the analyst has documented it.