IT Project Help

Ask us about our enterprise IT services! Just give a short description of your next project, and we'll see what we can do to help.
 

IT Project Blog Extras

About the Author

IT Project Blog

Kathlika Thomas Fontes, head writer of the IT Project Blog, has over a decade of business analysis and PM experience. She has managed numerous international projects and has also developed several workshops and training programs.

IT Project Blog

Current Articles | RSS Feed RSS Feed

6 Steps to Defining IT Project Requirements

  
  
  

GUEST ARTICLE--This article was written by one of NuWave's IT consultants for the IT Project Blog.


IT Project Requirements

We all know that defining IT project requirements is a crucial task when initiating new projects. But did you know that Standish Group’s CHAOS Report shows that a clear statement of requirements is one of the TOP THREE reasons for project success? Since it is clear that defining requirements is one of the top PM best practices, we have compiled a series of steps that every project team should follow in order to get on the track to success.


  1. Business and Functional Requirements. The first step is for the IT project team and end users to define and document all of the business and functional requirements of the project. This process begins with a requirements document. This document details all business and functional requirements of the project. It details the "what" of the project.
  2. Design Requirements. Next, the team and users define the design requirements and add them to the requirements document. The design requirements describe "how" to build the solution(s). All team members must fully understand all requirements before moving forward.
  3. Project Phases. The next step is to outline the phases of the project based on the requirements. The end of each phase should have measurable deliverables so that it will be clear when a phase has been completed.
  4. Project Schedule. The team then creates a project schedule from the determined phases. This should be approved before continuing.
  5. Test Plans. Another PM best practice is to write and execute test plans during each project phase completion. Each requirement is listed in the test plan and cross referenced with its associated test to assure that every requirement is tested for success.
  6. Completion. The project is deemed complete and successful when execution of the corresponding test plan validates that the project has met each documented requirement. Of course, in order to be deemed successful, the project must also be completed within the budgeted time and cost.

This procedure puts the users of the solution and the team creating that solution on the same page throughout the project, leading to a greater success rate. Both sides understand and feel ownership of each documented requirement because they were both involved in defining requirements. As project phases are completed, project testing validates that all IT project requirements are met, and therefore the end product meets the overarching goals set in the very beginning. Please share your experiences with defining and following project requirements!

Comments

Great article! I use a very similar procedure when managing projects. I can't tell you what a difference it makes in the end result to have well-defined requirements and a systematic approach to completing and testing each phase. Well done!
Posted @ Thursday, May 13, 2010 10:20 AM by Gary
Agreed! I love point #5... a traceability matrix is your friend. Great way to map test cases and results back to original requirements to make sure that no scope items are missed. Thanks!
Posted @ Thursday, May 13, 2010 10:30 AM by Kathlika Thomas
This is a great idea to put ideas out there, and encourage discussion. My points in addition to the good bullets above would be to designate the "whos" and their backups as needed.  
 
 
 
And while project management doesn't specifically try to drive sales, they are in fact in an excellent place to do so. They see when internal client systems break down, whether it is communication channels, actual technology failings by vendors, or just regular unmet challenges in the busines with which they are working. 
 
 
 
I was in a position where I worked with PMs, first of being a person who followed project plans, to the place where I led technical teams following project plans, up to where I sold solutions and turned things over to PMs. Since I was in sales, I "selfishly" would talk with the PMs over lunch or a break and ask how things were going, as well as what other challenges did they and the teams see in the client's business. Almost without fail, we always found an opportunity to go after, just because of the awareness of the PMs to actually look for such opps, and encouraging the team they were leading to also look for and report such things. 
 
 
 
I see great things to come with your blog, I intend to be a regular reader.
Posted @ Sunday, May 16, 2010 11:22 AM by james croyle
Thanks for the feedback, James! This was a wonderful article and a very enjoyable read.
Posted @ Sunday, May 16, 2010 12:38 PM by Kathlika Thomas
thèse is the most interesting course 
Posted @ Monday, December 02, 2013 5:14 AM by wondwessen haile
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics