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.
Before you can truly prioritize a business initiative, you have to know the cost. And for a dev project, cost estimates – at least credible cost estimates – are in themselves expensive, given that they need to be done by high-value employees or contractors.
One answer-in-progress is a simple proposal form that can be found in the Knowledge Network. The three-page template covers the basics of top-level project justification. For larger projects, it should be accompanied or followed by more intensive financial projections, but for smaller projects, these key points will prepare a prioritization committee or group of managers to green-light a proposed project for formal business requirements and functional specs.
Click through for key points that will prepare a prioritization committee or group of managers to green-light a proposed project for formal business requirements and functional specs.
Unfortunately, many projects go through the pipejust because they are ‘neat.’ Neat is not a business need, nor is the idea thatsomething can be described as ‘Web 2.0,’ ‘viral,’ or ‘something edge.’ If youcan’t describe what about your business needs tobe improved or expanded by the project, you don’t need the project.
Before proposing a project,you need to know kinda-sorta how you want it to work. This description doesn’tneed to rise to the level of even a formal business requirement-that comeslater in the process-but you do need to have a notion of how the tool orfeature you are proposing will work before you bring it to a companywideprioritization discussion.
If you are going to propose a project, you have togive the folks considering it-many of whom may not have the clearest view ofhow your line of the business works-an idea of what the post-launch success metrics andoperation costs will entail.
Early-stage conversations about any initiativeare full of assumptions. You need to recognize them, and then identify the associatedrisks should those assumptions not pan out.
Get project sign-off by project sponsors and key senior managers.
