We at IT Business Edge are kicking off a review process of the development efforts that resulted in our new site design and re-launch.

The first step – and I think a fairly prudent one – in the process is for all the stakeholders, both technical and non-technical, to submit a list of 10 processes that we think could be improved to spare us some pain next time around (which I, for one, hope is some space of time from now).

Of course, my perspective is skewed, given that I get paid to hassle IT about dev projects, among other things. But tops on my list is the need for business sponsors to be more intimately involved in the dev process, particularly since as a small company we have to pursue what used to be fashionably called “extreme” development.

First off, let me say that being intimately involved in the dev process is often not as much fun as it sounds. Parsing functional specs line-by-line is a pain, particularly if your stock in trade is selling advertising or writing clumsy blog posts.

But seemingly minute details – like the difference between a “tag” and a “node” – can make a big difference in the final deliverable in a development project. It’s unrealistic for a line-of-business manager to assume that they know enough about technology to debate the virtues of Oracle v. MS SQL Server – although I’ve seen it happen before to somewhat laughable effect – but business people can, in a pinch, understand and add value to a functional spec.

Large enterprises have entire divisions of product managers and junior analysts devoted to this task, but in many smaller shops this vital – in my opinion – stakeholder relationship just sort of drifts off into the ether. After all, we have ads to sell and clumsy blog posts to write. Again, it’s a pain, and one the company has to recognize up front and allocate resource to, even if it’s on the basis of a temporary assignment. This type of engagement does not just filter into a dev process organically.

Of course, some projects just fall into the category of maintenance and T&M. But for sizable projects, there are three fundamental points of engagement that I think must be required from business drivers:

They should write a fairly detailed Business Requirements document: Not database schemas here, but a detailed description of the functionality, along with a glimpse of the business rationale for the project in the first place, should be included. The business value of a sizable project should have its own justification process, of course, but it’s good to let the dev team in on what you hope to accomplish with this thing when it’s finished. Here’s a hint – if it is at all possible to draw a picture of something, be it a business process or a UI screen – draw it, or find somebody who works for you that can.

They should have a formal sign-off on the Functional Spec: After IT converts the Business Requirements into a functional spec – and that’s really a task best left to a trained Project Manager – business drivers must get in there and read every little line, and then read them again. When you are completely satisfied, sign it – and expect some well-earned grumbling if you have to come back for a change request later.

They should alpha test the deliverable: Since business owners have an intimate knowledge of how the project is supposed to work, they are more than qualified to be an extra set of eyes on the first reasonably stable deliverable, before a less engaged group of testers get hold of the thing in a beta rollout.

I’ll keep posting notes about our progress in polishing our own processes as we move ahead.