Every IT project should begin with a requirements gathering process to determine the nature and scope of the project. This step is essential to the success of the project. The information discovered and documented here is used to fuel the rest of the development process in a way that allows for the goals of the IT project to be achieved. Unfortunately, this step is often not done thoroughly, or skipped entirely. The major components to the requirements stage are:
Many IT projects do not begin with a project charter, yet it is a critical element of IT project management. The project charter helps keep the project on track with regard to scope and budget.
We have written about the Project Charter on our IT blog. It is a living document created at the beginning of an IT project to identify the business aspects of the project. All project stakeholders should agree to it and the project’s executive sponsor should sign off on it. The project charter develops common knowledge among all project stakeholders. It becomes the “go to” document when scope creep enters in, threatening to derail the project and eat away at budget and resources.
After the project charter is created, it’s time to really dig in. The next step is to define inputs. Inputs are easiest to define, as they are often inherent and obvious, especially if we are converting a series of documents such as Microsoft Excel or Access or another system into a web- and/or mobile-based system through .Net development framework.
The goal for all IT applications is to be uniform, increase efficiency, automate work and capture logical groups of input items for reporting and analytics. Once inputs are gathered, the goal is to find ways to make the data that is entered into the IT system perform better to meet the business goals.
Once inputs are defined, we move on to processes. This step can be more difficult as much of the knowledge about workflow, why data is captured, what is done with it and more resides in the minds of the system we are converting or with the ideas about a new system, if we are building from scratch. Among several key questions we ask at this stage is “What happens?” and then “What happens next?” We often ask this question several times and each time uncover new insights that allow us to develop something that increases efficiency and accuracy, provide business intelligence and is repeatable and scalable.
Outputs uncover needs around reporting, analytics and key performance indicators (KPIs) upfront. Most of the time outputs follow inputs and processes, although occasionally we like to begin with outputs. At this stage, we identify gaps in what is currently being captured and shown and detail what needs to be captured and displayed. A few of the many outputs to explore at this stage are exception reports, KPI reports and dashboard reports, among others.
Throughout the requirements stage (inputs, processes, outputs), user stories can be created to capture how the inputs, processes and outputs work together.We have written about the importance of user stories in helping to deliver IT projects on time and on budget on our blog – please check out that article for more information.
In brief, a user story is a functional description of who is doing what action and what results are expected. User stories are important for developing new functionality, modifying existing functionality and fixing bugs. They keep track of the full suite of functionality to be developed for an IT project. The main goal of user stories is to reduce the risk of having to build functionality twice – essentially, to create a bubble around the project so that functionality can be defined once and built once. In addition to defining actions and results, user stories should include a business value reference.
More on Requirements…
More information can be found on Requirements in our recently released eBook – Discover. Build. Launch. A Playbook for Uplifting an Inefficient System into a Custom Web Application that Meets Your Business Goals – which you can download for free.