Projects: Management - Baseline
Home arrow Projects: Management arrow Managing Projects: The Right Level of Specificity











Renew Your Subscription


Projects: Management



Managing Projects: The Right Level of Specificity

By John McCormick

  Table of Contents:
  1. Managing Projects: The Right Level of Specificity
  2. ' Reference'


Where are projects going wrong?

Rate This Article:
Add This Article To:

Managing Projects: The Right Level of Specificity


( Page 1 of 2 )



For all the fancy new tools, portfolios of best practices and strict testing regimens, delays and failures still plague corporate software development projects.

It's possible that as many as 70% of all projects are significantly delayed or canceled, says Dave Locke, program director for worldwide technical marketing at Rational Software, a unit of IBM.

Among the reasons why projects fail: mismanagement, scope creep and communication breakdowns. Another big problem, according to Locke, is poorly defined software specifications.

Typically, the technology department creates a specifications document based on requirements received from the business side. A software specification meshes what the user wants with what's possible technically and, just as important, feasible financially.

If the specifications are too complex, the project schedule "becomes untenable and may even be longer than the useful life of the system," says Ellen Shepard, chief operating officer at software consultancy Agility Investment Technologies. And the more complex the system, she adds, the harder it will be to maintain and enhance down the road.

But a specification that's not well thought out, says Shepard, "will almost always lead to an unmet user expectation"—a situation that can be fixed only with additional time and money.

Part of the problem stems from the business side providing too much detail—to the point of dictating how to solve a problem rather than simply stating the desired outcome. Conversely, it's still common to find that employees are too busy—or too impatient—to bother with a software project. And, of course, the translation from business goal to technology spec may introduce errors.

According to some, the answer may be a standard procedure for creating specifications. "If companies are using the right methodology, I think it's not an issue at all," says Susan Hutt, a vice president in PeopleSoft's Global Services practice.

To help you get started on solidifying your own process, Baseline has outlined the seven key steps for keeping requirements in check.



 
 
>>> More Projects: Management Articles          >>> More By John McCormick
 


Sponsored Links
  • Free 30-day endpoint security trial: VIPRE Enterprise
  • Reduce operating expenses with CDW Healthcare solutions.
  • Get expert tips & advice on IBM-Oracle database solutions.
  • Get Control with SonicWALL Application Intelligence.
  • Download eval guide and prepare your apps for multicore.
  • FREE Data Leakage for Dummies Book from Sophos
     
  •  
    FEATURED SLIDESHOWS

    FEATURED SPONSORED MESSAGE

    TechDirect

    Find the trusted vendors and products that will meet your needs, compare the top solution and connect vendors in one place.

    Before you order the next, data management, office automation or IT hardware solution visit TechDirect.

    Click Here

      Brought to You By
     

     

     

    LATEST STORIES


     

     



    rss graphic
           Baseline Newsletters