Getting some process going

Dear Bob …

We work with a software vendor whose app we host. They are small (20-ish employees), we have to cover a lot of customers and pretty close to 24/7. We are, unfortunately, their largest install, certainly larger than they designed for.

There have been scaling problems.

My problem is in figuring out how to get us past the “cowboy” software support process. When I started in IT in the early 90’s I worked for ATT in New Jersey so I found all about software quality Bell Labs style. And worked in electronics before that and got the Deming et al background. I even was a Fagan Inspection facilitator. We counted function points.

Years later I find myself in a different universe. There’s been lots of growth, and more potential but we have very little common understanding of the need for configuration management or a rigorous testing/promotion process. We have a test environment but it’s often bypassed with my management going straight to the vendor, changes going straight to production.

CMM level 0.5 all around. Maybe -1.

Managers have been around at large orgs and pay lip service to the process thing, and we have made improvements, but we also suffer from the pride of “let’s put on the show right here in the barn!” thinking -– we’re small, unconventional and smarter than the rest, yessir.

And even when we have made a stride or two in the quality direction, each personnel change on our side or the vendor side results in the whole thing falling down and going backwards, because it really wasn’t a core process change.

So where do I look for tips on how to get us all on the software process cluetrain?

Your article “A scandal unveiled,” (Keep the Joint Running, 9/15/2003) was right up the same alley, but pointing in the opposite direction –- about enterprise apps that don’t downscale. Well, we need the other thing –- upscale the brains to the support the enterprise approach, because we are already in the enterprise world.

My web searches only find the enterprise stuff -– ITIL, CMM, Six Sigma and all. Those are overwhelmingly complex and I get glassy eyed looks mentioning anything like that to my compatriots.

So are there any “software process improvement for SMB dummies” kind of programs I can latch on to?

– In Chaos

Dear In Chaos …

Sounds to me like you do have a scaling-down challenge. You need software quality assurance and change control, only you need the “lite” versions.

They’ll be far better than nothing at all, and as much as your company culture will allow. Let them gel, and remember, once you get on the process train, it’s hard to stop before you arrive at bureaucracy station. I can understand your managers’ allergies to the bulky ways of doing things they escaped from. I’ve escaped from them myself, and am glad of it.

I’ve also lived through the We’re-Smarter-Than-Everyone-Else mentality enough times to know what it leads to … usually, being dumber than everyone else. People who are really smarter than everyone else get that way by first learning what everyone else knows. Then they figure out what to do differently.

Assuming you’re in a position to influence things, I see two basic strategies for getting the ball rolling, depending on the specifics of the social situation.

In the first, you and a compatible soul with equivalent influence in the software vendor work together to develop the plan. In the second, you and your manager put it together. It depends on which you think will be more effective.

The plan itself is pretty basic. It’s a presentation that starts with two questions: (1) What risks aren’t we willing to take? And (2) What risks are we willing to take?

The risks you aren’t willing to take are:

• Intrusions.

• Installations that seriously degrade system performance or knock it down entirely.

• Becoming a stultifying bureaucracy.

The risks you are willing to take are:

• Software defects that result in unexpected application behavior (non-critical bugs).

• Features that end-users don’t find as appealing as you expected.

Next slide: “This isn’t just theory,” listing catastrophes and near-catastrophes that everyone in attendance knows about.

Your next slide is titled, “Procedures we need to enforce to prevent the risks we aren’t willing to take.” List them.

Your voice over is that you no longer have a choice about instituting and enforcing these procedures. You do have a choice about how lean or bulky you make them.

Present to the key decision-makers … one-on-one first, to get buy-in, then in a group setting to demonstrate consensus. Plan the sequence of presentation carefully, too. You don’t want to offend key decision-makers by leaving them to last. You also don’t want to waste their time by meeting with them too early, before you’ve perfected the pitch.

This is just a sketch, of course. It should get you pointed in the right direction.

And don’t become discouraged if nobody buys what you’re selling. Chances are they won’t, until there’s a life-threatening experience.

Facts and logic by themselves are rarely persuasive, especially in companies that are making money.

– Bob