Xp And Annual Budgets

At many companies, budgeting is done at discreet intervals, typically yearly. For a project to be a considered, a complete proposal must be submitted, with a budget request before a deadline. Selected projects are approved, and staff is allocated to them. If one of these projects is subsequently cancelled, the team members are at liberty and can only be assigned to other projects, many of which are fully staffed. Ideally, cancellation of such projects should make consideration of new projects possible, or increased budget for existing projects. In practice however, that requires approval from many levels of management and the budget is just as likely to be allocated to another division who is not likely to want the freed-up staff. This means that canceling the project places the status of its team members in limbo. The project manager in particular is unlikely to be offered a new project manager position, or will at least have to undergo another very painful budget request process.

-- RussellGold

This happened to me a while back. Technical staff are easier to absorb into existing projects than project leaders. And, since project leaders may be more expensive resources than the general technical population, one between projects one is at extra risk if a cold wind blows (e.g., cashflow problems, or the company "cleaning up its books" prior to an IPO). -- DaveSmith

I took this from IsEarlierCancellationFailure because I've been waiting to this point to be discussed in a sensible way for a while now ... about twelve years in fact.

How does XP work with annual budgeting? -- RichardDrake

Why can't you have ExtremeBudgeting? Well, maybe this only works in a small company.

DoIt has an interesting approach to this problem. In 2000, we are striving to be "fully recovered" - read: zero net impact on our parent organization's budget. In 1999, I estimate we were about 80% recovered. We actually have a fair chance of being slightly over-recovered for the year, which would make us an internal "profit" center. But don't tell anyone! <g>

We operate inside a large corporation, FirstUnionNationalBank. We function as an internal service provider to line-of-business development teams. Sometimes we are selling our development services, sometimes classroom java training, sometimes consulting/mentoring on using object technology, sometimes reselling components, libraries, or applications that we originally built for other projects. Our customers are other First Union development teams. They typically come to us for one of a few reasons:

1. We can do it cheaper and faster than they can

2. They need to get started RIGHT NOW and can't get a team in place fast enough

3. They don't have the required skillset

One of our major competitive advantages is that we have a staff of extremely (pun intended) highly motivated and talented developers who can IMO walk on water. We simply know how to apply advanced technology (which in our case means server-based java components/applications, whether packaged as CORBA or servlets) better, faster, and more reliably than anyone else. And are confident in our ability to add new technologies to our bag of tricks quickly.

The other of our major competitive advantages is that we are able to rapidly react to new opportunities, switch our existing teams around, quickly add new people to staff, and get going (and there done) faster than the line-of-business teams themselves. This is largely because we have 8-week development intervals, small highly collaborative teams, and a short fluid planning horizon.

Because we are not tied to any specific line of business, if one of our customers' projects gets cancelled we get the opportunity to drum up new business elsewhere in the corporation - in effect, to chase the money wherever it goes next. Because we have extremely strong "brand name" recognition within the bank, we have always been able to generate enough business to refill our pipeline when something like this happens. Because we can sometimes "over recover" by reselling existing components, we have so far been able to bridge the funding gaps this introduces. (Where's some wood to knock on?)

It turns out to be a pretty great niche from which to launch XP practices into the corporation. It also turns out to be a much better way to influence the technology and architectures adopted by line-of-business developers than relying on theoretical arguments about PhilosophicalPurity and bureaucratic StandardsEnforcement. -- BillBarnett

Bill, thank you for all three contributions here. You have struck a number of great chords and I'm just resonating (partly reminiscing in fact - I didn't remember I still had some of those old strings!) right now. A tuneful response should emerge in time ... please watch RecentChanges. -- RichardDrake