A Little Homework Goes a Long Way in Project Prioritization


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:

  • Business Need: I've seen many projects go through the pipe (and probably bear some blame for a bunch of them) just because they are "neat." Neat is not a business need, nor is the idea that something can be described as "Web 2.0," "viral," or "something edge." If you can't describe what about your business needs to be improved or expanded by the project, you don't need the project.
  • Key Assumptions: Early-stage conversations about any initiative are full of assumptions. You need to recognize them, and then -- as this form requires -- identify the associated risks should those assumptions not pan out.
  • High-level Functionality: If you or your team is proposing a project, you need to know kinda-sorta how you want it to work. This description doesn't need to rise to the level of even a formal business requirement-that comes later in our process-but you do need to have a notion of how the tool or feature you are proposing will work before you bring it to a companywide prioritization discussion. If your business is organized so that the folks who come up with functionality ideas work in another team than the folks who define business need, then I assume you have a process in place to create a functional snapshot before the project reaches the stage of competing with other initiatives for premium IT resources. If these high-level functional snapshots take the form of formal business requirements, then I am very jealous of the success your company is enjoying that affords you that much overhead.


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.