Requirements Gathering for a Project Management Information System

The requirements gathering process is critical to successfully deploying a Project Management Information System (PMIS). Here are tips on how to gather requirements for a construction project management solution.

The success of any software development project hinges on the requirements gathering process. Would you build your house with no drawings, no material list, or no schedule?  No, of course not.

The same planning is required for a software solution.

Good requirements help enable a successful final product. Poor requirements can result in cost overruns, schedule delays and poor client/contractor relations due to excessive changes and rework.

The right way to gather requirements

Here are a few definitions and best practices to help you better collect and communicate effective requirements from the start:

1.       What is a software requirement?

A software requirement is a detailed definition of a function or feature that must be met to ensure the product achieves what it was designed to accomplish for its users.

2.       Why do I need to do requirements?

Requirements are needed in order to define the scope of the development, provide a cost estimate, and manage the project.

3.       Who does requirements?

It’s not any different than a construction project.  The client has a need. So they develop a design, issues bid packages, manage changes, and ultimately own the overall scope and budget.

The developer doesn’t define the client’s scope.  The developer may help quantify or qualify the scope, but the requirements are owned by the client.

4.       When do I start requirements?

Start with requirements before you look at any software product.

Documenting your requirements, and taking stock of your existing tools, will help you better understand what you truly need. It is also important to talk with other departments in your organization. Chances are you could combine efforts in order to save costs and avoid duplicating software.

When companies start looking at software products before understanding their requirements, they often end up buying into features that are unnecessary or redundant.  By defining requirements first, software options can be better evaluated.

5.       Where do I document my requirements?

Microsoft Excel, Word, Visio and Adobe Acrobat are the most user-friendly and commonly available tools for collecting and documenting requirements.  If you have better tools than those, then by all means, use them.

The key is ensuring that your requirements document can be easily updated, shared, and stored in a central location such as SharePoint or a File Share with version control and change management.  Version control is essential since these documents should be shared between client and developer.

Remember that these are living documents that change over time and the “story” should be captured to support changes.  If done correctly, these documents will evolve into testing documents and training documents.

6.       How do I start?

There are many proven approaches to requirements gathering.  We recommend that different types of requirements should be gathered for different phases of the project.

Budgetary/ROM requirements phase: Your first step will typically be getting budget approval for your project. To do this, you will need to define high-level requirements.  Examples would include X number of reports and dashboards, X number of forms with workflow, etc.  The details of these inputs and outputs are minimal at this point.

Summary requirements phase: Next you will need to create an RFP. Here you must list out the key requirements based on your business needs. This phase often includes a long wish list of items of different priorities. Estimates from developers for both cost and schedule based on your RFP are usually +/- 50% with a lot of assumptions and risks called out by the vendor.

Detailed requirements phase:  Finally, a formal requirements process should be conducted once you select a vendor and before any work starts.  While a good software development organization with both construction and IT experience, like Lydon Solutions, can turn lemons into lemonade, it is advisable to follow best practices when collecting and communicating detailed requirements.  These requirements can be used to estimate the cost to within +/- 10-25%.

Want to know how to get started with requirements? Read our next article where we go over how to put together your Detailed Requirements document utilizing use cases.

Need expert help gathering requirements for a construction project management solution?

We know that the requirement gathering process can be daunting. We are here to help! Lydon Solutions has a set of standard business requirements documents that we use as a starting point. Get a free consultation to learn more.