6 Steps to Defining IT Project Requirements

6 Steps to Defining IT Project Requirements
By Kathlika Thomas

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!

Kathlika Thomas has over a decade of business analysis and project management experience. She has roots at Accenture, one of the “Big Five” consulting firm and has managed numerous international projects. Kathlika has also developed a number of workshops and training programs related to business analysis, business intelligence and project management. You can read more from Kathlika at the IT Project Blog.

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

3 Responses

  1. Avatar Senthil says:

    Hi,

    How do you see if different teams are involved in getting requirements from end users, in case if project teams are spread at different global site with different timings? What would be the ideal way of working?

  2. Avatar Joe MacNish says:

    There are 2 steps missing from your list.

    1. Define Project Value : What is the value of the project to the organization in achieving its goals? Identify, specifically, what impact the success of this project will have in helping the organization realize its mission.

    2. Identify Issues and Risks : “Fortune favors the prepared mind” after all. Identify the risks and potential issues facing the project, and quantify both their probability and estimated cost. More importantly, develop response plans so that the team can respond quickly and effectively if a problem is realized.

  3. Avatar cbs says:

    Interesting article but I wonder whether it misses some context? I agree that requirements are important to project success however, if I understand this article correctly I have to disagree with the basic premise of it, which seems to me to be that ALL requirements must be known, understood and defined before we start the project. From my own experience as an IT PM this is a perfect world scenario that seldom if ever exists in the field. In IT we need to be much more adaptive on requirements and change – a prescriptive, follow these steps to success, process like you have outlined just does not happen in the IT project world. My basic problem with the outline is that if you followed this “waterfall” of steps it is highly likely the project would never start!! In IT, user requirements evolve over time as often the user doesn’t really know what it is exactly they want and after seeing “working” functionality they often change their minds. I definitely disagree with your contention that “All team members must fully understand all requirements before moving forward”, this is not necessary and as stated above largely not possible – unless you have unlimited time and money. I would also not derive the schedule from requirements but would instead use iterative and incremental practices and time-box the iterations and deliver “features” that add value to the client – which may not necessarily meet the entire requirement but may be an incremental step towards meeting it.

Leave a Reply