Dear Bob ...This is "Budgeting" with a follow-up question (from "Penetrating the mysteries of IT budgeting," Advice Line, 11/7/2007).All of what you say makes sense – especially in a large organization where duties and responsibilities are separate and clear-cut.We are small, with multiple-hats, and our IS Governance = Administration. Unfortunately, and in keeping with the industry – too often the Project is not Dear Bob …This is “Budgeting” with a follow-up question (from “Penetrating the mysteries of IT budgeting,” Advice Line, 11/7/2007).All of what you say makes sense – especially in a large organization where duties and responsibilities are separate and clear-cut. We are small, with multiple-hats, and our IS Governance = Administration. Unfortunately, and in keeping with the industry – too often the Project is not based on business case –but “Dr. Squeaky Wheel.”We have done most, if not all, of what you suggest – formally and informally. I guess I was hoping for a magic way to quantify; a “number” that says, “see – we have a Project Complexity score of 4.29 so we have justified the need for 1.5 Analysts and .5 Help desk staff …”Have any magic? – (Still) BudgetingDear Budgeting …Ah … you’re looking for Function Point Analysis. Not for the faint of heart. I can’t endorse it myself – every time I get close to it I find myself wondering, “Would the end-users recognize a function point when it comes up on the screen?” I know practitioners who claim it allows them to estimate projects with high levels of precision.My personal opinion: The best way to estimate projects is to break them into small chunks with go/no-go gates in between. That allows you to avoid estimating how long it will take to build a system before you’ve decided what has to go into it.The waterfall version looks like this: 1. High and mid-level business process redesign that includes the role the system plays in the new process (this substitutes for “Requirements”) and is more valuable. One of the deliverables is the Statement of Work and estimate for the next phase, which is …2. Either product selection (if you’re going to buy and integrate) or system specifications, along with a more detailed business process design. One of the deliverables is the Statement of Work and estimate for the next phase, which is …3. Either construction or installation and integration. This very well might be a multi-phased effort depending on the scope of the redesign. One of the deliverables is the Statement of Work and estimate for the roll-out phase. An alternative, which I increasingly like as I grow older and less energetic, is to assign one programmer/analyst to a business change effort. The P/A sits with the end-users, learns their job, helps them think about the next logical and easy-to-implement process improvement, and makes whatever system changes are necessary to make it possible. Then they do the next one.It’s business improvement through the removal of small annoyances. It can be surprisingly effective, and makes resource planning easy. What it doesn’t let you do easily is predict when you’ll reach the point of diminishing returns on the improvement effort so you can redeploy your P/A to the next one.– Bob Powered by ScribeFire. Technology Industry