Your taxes are due.

It’s that time of year again — time to reflect that many business executives have the same attitude about IT that the Tea Party has about the federal government: They “know” they spend too much for it and aren’t at all clear what they’re getting for their money.

Which has little to do with this week’s pair of IT critical success factors, but a lot to do with IT CSFs #1 & 2. The relationship matters more than anything else.

This week’s factors can certainly influence the quality of the business/IT relationship, though, because they’re all about IT’s credibility, which lives and dies on how well it delivers the goods.

“The goods,” of course are applications that (1) do what the business needs, (2) don’t cost too much, and (3) show up on time.

Above and beyond everything else required to deliver the goods are a company-wide project management culture, and a well-practiced systems development lifecycle.

Project management culture

Project management is a pain in the corporate keister. In a construction project the project manager doesn’t draw the blueprints, pour the concrete, or weld the girders. In a software project the project manager doesn’t design the software, write the code, or test the results. Project management is overhead.

It’s annoying, too. Most people, most of the time, put planning right next to dental work, at the top of their lists of things they seriously don’t want to do. But project managers insist on it anyway, and even worse have the bad taste to do it in public: They insist other people review and approve their plans. Is this how their mothers raised them?

We aren’t done. Not only is project management annoying, but project managers are annoying. Most people, most of the time, follow the MT methodology, which stands for “muddling through.” Project managers, though, can’t accept muddling through because they need to coordinate the actions of multiple muddlers.

So on top of everything else, they nag.

Net net: There’s nothing about project management that’s naturally likable. And yet, even the best project managers can’t succeed unless everyone whose activities they have to coordinate let them. This means that, just as was the case last week when the subject was process, project management can’t succeed unless the whole company, inside and outside IT, has a culture of project management.

Unless, that is, all those annoying things that have to happen for projects to finish on time, within their original budget, with all deliverables intact … and, by the way, resulting in the intended business change happening like it was supposed to … where was I? Oh, yeah, that’s right. Unless everything about project management is How We Do Things Around Here.

Is this important? Yes. Were we to construct a list of general-purpose corporate critical success factors, there’s little doubt that excellence in project management would make the list, and would probably have a high position on it. That’s because projects are how change happens in an organization, and if there’s ever been a tired cliché more true than “the only constant is change,” I don’t know what it is.

Well-practiced SDLC

There is, as you’re thoroughly tired of reading by now, no such thing as an IT project . There are, though, lots and lots of projects that include a need for information technology. IT is rarely if ever sufficient, but it’s usually quite necessary.

Which means IT needs to be very good at designing, developing, testing, and rolling out new applications. Or (or and) it needs to be very good at selecting, configuring, and integrating commercial, off-the-shelf (COTS) solutions.

SDLC stands for “systems development lifecycle.” The phrase is ingrained, so I’m gritting my teeth and using it here, even though most IT organizations implement COTS solutions more often than they develop from scratch.

IT needs to be good at this, and the only way to get good at anything is to practice it.

Yes, there’s lots of controversy over whether SDLCs should be waterfall or Agile. And within the Agile community there’s lots of controversy over whether it should be Kanban, Scrum, eXtreme, or conference room pilot. (Actually, CRP rarely generates controversy because even though it ought to be the most-widely used Agile variant, very few people have even heard of it).

But in the end, which SDLC you choose matters less than sticking with it and getting good at it. If the point isn’t clear, turn it around: How good can anyone be at anything if they only do each thing once, for the first time?