Way back when I was a developer, my professors taught me structured design and design by contract. Those were supposed to be the silver bullets for programming. You see, if you specified things enough, and structured things enough, everything would all work out. I thought I was the only idiot that structure and specification didn’t […]
Do you have projects where you can’t predict an end date? These tend to be a job search, a change project, and with a tip of the hat to Cesar Abeid, your life. I like to call these “emergent” projects. You might prefer to call them “adaptable” projects, but to me, every project has to
This post is continued from Cost, Value & Investment: How Much Will This Project Cost, Part 1 We’ve established that you need to know how much this project will cost. I’m assuming you have more than a small project. If you have to estimate a project, please read the series starting at Estimating the Unknown:
I’ve said before that you cannot use capacity planning for the project portfolio. I also said that managers often want to know how much the project will cost. Why? Because businesses have to manage costs. No one can have runaway projects. That is fair. If you use an agile or incremental approach to your projects,
I was thinking about the Glen Alleman’s post, All Things Project Are Probabilistic. In it, he says, Management is Prediction as a inference from Deming. When I read this quote, If you can’t describe what you are doing as a process, you don’t know what you’re doing. –Deming I infer from Deming that managers must
I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what
My manager reviewed the org chart along with the budget. “I need to cut the budget. Which resources can we cut?” “Well, I don’t think we can cut software licenses,” I was reviewing my copy of the budget. “I don’t understand this overhead item here,” I pointed to a particular line item. “No,” he said.
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
I sent a Pragmatic Manager email last week, How to Avoid Three Big Estimation Traps. If you subscribed, you’d have seen it already. (That was a not-so-subtle hint to subscribe 🙂 If you’re not sure of the value of being on yet-another-email list, browse the back issues. You can see I’m consistent. Not about the
If you’ve been paying attention to agile at all, you’ve heard these terms: pairing and swarming. But what do they mean? What’s the difference? When you pair, two people work together to finish a piece of work. Traditionally, two developers paired. The “driver” wrote the piece of work. The other person, the “navigator,” observed the