Why You Should Document “As Is” Processes

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.