Do you know your project’s bounds? Do you know what your sponsors want from your project? For many years, I heard about the “iron triangle.” Sometimes, the triangle was “Scope, Quality, Cost.” Sometimes, it was “Scope, Date, Cost.” It was always three things out of a minimum of four possibilities. I never saw a triangle […]
I’ve been thinking a lot about planning recently. Many of my clients want to create long-term plans, based on data with short validity, even for products in a high state of change. I suspect the first question is how much change do you need in your product, not how good your information is, or how
I suggested ways to think about more agile budgeting in part 1. I didn’t tell you why. How do you budget your own money and time? If you’re like me, you have a plan for the year. I evaluate the plan—my products, services, and clients—on a regular basis. I always evaluate monthly. Sometimes, I evaluate
Too often, organizations want to budget for an entire year. The managers run around for two or three months in advance of that fiscal year, attempting to predict a ton of things: Estimates for not-well-defined projects or features, Capital equipment or tool needs, “Headcount” aka, people needed. Then, the organization doesn’t finalize the budget until
I’m working on my roadmapping talk for Agile 2018. I finally had the transforming idea about how to position the talk: Roadmapping and product planning are about feedback loops. The shorter the feedback loop, the faster and more often we can learn. That feedback loop works in at least these ways: The faster we learn,
Do estimates make you slightly crazed? Maybe you want to roll your eyes at the organization’s confusion between your estimate (guess) and a commitment. You’re not alone. I wrote an article about estimation, How to give IT project estimates—and when not to estimate at all. If you’ve ever struggled with estimating work, give it a read.
I had dinner with a colleague. While we were settling into our coffee, he asked me, “What does post-agile mean to you?” I was no longer calm and relaxed. “That’s a nonsense word. Post-agile!” Here’s why I reacted the way I did. We have known about miniature milestones, or inch-pebbles, since the 1940s. That’s how
As I write the program management book, I am struck by how difficult it is to estimate large chunks of work. In Predicting the Unpredictable and Manage It!, I recommend several approaches to estimation, each of which includes showing that there is no one absolute date for a project or a program. What can you do?
I posted my slides for my Agile 2014 talk, Agile Projects, Program & Portfolio Management: No Air Quotes Required on Slideshare. It’s a bootcamp talk, so the majority of the talk is making sure that people understand the basics about projects. Walk before you run. That part. However, you can take projects and “scale” them
Did you see Dwayne Phillips’ post today, Adding People to a Late Project? Dwayne says: Adding people to a late project only makes it later. We have known this for decades. Especially in the article he refers to, it seems as if there might be no end to the number of people added. Did anyone