Lydon Solutions

Construction Project Management Software Solutions

construction project management information systems

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.

How to add a text box to a SharePoint page

Tips from the Field |

Here’s how you can use the Content Editor web part to include a text message on your project web pages in SharePoint.

If you’ve ever created a new project web page in SharePoint, you probably wanted to include some kind of text box for your team. This is a great way to present useful information like project scope, contact or support details, or even a training message to help team members use the site

The first idea that may come to your mind is to simply type directly into a SharePoint zone on a page directly like this:

There is nothing wrong with the above. But you can get more flexible results using the Content Editor web part.

The Content Editor web part offers the following advantages:

·       Flexibility – You can move the web part to any zone on a page without having to copy and paste your text. Plus, you won’t get broken URLs if you include them in the Content Editor web part.

·       One-click visibility control – You can hide the text contained in the Content Editor web part with a click. This can come in handy if you want to show a reminder message on certain days only – or if you want to prepare but not publish the content right away.

·       Audience targeting – You are able to target the Content Editor web part by permission group. So messages can be displayed only to specific project teams based on permissions.

·       Consistency –  You can keep all your pages looking consistent by using standard web part titles.

How to add a Content Editor web part in SharePoint

You can add the Content Editor web part to your SharePoint page in a few clicks:

Add the Content Editor web part

1.       Click Edit from the Page ribbon.

2.       Click on the zone where you would like to add the text.

3.       Click on Insert. Then click on the Web Part icon in the ribbon.

4.        Under Categories, select Media and Content. Then select Content Editor under Parts (don’t see Content Editor? Get instructions to enable it below). Click Add.

You should now see the Content Editor web part in the zone you selected.

Edit the Content Editor web part

1.       To edit the Content Editor, click on the upside down triangle on the right and select Edit Web Part.

2.        Enter your text into the Content Editor web part.

3.       You can customize the Content Editor under Appearance, including changing the title and specifying the height and width of the web part.

4.       If you want to remove the title of the web part entirely, click Appearance and change the Chrome Type to None.

5.       When you are done, click OK in the Content Editor web part and save the page

There you have it.  You built your own flexible web part for text entry that can be placed anywhere on the site page.

Content Editor web part is missing from your SharePoint?

Don’t see the Content Editor web part as an option in your ribbon? Microsoft released an update last year that disables certain web parts by default in Office 365 and SharePoint online. To restore the Content Editor web part, you or your SharePoint admin will need to turn the scripting capabilities back on for your site.

You can find instruction to do so here. After you enable scripting and refresh your site, you can continue where you left off above.

Want more tips and tricks for construction project management professionals?

Our new ‘Tips from the Field’ series features time-saving information for construction project managers. Subscribe to our newsletter to get our latest tips and tricks delivered directly your inbox each month.

And be sure to check out our previous tip to learn how to import data from Excel into SharePoint.

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.

PMIS the Right Way

How-To |

Considering a new Project Management Information Systems (PMIS) for your construction company?

We covered the reasons PMIS implementations typically fail in our previous blog post. Below we share the best practices we’ve learned implementing successful PMIS solutions for our clients over the years. Follow these tips and you will save yourself and your company headaches.

In a future blog post, we’ll explain why we believe Microsoft SharePoint, a tool already in place at most organizations, is the best PMIS option for many companies.

10 Tips for a Successful Project Management Information System Implementation

Do not go into an Enterprise PMIS rollout with your eyes shut.  A PMIS needs a scope, schedule and a budget just like any other construction project.  Buying software is the last step in the process not the first.  Do your homework and follow these best practices:

  1. Take stock of what you already have.  Analyze what you have before going out and buying an expensive new PMIS. You may find you already have tools that will meet your needs. For example, most companies already have Microsoft SharePoint. We have been able to provide 95% of our clients’ requirements by supplementing SharePoint with P6 and Arc GIS integration. Be sure to read our next blog article to learn why SharePoint may be the best PMIS solution for your company.
  2. Take time to do requirements.  We cannot say this emphatically enough. Taking time to do a proper requirements gathering phase is the difference between project success and failure. Requirements are independent of a PMIS, so spend the time defining your process before you even look at platforms. Understanding what your organization needs will make it easier to pick the right tool, prioritize features, avoid bloatware and ultimately save you time and money.
  3. Shoot High, Aim Low.  Plan the deployments so that functionality is released in phases.  The shotgun approach does not work.  Everybody on the project team is busy and their ability to change is very limited.  Small wins build support and foster empowerment of project teams.
  4. Assign Subject Matter Experts. A PMIS doesn’t build itself and magically know how you do things. You have to commit internal resources to collecting requirements, testing, training, encouraging adoption and managing feature requests. Establish a team of internal subject matter experts (SMEs) to support the PMIS throughout the entire Software Development Lifecycle (SDLC). These should be experienced SMEs from each discipline that will use the PMIS, not “newbies.”
  5. Get the right team.  Ensure your PMIS deployment is successful by entrusting the project to a team that is expert on the platform. Many construction companies hire one-off contractors or consultants from staffing agencies to develop functionality and deploy solutions. Companies do this because they believe they will save money. But hiring IT generalists often leads to wasted time, incomplete solutions and ballooning project costs. A PMIS solution should be deployed by a team that knows the product – both hardware and software – inside and out. Hire a team that specializes in PMIS deployments that can efficiently deliver a complete solution.
  6. Build grassroots support for your project.  PMIS systems are successful when users embrace them, not when they are forced to use them by upper management. You can increase adoption by ensuring the PMIS makes things easier and more efficient for all stakeholders. Otherwise you are just creating more work for other teams. Find internal champions in each department who know the business and can influence the rest of the organization. Work closely with them to gather their group’s requirements.
  7. Focus on core competencies.  A successful PMIS implementation requires the help of technology experts with experience deploying project management systems. You are probably thinking that this is convenient advice coming from a consulting company. That doesn’t make it any less true. You know your business backwards and forwards, but you are probably not an IT expert. Your internal IT department specializes in software and hardware refreshes. But they are not experienced with the intricacies of PMIS deployments. Bottom line: you will end up spending double the cost and tenfold the time trying to develop and roll out a PMIS without expert help.
  8. Embrace the cloud.  Companies spend millions maintaining data centers that will never keep up with the latest technology and security requirements.  We realize moving to the cloud seems daunting, But if you want to save cost, improve efficiency and foster innovation, your best bet is to get out from behind your firewall.
  9. Make your IT partner part of the construction team.  Your ideal IT partner should become part of your construction team to understand your business and your requirements. This will allow them to respond quickly to project needs and build solutions as they are needed.
  10. Expect to spend money.  Software is only part of the cost you need to consider. A bigger cost is the labor to develop and support your implementation.  A PMIS should be treated just like rolling out an enterprise financial system or CRM.  You don’t buy a system and then walk away. A successful long-term implementation requires careful initial planning followed by expert installation, maintenance, and support. Make sure your budget takes into account the full lifecycle of the PMIS.

Why Microsoft SharePoint is an ideal PMIS platform

In a future post, we’ll pull everything together to discuss why we recommend Microsoft SharePoint to our clients as the ideal foundation for a robust PMIS solution.

10 Reasons Construction Project Management Information Systems Fail

How-To |

Most construction specific Project Management Information Systems (PMIS) implementations fail. This will not be welcome news if your company just spent tens of thousands of dollars implementing one. But we meet a surprising number of construction managers and owners who are unhappy with their current PMIS deployment. They typically come to us for help after discovering that their fancy new project management system is too costly and complex to implement. Worse yet, no one at their company wants to use it because it doesn’t help them do their jobs better.

We’ve had these conversations many times over the years – enough to know that the construction management landscape is sadly riddled with expensive and ineffective PMIS solutions.

How did the construction industry get to this point? We outline 10 reasons below. If you’re considering updating or implementing a PMIS at your construction company, we hope these tips help make the process smoother. In our next blog post, we’ll also share our vision for how a proper PMIS solution should be designed and implemented.

Top Reasons why Construction Project Management Information Systems fail:

  1. The system is not flexible.  Many PMIS solutions force a team to manage a project in a specific way. The reality is that most companies, projects, and people do things differently. Processes also evolve over time. A PMIS system should be flexible and adaptable – without requiring expensive custom coding.
  2. Internal politics prevent adoption.  Multiple departments are involved with managing a project. Each one has its own specific workflows and software platforms. Implementing a “one-size-fits-all” PMIS across these disparate groups often leads to resistance and lack of adoption. But who can blame them? Deploying a new software tool that doesn’t integrate with other departments’ existing platforms is making more work for them, not less. So everyone falls back on manually importing and exporting Excel files to collaborate. Not exactly a gain in efficiency.
  3. The systems lack internal support.  Individuals who are involved with projects from requirements through implementation make ideal project champions for choosing the proper PMIS. These champions are critical to helping a product gain acceptance in the organization and creating grass roots acceptance.  Without internal support, systems “die on the vine” only to be replaced with another expensive system that never gets implemented.  The system is blamed for the failure and not the organization.
  4. Companies don’t understand what they have.  Project managers and executives are busy. They often simply don’t have the time or technical skills to evaluate the capabilities of their current tools. So they bring in a consultant. But most consultants make money selling fancy new software platforms as well as the services required to deploy and customize them. But this approach overlooks the most efficient and effective option: improving the PMIS solution that the company already owns.
  5. A company’s IT department “locks down” the application.  Once a PMIS is absorbed into a company and hosted on their internal servers, the IT department takes over managing the tool. Further customization and feature requests from users are too often stifled or delayed. Users then have one more reason to not use the tool.Blog Quotes Construction Project Management Information Systems
  6. Business requirements are not valued.  Many companies jump into buying an expensive PMIS solution thinking that the software itself will fix their issues. They then task the implementation of the system to those in the organization that know the least – usually the “newbies” since other subject matter experts are busy running projects.  But this immediately devalues the product.  A system is only as good as the people that develop and support it. There must be commitment to the entire software development lifecycle for a product to be successfully adopted in an organization. Without knowledge of the business processes, proper training, and acceptance by the organization, all enterprise software systems will fail
  7. The wrong team is implementing the solution.  Software development and implementation is a unique craft.  Most construction professionals think they can do it because they managed a construction project. But the truth is they lack the technical experience to do the implementation right. On the flip side, IT companies that don’t know construction and try to build solutions often fail because they build tools that are not grounded in how work is actually performed in the field. A PMIS will fail without the expertise of the right team that knows both construction and how to implement software.
  8. The solution lacks a unified vision.  Companies typically buy the “best of breed” software to do specific things (dashboards, cost, contracts, etc.). Then they end up using only 5% of each systems’ functionality because the rest of the features don’t fit their needs and don’t integrate with other systems. We’ve heard horror stories of team members using up to 10 different systems to do their job – many of which become corporate mandates that make doing their job even harder.  What ends up happening? These individuals enter the least amount of information they can get away in these mandated systems, but ultimately end up doing their real job in Excel. Again, less efficiency, not more.
  9. Management is sold an “out-of-the-box” lie.  Every consulting and software company will claim to offer a one-size-fits-all solution. But there is no such product.  Most, if not all, PMIS deployments are custom coded. Each and every change will be expensive and make the tool more difficult to update in the future. The consultants you hired to install and configure your new PMIS will never leave because the platform is too complex for your in-house IT to manage. Ultimately, the cost to develop and maintain the product will become its downfall.
  10. Companies try for the Hail Mary.  Companies too often try to do too much when they deploy PMIS solutions. Instead of getting the small win, they end up in a state of constant re-engineering.

A better way to implement your Construction Project Management Information System

As we can see, the challenges and resulting opportunities that the construction industry faces in choosing a new PMIS are numerous. Stay tuned, because in our next blog post we will explain how to successfully implement a PMIS solution. The final blog post in our series will share how construction professionals can use solutions already deployed at their organization – tools like Microsoft SharePoint and Excel – to avoid these pitfalls and achieve better results.