       |
||||||||||||||||||||||||||||||
Back to Basics |
||||||||||||||||||||||||||||||
|
Home > Articles >
When I first started managing projects, I treated requirements as an input to the project--they would magically appear and tell me what the scope of my project was. It didn’t take me long to figure out that I was taking the wrong approach, that requirements gathering was actually an integral part in the execution of the project. But I am still surprised by how many organizations are unable to come up with good requirements.
In this article, I want to go back to requirements basics and examine how the requirements tie the organizational needs into the deliverables of the project--and how we then go on to validate those requirements.
From needs to deliverables--via requirements All projects begin with a need, or maybe more accurately a set of needs--things that the organization is looking to change. The reason may be competitive, operational, financial, regulatory or any number of things, but we always start with a basic need. Please login/register to read the entire article.
sponsored announcements and special offers
Learn how IT can better guide its strategic investments and operational resource allocation throughout the service lifecycle. With Service Portfolio Management, IT investments and resources are translated into things the business cares about – services. Download the white paper Service Portfolio Management: Manage IT For Business Value.
Don't re-invent the wheel! Why divert resources to developing business intelligence and analytics functionality when partnering results in improved productivity and more innovation? Check out this IDC white paper from SAP to see why partnering with an established BI vendor presents a compelling economic case.
Register Today and Save 15%!
|
 sponsors
vendor offers
vendor events
| ||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||
