adoption curve dot net

I’m not going to waste too many electrons in expounding what a deranged and fundamentally bad idea the European Directive on Computer Implemented Inventions (aka European software patents) is – there are many, many people who can explain that far better (here’s a few:

• Free Software Foundation
• No Software Patents.com
• Foundation for a Free Information Infrastructure
• Petition for a Software Patent Free Europe

And I’m not going to waste too many electrons on the travesty of the democratic process that has taken place, with a Commissioner in the pocket of the corporate software cartel ramming through a piece of legislation that has been comprehensively rejected numerous times.

The bottom line is that it’s happened, and there’s one last chance to do something about it. For the directive to be kicked into touch it needs to be rejected by a majority of MEPs in the European Parliament – 347 of them, to be precise. So now is the time to start lobbying your MEPs to prevent this happening.

If it does, then open-source software as we know it will be lawyergrammed out of existence. Software will exist only by permission of Microsoft and Cisco and Nokia – anyone seeking to challenge the behemoths will simply be stamped out though the abuse of the patent process.

So write, call, email and fax. If the Directive passes, it’s because the corporations wanted it to happen – not because there’s any kind of a democratic mandate for it. This sets the direction for the kind of society that we want to live in – on the one hand, beholden to the best interests of the shareholders of a few giant (and largely American) corporate cartels; or on the other a society that balances the interests of society as a whole against those of the corporations.

It’s our choice.

If you want to start a fight (or at least a heated argument) amongst a group of project managers, the best way is to gather them at a bar and utter the statement “I think methodology X sucks / blows chunks / is the greatest development in the field of project management since the invention of the Gantt chart (delete as applicable)“.

Then stand back to admire the chaos you’ve just caused.

There’s a similar debate (albeit much more civilised than a bar brawl) going on in the Ecademy Project Management Community forums at the moment – there are advocates and detractors of Prince, those that see methodologies as fundamentally flawed, and every shade of opinion in between.

The discussions got me thinking. The fundamental problem with methodologies is that they’re not always applicable all the time. And the decision process about which parts of which methodology to use at which time is pretty much intangible – it’s something that comes with experience rather than training.

The temptation when you’re an inexperienced project manager – or an experienced one operating beyond your comfort zone – is to use a methodology like a cross between a crutch and a security blanket. If outcomes are looking dodgy, a methodology can be a great process to lean on. And if you’re made uncomfortable by the environment or the stakeholders, you can bury yourself in the familiar rituals of the process to block out the nasty, uncertain world outside.

And if you’re not a project manager, then the temptation to put misplaced faith in a methodology is even greater. It’s a part of the human condition to crave certainty, so if a methodology is presented to you as a sure-fire way of guaranteeing an outcome – and you’re blinded by the flashing lights and jargon – it’s understandable if you put your faith in it.

That’s not to say that methodologies are fundamentally flawed, just that they’re a tool. As the old saying goes, if all you’ve got is a hammer, every problem looks like a nail. Now if only there was a methodology for working out which parts of the methodology to use…

No sooner had I posted about the obsession that some recruiters have with budget size, then the phone rang again with a similar question. And over at Projectified (which comes with a great strapline), Brian Kennemer commented on the post, pointing out:

But I have to say that I think this theory breaks down to some degree. I think that big, high stakes projects carry with them different kinds of pressure than small ones. Also in many cases large budget often equates to large scope.

I think that last point is actually the key to my argument – a budget is actually just one proxy measure to the business scale of the project. The larger the budget, the larger the scope and the larger the impact. But absolute measures of budget are meaningless unless you’ve got the context in which to put the figures – going back to the example I cited, the budget amounted to 10% of their annual turnover, and their entire reserves. Screwing that up by going 10% over-budget would have resulted in holing them below the waterline. If I’d screwed up the biggest project I’ve managed to date – well, missing the numbers by 10% would have resulted in some penalty clauses being invoked and some harsh words exchanged, but ultimately the organisation would have survived.

Which was the “best” project? From a personal perspective, the smaller one – there was no place to hide, so the satisfaction of bringing it in on time, on budget was all the greater. Which was the most glamorous? The biggest one, naturally.

What recruiters should be asking is “which project did you learn the most from, and what did you learn?” But that’s not a question you’ll be asked often until you’re talking to a recruiting manager rather than an intermediary.