Lydon Solutions

Construction Project Management Software Solutions

requirements gathering

Why You Should Document “As Is” Processes

How-To |

How you do business today – your “as is” process – is just as important as how you would like to do business in the future when gathering requirements for a new construction Project Management Information System.

You may be tempted to focus on how you would like to do business going forward when putting together requirements for a new Project Management Information System (PMIS). Resist this temptation. You will design and deploy a better PMIS by capturing the best practices from your existing business processes. And you will improve user adoption, simplify training, and avoid business disruptions.

Capture Current Business Processes with “As Is” Requirements Gathering

Collecting detailed requirements should be a two-part process:

  1. First document how groups in your organization currently do business. These are “as is” requirements.
  2. Next understand how they would like to do business going forward.  These are “to be” requirements.

Documenting the “as is” process first enables you to understand what worked and what didn’t work. You can then apply the current best practices to make your “to be” processes better.

Tips for gathering “as is” requirements

  1. Not every process needs to be replaced: “As is” processes should be the starting point for any potential “to be” processes. But don’t assume that every “as is” process needs to be replaced by the new system. Take the time to understand the effort and investment involved with the existing process. Document the benefit and ROI for any new process.
  2. There is no “standard process”: Every company, project, and person does things differently. So make sure to include a representative sample of stakeholders in your requirements gathering team and focus groups.
  3. Don’t judge what came before: Avoid being judgmental when documenting existing processes. Business processes often evolve as the best way forward based on various past circumstances and constraints (e.g. limited budgets, tools, or available technology). Focus on understanding the current process.
  4. Mind the gaps: Related to #3 above, current processes and systems often have gaps filled by manual or undocumented steps. This is because information workers will turn to other tools to get their job done when they encounter holes in an existing process. For example, Excel spreadsheets passed around via email frequently become an undocumented part of the project management process. Your “as is” requirements should capture all of these undocumented and manual steps.
  5. Requirements take time and should be comprehensive:  There are no shortcuts to requirements gathering. Listen to each set of stakeholders. Take the time to learn how the PMIS system will be used across your organization. Understand all the interactions with other groups and their processes.  Your final design will be better if you capture this information.
  6. Don’t confuse the system with the business processes:  When documenting an “as is” requirement, be sure to capture how work is actually done with or without a system. Don’t simply capture the steps involved in using whatever system is currently in use.
  7. Beware of reengineering: When asked about how they do business today, users often want to tell you about how they would ideally like to do business in the future. Don’t substitute a wish list for actual processes. Change sounds great on paper, but implementing it can take significant time and resources. Often these reengineered or idealized processes don’t have buy-in from other groups. Your new PMIS will face resistance if it rolls out with processes that are way off from how users actually get their work done. So be careful when you hear “tomorrow we are going to be doing it this way” or “we are in the process of changing over to this.” Focus on documenting how groups do business today.
  8. Manage requirements gathering as a project:  Requirements gathering is just like any other project. You need to set a scope, schedule, and budget. This will keep everyone – you, your stakeholders, your developer, the IT group, and executive management – engaged and accountable for the finished product.
  9. Gather requirements with standardized templates: Create standardized collection templates for both the “as is” and “to be” processes.  This will help you ask the right questions. It will also ensure a consistent format and accelerate the collection process.  Having all of this documented can also help down the road if there are questions about what should be in or out of scope for the project.
  10. They’re ALIVE!   Remember that your requirements documents are living documents. Keep versions, update regularly, and refer back to them often.

If you keep the above in mind while capturing your “as is” and “to be” requirements, you will be well on your way to implementing a successful PMIS for your organization.

Are you considering a new Project Management Information System?

Be sure to read our previous posts with more tips and advice on requirements gathering:

10 Tips for a Successful Project Management Information System Implementation

Requirements Gathering for a Project Management Information System

Gathering Detailed Requirements Via Use Cases

And we’re here to help if you need it. Lydon Solutions has years of expertise compiling detailed requirements for construction software projects.  Get a free consultation to learn more.

Requirements Gathering for a Project Management Information System

How-To |

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.