A Little Homework Goes a Long Way in Project Prioritization

Ken-Hardin

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.



Add Comment      Leave a comment on this blog post
Apr 13, 2009 4:04 AM Som Gollakota Som Gollakota  says:

Hello Ken, Thanks for the write up and the template. You are spot on about doing some homework before initiating a project. Especially in current economic times, your editorial could not have been better timed.

I have used/reviewed similar project proposals (Project Concept Summary Documents etc) in the past. Some of the companies I worked for in the past mandated such a document for funding a project, and the IT PMOs mandated for project intake.

It is probably a discipline (or culture) thing among the business owners who fill this document out, because, I have seen funded projects falling apart mid-cycle (or worse, end of cycle) because they don't make any business sense. It is such a waste of money.

I have seen two variations of such Project Proposal documents-one, at the end of concept phase, outlining the business need, and justifying a relatively 'small' amount of money (sometimes, as high as $0.25 M or higher) to detail out business requirements and build a solid business case (call it Inception). Projects fall apart at the end of Inception because the business owners could not come up with a good enough business case to secure funds and execute the rest of the project (in essence, the Inception money just went down the drain).

Often times, a level-1/level-2 business manager, who is building the proposal for a senior manager/director/VP of their org, is either 'following orders' or trying to be on the good side of their VP.

Personally, as an IT Project Manager, I prefer that my business owners think hard and answer the question 'Does this really make business sense?' and get to facts and figures (Homework) in their project proposal or the business case. This will not only help organizations put their money where their business is, but also help IT managers such as myself to execute the projects knowing they are adding business value. In any economic situations, a penny saved would add to our spending-power on the opportunity pool, and aid in improving business and returns on investment.

Reply
May 13, 2009 4:36 AM jdrek jdrek  says: in response to Som Gollakota

this is helpful

Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.