Why a Big Budget Will Kill Your Software Project

Money, get away.

Get a good job with good pay and you’re okay.

Money, its a gas.

Grab that cash with both hands and make a stash.

New car, caviar, four star daydream, Think I’ll buy me a football team.

Everyone, sing it with me:

New box, database, VP daydream, Think I’ll buy me an IT team.

Money

In Making of a Web App I said that new software projects should simplify scope for increased likelyhood of success, greater end-user satisfaction, and key stakeholders who get what they need instead of a version diluted by dozens of others’ desires.

Yet, on large projects with dozens of stakeholders – such as is common on corporate IT efforts – it’s impossible to effectively reduce and simplify. There are decades of project management best practices and strategies for helping large, complex projects succeed. This post is a warning to those new to the industry and new to corporate IT efforts: don’t try reduce and simplify at your office. It won’t work. And here’s why.

Follow the Money

It all starts with the money. Everyone wants to have big budget projects, because:

  • They never know what the next budget cycle looks like, so will go after what they can now.
  • “Use it or lose it.”
  • Empire builders.
  • Large budget must = “Important project that cannot be cut”.

More Money = More Stakeholders = No Way to Simplify

Then, when project get the big budget and the staff they desired; the scope grows, more people latch onto the effort and it becomes impossible to say “no – we’re keeping it simple”. Projects are then left trying to make everyone happy. And you know that those that try to make everyone happy usually end up making no one happy. That’s just the nature of life.

The Alternative

Happily take the small budget, quick-win projects and build a raving fan-base of people that love what you do and actually like the software you deliver.

Lower budgets equal lower profiles. A low profile is not good for advancement-by-politics, but can mean less people looking over your shoulder which means more freedom to focus on the people using the systems you build. Without everyone in the company jumping on your gravy train, you can focus on the business needs of one or two key stakeholders and can quickly gain happy users that have come to expect corporate IT projects to take a long time, cost a lot of money, and only partially represent their real business needs.

Your newly estatic community of people that use your software will do what it takes to keep you and your team around through good times and bad. You will have an advocate outside of the IT department. And in corporate politics, any cross-departmental advocate is a good thing to have.

To those with grand plans of enterprise domination, let me ask that you think carefully before jumping into those choppy seas because maybe, just maybe the small, focussed projects are the place to be.

Sing It Brother!

New start, raving fans, it’s my daydream, Think I’ll like my new small team….it’s a gas…