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 giving a talk at Agile 2012, entitled “How Much Will This Project Cost?” It doesn’t seem to matter what life cycle your project has, someone wants you to predict the cost. The problem is, it’s the wrong question. But, that won’t stop people from asking it anyway. People want to know the cost so
I hope that this 3-part series on how to move to continuous integration and how to evaluate if it’s worth moving to continuous integration on your program convinced you moving to continuous integration was worth it for programs. The reason continuous integration is an issue on programs, is because the lack of CI can delay
If you’ve started to use agile approaches to your projects, you’ve reaped the benefits of seeing completed work, reduced work in progress, and making project risks more transparent earlier. But there’s another benefit of moving to delivering work in smaller chunks: incremental funding for projects. Few organizations have embraced the idea of incremental funding. It’s