One of the dirty little secrets of most development projects, particularly in smaller businesses, is that they often get pushed into the IT pipeline before anybody does any real homework to see if they make sense.
Sure, an idea may sound like a no-brainer when you discuss it at the senior managers meeting, but there's a facility to filling out a little paperwork to justify a tech project, even if it is going to run only a few thousand bucks in direct development expense. After all, you could always have spent that money on something else that made even better sense, when put to a little scrutiny.
I know there's not an analyst or consultant out there who would not say "Well, duh" to this assertion. But they will also tell you-and I can share similar painful stories with you, I swear-that the basic step of a simple project justification often just gets skipped in the hurry of "just getting it done." Particularly in small shops.
In the wake-some of us, in a moment of candor, might say "aftermath"-of our own major site redesign project, we at IT Business Edge are refining our project-management process. The first step is, as you'd expect, bringing the idea for a project before a cross-company committee for prioritization. We've done this since day one, of course, but we are making the process a little more structured.
The catch is that before you can truly prioritize a business initiative, you have to know the cost. And for a dev project, costs estimates-at least credible cost estimates-are in themselves expensive, given that they need to be done by high-value employees or contractors.
Our answer-in-progress is a simple proposal form that I just uploaded to our Knowledge Network. The form, developed primarily by project manager Andrea Receveur, requires someone to identify themselves as the "business driver" for the project-this person can be either from inside or outside IT-and provide key scratchpad projections for the initiative.
Among these data points:
The little form I uploaded, and our overall process, is for smaller shops or companies that have a need/desire to pursue a more rapid approach to development-without shooting themselves in the foot along the way.
My own contribution to this form is the sections for Success Metrics and Operational Considerations. If you are going to propose a project, you have to give the folks considering it-many of whom may not have the clearest view of how your line of the business works-an idea of what the thing will produce if it works as you expect. And you'd be surprised how many projects get approved without at least some consideration of what the end deliverable will cost to operate as a business tool.
I filled this out yesterday for a site improvement we've been kicking around in discussion for a few weeks. It took me about an hour, and that was with mining a few data points from Google Analytics (you get what you pay for) and conferring with the manager who will be stuck running the feature if it is launched. So, it's not a huge resource drain.
I cannot stress enough, however, that this form is not meant to replace a formal business case for very large projects. It's only three pages long, after all. Its role is to force your business take a couple of breaths before rushing into relatively manageable projects in the name of "time to market" or "revenue at risk" or other catchphrases that pass for excuses for making easily avoidable mistakes.