Lydon Solutions

Construction Project Management Software Solutions

How-To

Construction Reporting Made Simple with Construction Viz and SSRS 2016

How-To |

Microsoft significantly enhanced their lineup of reporting tools with SQL 2016 and SSRS. Construction Viz puts these powerful visualization and mobile capabilities at your fingertips

We wrote about the robust mobile and offline reporting capabilities enabled by Datazen in a previous blog post back in December 2015.

We are always on the lookout for smart solutions to construction program management challenges. Datazen’s powerful mobile reports impressed us right away. Our team used Datazen and SQL to build real-time mobile dashboards and KPIs that construction teams could access no matter what OS or device they used. Datazen also enabled us to create offline reporting solutions for use in the field.

Datazen was powerful, but at the time it was still a separate application that resided on top of SQL. Taking advantage of it required custom integration.

Microsoft changed that by acquiring Datazen and incorporating their mobile capabilities into SQL 2016. Datazen is now a core part of the SQL Server Reporting Services (SSRS) toolkit. We think this is great news for our clients in the construction industry. Read on to learn why.

Construction Viz Takes SQL 2016 and SSRS to the Next Level

Construction Viz, our subscription-based construction project management solution, is powered by Microsoft SharePoint 2016, SQL 2016 and Azure. That means Construction Viz puts the power of SSRS – including the mobile capabilities of SSRS Mobile (Datazen) – at your fingertips, on any device.

Here are just a few of the powerful reporting features that Construction Viz enables for each business need:

SSRS Mobile Reports (formerly Datazen) – Construction Viz leverages the latest SSRS features to provide reports optimized for mobile viewing. Users can get business insights on the go from any device.  These reports are ideal for dashboards and KPIs for the manager or executive on the go to access through a Construction Viz site or SSRS Mobile.

SSRS Paginated Reports –  Paginated reports are the cornerstone of complex reporting in both SharePoint and SQL. These reports are great for printing and bringing into construction review meetings, such as monthly reports, status reports, and form logs. Construction Viz makes it simple to create and customize paginated reports that are attractive, clean and modern looking. Need to add data from a report to a presentation? No problem. Export a live and editable report from Construction Viz to PowerPoint. And, if you already have reports that you’ve created on-premises in SSRS, it is easy to pin any Construction Viz report to your Power BI dashboards to monitor all your reports in one place.

Custom KPIs, Dashboards, and Interactive Grid View widgets – Our custom JavaScript widgets make it possible to aggregate and report on data – both from within Construction Viz and combined with external sources.  Responsive dynamic progress metrics right on a web page are ideal for quick statuses of project progress and interactive data grids provide for grouping, sorting, filtering, and exporting data in an easy-to-use format.

Geospatial Mapping – Location matters for construction projects. Our custom mapping solution enables the integrated display of data from external sources like ARC GIS combined with documents, images, video, and dashboards. This combined information can be displayed geospatially in popup windows or layers.  Stay tuned for follow up blog post on Mapping.

Analytical reports and charts created with Excel – Excel is the most widely used analytical tool today – and will likely continue to be for a long time. Construction Viz integrates seamlessly with Excel, thanks to its underlying SharePoint framework. These types of reports are ideal for project teams to quickly post up existing Excel files.  Simple, easy to use, and already available.

It is exciting to see all the rich new reporting functionality Microsoft baked into SSRS and SQL 2016. Even more exciting is all the new possibilities these capabilities enable for our clients.

Ready to Perfect Your Project Management with Construction Viz?

Find out more about Construction Viz by visiting our microsite for this new offering, or contact us to schedule a free consultation and demo.

Who is the primary stakeholder for your new PMIS deployment?

How-To |

Your organization’s project managers should be the primary stakeholders for any new Project Management Information System. Here’s how to keep the priority on them by doing a basic stakeholder analysis as part of the requirements gathering process.

As you begin gathering requirements for a new Project Management Information System (PMIS), one of the biggest challenges you will face is prioritizing features among the different stakeholders in your organization.

You may be thinking that a PMIS should equally address the needs of all stakeholders. Ideally, yes. However, the ideal scenario is rare.

The requirements gathering process will most likely produce a long list of features and you will need to make compromises. Perhaps some features will be part of the first phase, while others will be added later.

Since your project managers will be the power users of any PMIS your organization deploys, their requirements should be prioritized ahead of “nice to have” features from other stakeholders.  Your goal should be to ensure that any new system provides your organization’s project managers everything they need to make better decisions with information that is accurate, timely and meaningful.

Most every other feature should be secondary.

What are the highest priority features for your PMIS deployment?

Often PMIS projects wind up being developed based on things like:

  1. Auditing requirements
  2. Claims management
  3. Document management
  4. Fancy dashboards for executive reporting
  5. Approval workflows and reporting

But most of the above features would not be top priorities from a project manager’s perspective.

So why do so many PMIS implementations prioritize these things over what is most important to project managers? There are many reasons:

  • Feature requirement lists are heavily shaped by who participates the most during development. Project managers may be too busy running projects to attend planning meetings for a new PMIS.
  • Perhaps the project managers at an organization aren’t technically savvy about what is possible in a new PMIS.
  • There may be a lack of agreement on best practices.
  • Budget limitations may keep organizations from exploring features or enhancements – especially if an organization is deploying an expensive one-size-fits-all PMIS platform.

So what ends up happening? The resulting PMIS becomes overly complex since the stakeholders inevitably become Document Control and Auditing when there is no PM representation during requirements gathering. As a result, the PMS tracks every minute detail in case of an audit or claim. This means a ton of extra data entry for project managers and engineers. Meanwhile, project managers still don’t have the tools they need to do their job more efficiently and they fall back on manual workarounds. In other words, another failed PMIS deployment.

The above is very strange since the cost of Document Control Specialists can be less than 25% of a Project Manager.  Ask yourself: would your organization rather spend money on Document Control Specialists or Project Managers?

Why you should do a Stakeholder Requirements Assessment as part of your requirement gathering

We recommend doing a Stakeholder Assessment when we plan and deploy a new PMIS solution. A Stakeholder Assessment defines all of the stakeholders, their success criteria, decision making process, role within the project team and areas of focus.

We then apply the Stakeholder Requirements Matrix (See below) to what we learned during the requirements gathering process.  The Stakeholder Requirements Matrix provides a framework to prioritize everyone’s needs so you can prioritize requirements gathering and phases of a development/deployment.

A Stakeholder Requirements Matrix template for your new PMIS

Here’s a basic template to start a simple stakeholder analysis for your organization’s PMIS deployment:

  1. Start with a blank table or spreadsheet
  2. List the key stakeholders in your organization in the left column
  3. List all of the project areas that you’d like your ideal PMIS system to cover in a row along the top
  4. Mark the areas that pertain to each stakeholder’s primary responsibility
  5. Rank the project areas according to priority

All the features on your requirements list can now be categorized by project area and priority.

Below is an example for a typical construction PMIS project.

Let us know what you think. Was Stakeholder Requirements Matrix helpful for your organization? How have you managed these challenges on your software deployments?

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

We know that the requirement gathering process can be daunting. Lydon Solutions is here to help! Our team of experts has deployed project management information systems for clients managing multi-billion-dollar construction projects.  Get a free consultation to learn how we can help your organization.

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.

Gathering Detailed Requirements Via Use Cases

How-To |

Document detailed requirements for your construction Project Management Information System (PMIS) with use case analysis.

If you read our previous blog post, then you know that the requirements gathering process is critical for the successful deployment of your Project Management Information System (PMIS).

In this post, we focus specifically on gathering detailed requirements for your construction software project through a use-case approach. Use cases help you define your detailed requirements in a very granular way based on your existing processes and desired outcomes.

Stay tuned for future posts covering other methods for gathering detailed requirements.

Use Case Definition

First, what is a use case? Use case analysis is a technique used to identify the requirements of a system (such as a software design or process). It should include both a definition of the processes and the classes (which are a collection of actors and processes) involved.

Compiling Your Use Cases

Start by listing all the necessary business functions you need your new PMIS to deliver. These target outcomes or deliverables are your use cases.

Documenting Your Use Case Processes

Next, compile all the steps necessary to reach these target results. Identify who (or, in some cases what, if other systems or processes are involved) takes each action. Then define what the result should be from the system to each of these actions.

Think of what you are doing as basically creating a step-by-step description of a cause-and-effect process for each of your business functions.

Here’s a detailed example of how to document your use cases:

1.       Define the Pre-Condition

What is the state of the process prior to the use case occurring?  Your pre-condition should be defined as some state in the system before an actor takes an action.

2.       Define Actor(s)

List the users that are involved in the use case.  A user performs an action in a step to achieve a result.  An actor could also be the system in multi-step processes in some cases.

3.       Define the Steps or Actions that the Actor(s) take

A step or action is a defined activity with a start and finish.  It also includes necessary interactions between the actor(s) and the system.

It is important to be very specific. Carefully document steps that could be misconstrued by a developer.  If there are potential variations to any step, create additional sub-steps as needed.

4.       Define the Expected Result

Specify what the desired result of the action(s) performed by the actor(s) should be.  This output should be in terms of what the system will provide if the steps are followed.

5.        Define the State of the Use Case After the Step occurs

Finally, define the intended post-condition. This is the system state that must be true after the use case process is complete.  Any subsequent use case should use this post-condition as a pre-condition in order to know where to start.

When you are done, you should be able to represent each use case in a diagram like the one below in your detailed requirements document.

Let Lydon Solutions help you accelerate requirements gathering for your construction project management solution

Want expert guidance gathering requirements for your new PMIS deployment? We are here to help! 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.

8 Reasons To Use SharePoint to Manage Your Construction Projects

How-To |

Read why we recommend SharePoint as the ideal Project Management Information System for our clients in the construction industry.

Microsoft SharePoint might not be the first thing that comes to mind when you think about construction project management. But it should be. SharePoint is your ideal foundation for a flexible, efficient and cost-effective construction Project Management Information System (PMIS).

Here’s why:

1.       You probably already have it 

SharePoint is the leading Enterprise Content Management System deployed by over 70% of Fortune 500 companies.  It is used by companies of all sizes in virtually every industry.

So chances are, your organization already has SharePoint. This means you’ll save money on licenses and training.

2.       It integrates with the tools you are already using

SharePoint integrates with tools you use every day, like Oracle, SAP, ESRI Arc GIS, Microsoft Office and more.

3.       All the features you need are available

SharePoint has all the construction project management tools you need – no coding required.

  • Sites – Configurable Web sites to aggregate and share your data
  • Communities – Forums where project teams can collaborate and share documents and data
  • Content Management – A complete document management solution, including forms (both online and offline), and workflows.
  • Search – Enterprise Search across SharePoint and even external systems
  • Insights – Powerful tools for reporting and ability to web-enable Excel, Visio, Project, Access, and Excel
  • Composites – Robust no code solutions and mashups can be built to parse and share data as needed

4.        Built-in collaboration tools

SharePoint, unlike most other construction PMIS tools, is designed to share data by default.  The data can be created in SharePoint, SQL or integrated from other applications. You can use SharePoint to collaborate across teams, departments and even with external stakeholders.  You control who sees and does what.

5.       Take the pain out of reporting and analysis

SharePoint features powerful reporting tools for quickly and easily aggregating and sharing data.

Here are just a few examples:

  • SQL Services/SharePoint Services – Build complex reports that pull data from any content source in SharePoint or SQL. You can define query parameters and even output in a paginated, printer-friendly format.
  • Dashboards – Build configurable dashboards and scorecards using SharePoint and third party tools.
  • Excel Services – Use Excel and Power Pivot to build complex pivot tables that link to all of your data sources. Then create your own reports in Excel and web-enable them with SharePoint.
  • Power BI – Leverage Microsoft Power BI to transform your data into rich visual displays and share them with your team on SharePoint.
  • Mapping – Display your data geospatially in a map using ERSI’s mapping web part.
  • Views – Every List and Library in SharePoint can be configured for multiple views, include public and personal, depending on the stakeholder.

6.       Be ready for the future with powerful configuration options and third-party support

Ever wish you didn’t have to go to your software vendor to make changes?  Maybe you would like to do it yourself or bring in a third party.  SharePoint lets you do that.

SharePoint is an extremely configurable application.  You can build out pages, forms, workflows, and dashboards without writing any code. For developers, the backend is SQL, so whatever you can think up can be customized. Both code and no code solutions can be built into your SharePoint environment that you can keep re-using.

And beyond that, there are thousands of companies that provide consulting or tools to support Microsoft SharePoint.

Do you know of any PMIS software product that will allow their clients to develop custom solutions on their platform?

7.       Security and reliability you can trust

Microsoft has built SharePoint from the ground up to be secure. You can set security policy at the site, content, folder and even field level.

Customers of Lydon Solutions can also rest assured that we host their SharePoint environments on Microsoft Azure. This is the same industry-leading cloud platform where Microsoft hosts its own Office 365 service. Read our post on Microsoft Azure to learn more.

SharePoint also has the advantage being a Microsoft product. Microsoft is the leader in the business software space. There is minimal risk that Microsoft will go bankrupt or be bought up and degraded by another vendor. The same cannot be said about many custom PMIS solutions out there.

8.       Flexibility depending on the maturity of your Project Management Office

There are no two companies, projects, people, or processes that are the same.  But most PMIS solutions force you to use their system their way (e.g. follow a specific WBS structure or rigorous steps in a process). While having a starting point is great, if you want to change those steps, it will cost thousands and your request will get added to a product roadmap which may or may not be included in the next release.

SharePoint, on the other hand, was designed to be configurable.  You can make changes without going to Microsoft to do so.

Ready to save time and money on your construction projects with SharePoint?

Contact us for a free consultation to learn how SharePoint can help you take control of your construction projects.