If you’ve been around IT for a few years, you’ve probably developed a list of things you really dislike about the business.
Some of these may be: software salespeople who are paid on commission and disappear immediately after a sale; beta releases of buggy software that you’re expected to build mission critical systems on; the phrase “mission critical”; and non-IT executives – and even some IT execs who should know better – who think every project plan and budget that comes from IT is overstated (“I’m sure you can do it for 25 per cent less and three months faster than this if you really try”) even if they have no idea what they’re talking about.
You might add to that list of dislikes anything that has the suggestion of methodology.
In their defence, most methodologies arise from an honest belief in the need for consistency and comparability in and across IT projects. If all they succeeded in doing was introducing a degree of consistency to our IT practices, that would be a really good start.
As it is, “big” methodologies seem to take on a life of their own, seemingly more important in and of themselves than the results they ostensibly seek to achieve: “We have a great methodology…oh yeah, and the results you can achieve by using it aren’t all that bad either.”
This seeming love of the methodology form over value is often reflected in the documentation: it comes in beautiful, expensive, colour-coordinated binders that look good up on the shelf; they’re hefty, with significant “drop weight.”
“That’ll impress ’em — did you hear the thud that sucker made when I dropped it on their boardroom table?”
To defend yourself against this madness, I suggest you arm yourself first by making inquiries of someone from the vendor who actually works with the methodology every day.
– Make sure it’s scalable. A two-person, three-month, $100,000 project needs discipline and process as much as a one- year, 200-person, $5 million project does – it’s just that they need it in different forms and degrees. If the vendor can’t tell you specifically how it adjusts for project size, heave it out on its ear.
– Same thing for industries. Does the methodology adjust to reflect the industry you’re supporting? As an example, the requirements (specifically tracking and reporting) of defence projects are significantly different than those of other industries.
– Lay down a challenge the next time they’re in your office, and don’t give ’em any warning before they show up. “You’ve got one hour to run me through a real-life project planned with your methodology. Start now, and I’d prefer that you didn’t look at your books. If it’s as straightforward and powerful as you say, you must be intimately familiar with it, right?”
– As always, ask for references, and prepare detailed questions before you call them.
– Ask how the methodology has changed over the last year, and why those changes were made. Any worth their salt better have changed (and improved) in the last 12 months, and your vendor had better to be able to say why and how right off the top of its head.
– Ask how much training you require to be effective with it. If you can’t pick up the fundamentals necessary to get started on a real project inside a week of training, it’s too complex.
– Ask if you have to buy an expensive and/or proprietary piece of software with the methodology to make it work. If it can’t be shown to work without a piece of software underneath it, then it’s probably too married to a prescriptive, rather than a philosophical, approach. Project management, for example, ain’t hamburger – you can’t expect to simply turn the methodology crank and expect a winning result.
As with all IT products, the best consumer is the best prepared and most focused. In the case of methodology purchases, the best buyers never confuse the benefits of process and discipline with the mechanics of a product offering.
Hanley is an IS professional living in Calgary. He can be reached at isguerrilla@hotmail.com.