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
  • Get up and running in as quickly as 30 days with BI. Learn how today.

  • FREE Securing Smartphones & Tablets for Dummies Book from Sophos
  • 5 New Technologies That Will Change Enterprise ITAdvertisement
  • Build an IT Infrastructure That Delivers the Future
     
  •  
    FEATURED SPONSORED ARTICLES

    FEATURED SPONSORED VIDEOS

     



    LATEST STORIES


     

     


    Advertisement
    rss graphic
           Baseline Newsletters