PowerBI Progress & Schedule Dashboard – By Darrin Kinney

I have recently been developing a series of videos that highlight the key features utilized in a progress and schedule dashboard. The videos showcase the capabilities of PowerBI dashboards in the Project Controls space. I have not seen dashboards effectively used in this way and want to share the valuable knowledge.


I have recently been developing a series of videos that highlight the key features utilized in a progress and schedule dashboard. The videos showcase the capabilities of PowerBI dashboards in the Project Controls space. I have not seen dashboards effectively used in this way and want to share the valuable knowledge.

This series is not meant to be a step by step guide. There are subtleties about this demo that may cause difficulties in the production environment. I would simply recommend you share this with your development team and discuss the pros and cons of your approach. Oftentimes, a more straight forward approach is more valuable when compared to endless development polishing an inferior product.


Part 1: The Showcase

This video gives an insight into the key capabilities of the dashboard. Having the ability to seamlessly review schedule activities, and how these contribute to the overall progress and forecast, is invaluable.

The ability to quickly dive into your schedule, without having to deal with the confines and limitations of your actual scheduling tool are also key features.


Part 2: The Excel Feeder Sheets

This highlights a simple Excel feeder sheet. Too often the time phased data that our schedules produce are not easily accessible in a digital format. I have built an excel file around a typical structure that project controls deals with. This structure will lend itself nicely to the steps that follow in converting the into a database format.


Part 3: PowerBI PowerQuery

Here we import the data from the Excel feeder sheets into the PowerBI platform. The use of PowerQuery is so embedded with the way PowerBI works. The steps you need to follow here are the similar to the steps you would need to follow in inserting the progress and schedule data into any formal data structure. The way we think about data is sometimes not compatible with the format that databases need. This is specifically around the need to “unpivot” time phased data.


Part 4:  PowerBI Measures and Dax

With all the data now structured and available to PowerBI, we need to now dive into the use of DAX to create Measures. A perfect example in the use of measures is in the generation of progress curves.

What might seem line a straight forward approach to drawing simple progress curves, is in fact (within the realms of PowerBI) not that simple. However, if you follow a logic approach and know what calculations are needed, the world is your oyster.


Part 5: Integration of JIRA and Agile Methods

In the (as of now) final installment of this series, I showcase a way in which we can integrate our PowerBI dashboard with a JIRA project. This approach is completely different from what you might expect. I don’t want to put a PowerBI dashboard ontop of my JIRA task list. I want to put a JIRA task list on top of my schedule.

The purpose of the dashboard is to extract the SCHEDULE data from the scheduling tool. When variations to prior forecasts occur, or where further detail is needed, we are often constrained because pictures, running commentary and discussion about each activity is not something that resides in our schedule. However, we can use JIRA to easily capture those elements and use our PowerBI dashboard and a linking tool to integrate everything together.


The Future: ???

There are still a lot of features and extensions that I have yet to formally discuss. The next steps are likely going to be a showcase of a SQL Server backend for this data. There is a lot of information that is missed in the way this dashboard imports data (specifically past budgets). Therefore visibility into changes is restricted.

Another interesting feature is the use of saw tooth graphs when budget changes occur. I have a clear vision for how this is possible, but perhaps not the development know how. I will definitely be passing my ideas on to a few more tech savvy than I, and will hopefully have something to say about that in the near future.

In general, the way in which dashboards and data are embedded into our work processes, is a field ripe for growth. It is also an endeavor that can greatly increase the visibility into project controls data and can also bring teams together using integrated tools like JIRA. As such, the future is bright and where we should always have half an eye looking.


Digital Transformation – McKinsey Practices – Darrin Kinney Commentary

A short commentary on my personal view of the 5 key digital practices promoted by McKinsey

For me, value is generated out of simple smart execution of our projects, but looking back into the feasibility studies and at the delivery of engineering HUGE gains can be had. I think McKinsey hits a lot of key issues, but perhaps missed the point of WHEN in the project lifecycle specific practices can be best employed

Understanding where value can be unlocked and realized, in the construction focused digital transformation space, is still elusive. Companies are making huge strides, mostly on backend support services such as HR and general employee services, such as online training, however, I personally do not believe these areas are where value is created. It is more an issue where cost has been eliminated as opposed to value creation.

For me, value is generated out of simple smart execution of our projects. When we can arrange for a pump to be installed right off a truck onto a foundation, have a mechanical crew available to commence work on it, and know that pump is on a critical path towards project completion: that is where we realize value.  When we can realize that differing rates of installation (linear planning), will force certain commodities to be the pivotable drivers to our schedule, understanding that delaying the commencement of later activities is actually a value adder due to the efficiency gains (or re-arrange your area handover to complete some areas without having to wait for everything). These are obviously simplistic examples: but, we need to be grounded, and understand the problems we face, and be clear on where digital transformation can support solutions to these problems.

In the realm of lightweight digital strategy, my series on the subject hit some good points

Digital Strategy in Construction – The Videos

In the realm of Project Management, I think the use of AGILE and the tools that have spawned from the Agile revolution will play a part in smart digital transforamtion

Agile In Construction

However, if we expand to a much broader topic, I think turning to companies like McKinsey is a good place to start. One of my favorite documents on this subject is

Decoding Digital Transformation – By McKinsey

The 5 Key practices outlined by McKinsey to capture the full value of digital initiatives:

  • Focus on fixing pain points, not installing IT solutions.
  • Implement digital use cases that promote collaboration.
  • Reskill and restructure engineering teams.
  • Adjust project baselines to capture value.
  • Connect projects to unlock impact across the enterprise

In my world or project controls, we perhaps interact with these practices in different ways. What follows is my personal take on these topics and what they mean to me and how I believe we can embrace them to extract value from digital transformation

Understanding FEL and where value exists

Before I really begin to discuss each item, what I really want to bring to the table here is the concept of WHEN. Major construction projects all operate under some sort of front of loading process

Front End Loading (wikipedia)

Most value gained in project development is during the FEL Stages. As I primarily work on the execution project management side of things, my perspective on what is valuable to me in the exuection space is different. Therefore understand that way you embrace the 5 practices will be a function on where you are at in the FEL process for a specific project, and your overarching project development lifecycle for what may be a variety of projects

Some of the practices (my personal belief) are more geared towards early studies, while others are more geared towards Execution. Below is my quick take on what practices are relevant to consider in each stage of your project development. This is more a strawman for discussion, and exactly why I write these blogs – to try to stimulate discussion on these topics.

The first 2 topics are in my view, more applicable to the execution environment. As such I have some good perspectives and existing material on them. The remaining are more study focused.

Focus on fixing pain points, not installing IT solutions. 0% 0% 20% 80%
Implement digital use cases that promote collaboration. 0% 0% 20% 80%
Reskill and restructure engineering teams. 80% 20% 0 0%
Adjust project baselines to capture value. 0% 50% 45% 5%
Connect projects to unlock impact across the enterprise 80% 20% 0% 0%

With that, lets now jump in and unwrap what each of the 5 key practices mean to me.

Focus on fixing pain points, not installing IT solutions

A few years ago, I was called in to a project to assist in the implementation of EcoSys. I have a good amount of experience with cost systems and it was nice to know someone could lean on me help them install their new “IT Solution”.

However, immediately, it was apparent the initiative was doomed to fail. The issue was exactly what McKinsey indicates – the company was not focused on the “pain points”. For this particular project, visibility into the build up of a specific contract final forecast cost (FFC) is the day in day out function of the cost team. However, that build up of data is not easily managed inside EcoSys. Creating “detail items” for each site instruction, when you have 100s of site instruction on each contract, and 10 major contracts – and that is only the cost need for site instruction – you quickly realize that information needed to be managed elsewhere.

Obviously the project already had an existing, more bespoke, system that allowed them to manage the build up of the contract FFCs. So, installing a new tool that just extracted the bottom line number from one system and consolidate it – was of no value to the project. Quite the contrary, extra work is required each period to now update Ecosys with summary level data. Now, as part of another key practice (Connecting Projects), having access to enterprise wide data is important; however, I would query where the value add is before pursuing that option.

My video on EXCEL Hell is a good primer on where you can look for understanding where PAIN POINTS exist

So, I can’t stress enough, before you begin pursuing a digital transformation, look at what you are doing and dive into the “PAIN POINTS”. More often then not, when you start looking into the weeds, you realize that a specific IT solution might not be the silver bullet.

Implement digital use cases that promote collaboration.

I am a huge proponent of collaboration. In the McKinsey position, they focus on interdisciplinary interfaces. In the project controls world, this is our bread and butter. We constantly need to get information from Engineering, Procurement, Contracts and all functions and merge this all into a manageable project management framework – either being the schedule, specific management plans, or our estimate and cost forecasts.

Anything that can positively influence collaboration as opposed to simply forwarding emails and excel files, is a huge win-win.

I have discussed my position of trying to implement a tool such as JIRA. I have a key quote

“how do we interact as a TEAM”

That concept is a core premise – dive into how your project interacts. Look at how information and data is shared. Who edits what- how – where does it go – what does someone do with it?

So when we look at collaboration and implementing a specific solution for a use case, ensure that use case touches many people in different functions. From that, if you are successful, that will immediately leverage you for future wins

Reskill and restructure engineering teams.

I can’t stress enough, real VALUE on construction projects is delivered by ENGINEERING.  Although, value can be retained via efficient execution, truly innovative approaches and step changes in value have to be driven by ENGINEERING.

A clear example we have seen in the past few decades it the use of Modular construction, and focused Pre-Assembly. This is not specifically new, but is not perhaps as embedded into our culture to keep driving the limits for what is possible.

To achieve gains, your engineering team needs to be at the forefront of technology. You need to empower your engineering teams to constantly venture out into the real word and see what everyone else is doing and to not be afraid to mashup something they see elsewhere and try new things. The risk adversity of owners oftentimes restricts this. So, you need to be careful implementing new ideas, no question there.

All I can reference here, is perhaps the way TESLA has designed and engineered their cars. There application to smart control systems on cars is revolutionary and now makes every other car made look anachronistic. You only get that solution by engaging an engineering team willing to think outside the box.

A critical aspect of engineering teams, is the need that there is negative value into trying to implement restructuring of engineering teams during Execution. Or at least, if you do truly pursue that approach, you have de-facto moved your project OUT of Execution and back into a study phase. Again, always having a clear mindset in where you are in your project development cycle is critical in how you make decision and interact with digital solutions.

Adjust project baselines to capture value

One of the most important terminologies in the planning world is DRAG. DRAG is the opportunity that a project has in pulling back the critical path until a secondary sequence of work becomes critical.

When a change in execution caused by smart digital tools impacts the critical path, you are limited by your DRAG. Past that point, further gains are no possible (without also changing something else). Therefore, the balance between smart execution and reality need to be constantly played off each other.

Another aspect that is key in this practice, is that we need to perhaps understand where this adds value. In the FEL 2&3 phases, or perhaps better known simply as the feasibility studies, this is where baseline development occurs. Thus, this is exactly where you want to dive into how digital solutions can impact the execution of a project. In my initial example of seeing clearly the linear quantity limitations a project might have. Making decision that either increase a productivity rate, or split the project into more access points needs to be done duration a study phase to add value. Opportunity exists to extend this concept into execution, but careful management of changes in execution would be needed.

Connect projects to unlock impact across the enterprise

Executing a true program of work is the nirvana of every project. I have seen clients are limited in their abilities to run a program of works (outside the government sector). Often times instead, you have competing owners executing competing projects at the same time.

Personally, this practice might be better replaced with concepts or partnerships and teaming arrangements to perhaps unlock value among an industry, not just 1 company. McKinsey makes specific reference to:

consolidating cost and schedule data from multiple projects and business units to increase the accuracy of bids for future tenders, thereby increasing the margin

gaining an enterprise-wide view of resources to optimize resource loading and respond quickly when project demands change

creating central repositories for designs at the element, package, and project levels so those designs can be repurposed on future projects

Consolidating cost and schedule data: Reference Estimate data is a “great to have”; however you will be again limited. Good estimate data will likely reside OUTSIDE your company and a better practice is to have closer alignment with delivery partners.

Enterprise view of resourcing to adapt to changes: Again, project are delivered by a much wider matrix of differing companies. Aligning resources is something I always hear discussed, but have never seen in practice. Here to, a better practice is to have alignment with delivery partners. Only when you can act as an industry team, can this happen.

Central repositories for designs: This is something that I don’t feel is notable. Obviously it is important and is something every engineering company and client will keep. I don’t feel as as if this really belongs as a novel practice. This is more standard business as usual.

Bottom line is that I believe that a much better practice, as opposed to aligning projects from an enterprise wide view, is to instead ensure better contracting relationships with delivery partners and executing smart engagement to extract value from engineering delivery partners.

Closing Thoughts

Huge gains from smart implementation of digital strategies can be had. With a good framework of practices. I think all effective digital transformation is led by PEOPLE. While we have noted 5 key practices, never loose sight that digital transformation is a direct function of the people involved. Great ideas can fail if not implemented by great people. My view is that the common theme linking successful digital initiatives is people – and communication. In the end, nothing is substitute for plain ole good project management ideals.

When you look at your projects and begin to discuss how digital transformation can positively be implemented, pay close attention to WHEN in your project lifecycle you are. Some initiatives are more focused on what you can do during execution, while others provide value earlier on and are not effective during execution. Having a digital framework to ask key questions as certain points in your project lifecycle is a natural extension to implement these ideas.


Digital Strategy in Construction – The Videos

Within the project controls world – I have found the strategic approaches to digital strategy to perhaps be a bit lacking. They key is that nothing exists in isolation. You need a fully comprehensive approach Gaining awareness of what is out there, gaining clear understanding of the current capabilities of your staff and in general, being at the forefront of our technological world is what the future will bring

Specifically in the world of project controls, I have found the strategic approaches to digital strategy to perhaps be a bit lacking.  This was the key impetus for me to put together the presentation last year. For me, digital strategy is not about implementing PRISM or EcoSYS. It isn’t even about upskilling your staff. There are more holistic views that can enable users to operate smarter. Obviously, this goes hand and hand with systems and education. They key is that nothing exists in isolation. You need a fully comprehensive approach

The genesis of the ideas were several posts on LinkedIn and a Blog Post on Digital Strategy

I have posted each of these separately, but nice to have them all together in once concise post that I can reference in the future. There is a similar post on Agile in Construction

Digital Strategy – Dealing with Excel Hell

Excel Hell is where we all live and the area of our business that has seldom been touched by digital strategies. Perhaps times we start to think what we can do about it and move to the next step


Digital Strategy – Enter Data Once

The next step is Entering Data Once. This term is tossed around a lot, but the way we view and deal with this is a dogs breakfast. I don’t necessarily understand all the possible solutions, but perhaps the framing of the problem and discussions about what we can do about will stimulate some discussions.

Once we have data stored digitally, we can move onto the next step: Be Visual


Digital Strategy – Be Visual

The future is all about digital dashboards. If you are not in this space now, you will be in the future. Now that we have our key data stored in a digital format, we can start to move our reporting into the 21st century: BE VISUAL!

Whats in the Future?

I think the sophistication of many of the commercial software packages can in some regards leave my beliefs redundant. Companies like Sablono and JIRA not to mention a myriad of other providers are implementing many of the concepts I try to follow related to digital strategy.

Gaining awareness of what is out there, gaining clear understanding of the current capabilities of your staff and in general, being at the forefront of our technological world is what the future will bring

Thus, perhaps the most important strategy I can recommend

Digital Strategy – Follow all the latest Trends and know all the software capabilities

This is perhaps at the core of my beliefs. Unless you at the forefront, vision alone is not sufficient.

Digital Strategy – IT by itself does not solve your problems – its how you use IT

SharePoint / PowerBI / Primavera P6 Integration – By Darrin Kinney

Which mix of applications will improve your construction progress reports? Understand simple steps, like adding comments to SharePoint and quickly publishing Primavera construction data through Excel, Access, and PowerBI.

I have dreamed about the ability to easily integrate many of my favorite applications. A few technological roadblocks had prevented me from pursuing this, but I am finally in a position to showcase what I view to be a quite seamless integration chain and management process.

Our key objective is to

  1. View our schedule activities
  2. Allow our area specific team to provide commentary on each activity (if we view the activity deviating from our plan or perhaps need to include notes about key interfaces)
  3. Allow our project wide team view our comments
  4. Provide a tool to present schedule and progress aspects of our area

Note that I still view JIRA as providing a tool that immediately makes this post redundant.  Although, in lieu of everyone jumping on JIRA, let’s dive right into an interesting use case of common applications.


Primavera exported to Excel

For this example, I am using dummy schedule data. The ideas here are quite universal and can be used with any schedule. Care should be take to ensure proper filtering to avoid ever displaying too many activities.

The key objective here is to be able to export our activities to Excel and then upload the data into a SharePoint list. Tools, such as XER reader, provide the ability to quickly move activities into Excel.


Here, a lot of interesting hacks and strategy come into play.

Digital Strategy – Enter Data Once

SharePoint is a perfect tool for editing data in one location, and to source it in many different ways without having to reenter it.

The first thing we need to do is create a list.


You can insert a few more columns to pull in Plan Dates, or prior updated dates. However, we are only looking at a comments functionality with this list. We can live with a very stripped down data set (and leave PowerBI to capture everything at a later point).


The above view is what you would see in the edit view on your SharePoint website. This functionality is fast and allows a team to provide a much more concise internal list of comments specific to each activity (or perhaps only key interface activities).

Where the above doesn’t work? It doesn’t work in situations where we might have a chain of comments. SharePoint allows effectively free text fields. We can enter multiple lines of data for each comment and include dates inside the comment for when the comment was made. There are more sophisticated data models that would allow for multiple comments to be actioned on each activity. However, this example is a lightweight solution — using easily available, off-the-shelf technology. From this point, we dive into your standard PowerBI template.

An URL with predefined filter criteria applied to the SharePoint list is simple. However, we need to use this with caution, because we may end up with 1000s of activities in SharePoint and it will be hard to update this in the future.

Microsoft Access

It is possible to directly edit a SharePoint list using MS Access. In this example, we get constant updates from our contractors on dates. Keep in mind, the SharePoint list is not the management tool for the dates or progress (however — looking at the above, it can be!).

To allow for the list to be bulk updated with new dates and progress figures, we can utilize a query in MS Access. I am a firm believer in the ability for MS Access to facilitate moving data between different systems.


In this example, I will be using an existing template I have previously discussed (follow this link to the Construction Progress Reporting post).


Where reports in PowerBI fall over, is that users have a difficult time actually being engaged as managers of the data. We do not have an easy ability to provide context or comments to specific data elements.

Here, we can immediately see that we can interface this dashboard with our SharePoint list. In our PowerBI queries, we can link to the SharePoint list.


As our schedule data is unique per ScheduleID, and our SharePoint list is unique per ScheduleID, we can link these 2 tables together and pull the comments into our table.


The resulting comment can the efficiently placed on a custom tooltip.


As with any comment, it is important to include an indication of criticality. In the above picture, we don’t have an indication if a comment exists, and if a comment does exist we do now know if its important. Therefore, in our SharePoint list, we can use an extension to insert a traffic light in the cell. Then on the PowerBI visual, a traffic light is displayed using a small, colored circle. This would allow for quickly glancing at all the activities and being able to quickly drill into a critical comment.

This is different from looking at Total Float or Variations. Typically on-site, various activities have issues for various reasons that may not have anything to do with float or variances. These may be risk-related issues we are trying to prevent, or perhaps gets others to understand. This approach to comments is exactly what can lend value to a project.

Agile in Construction

Will Agile ideas and approaches fit the construction world – Definitely.

This does not mean I think that a lot of the tried and true practices we have developed need to change. Quite the contrary, the construction world have for decades been the pioneers for quality project management.

What has changed is the way in which people communicate and the culture we live in. Agile does have a lot of good properties in the personal communication. So I believe the construction world needs to embrace some aspects of Agile and the software tools that have been developed to support Agile management


Introduction to Agile in Construction

In this presentation, we can see that indeed many of the terms used in Agile have existed for a long time in the construction PM space. So, in many ways, we already are Agile. Thus, if you go down a path to embrace new management approaches, you first need to understand the current overlaps and also where opportunities exist.


Using JIRA to improve communication on construction projects

There are some great possibilities in using JIRA in the construction world. I do not believe a typical Agile approach fits into the project space; however, many of the ideas are sound and specifically the tools that have been built to facilitate Agile can be molded to fit the construction project space.

Specifically, this relates to the way we communicate and track the work we are performing or the work we are overseeing. Applications such as JIRA and DevOPS have capabilities that I feel are a perfect match for the construction world and we need to be looking how we can customize these new tools to really revolutionize the way construction projects are managed.

Controls Accounts for Cost – Houston we have a (possible) problem

This article captures 2 issues that are related and perhaps not clearly discussed or understood (not even by me): Level of Detail, and Transactional vs Account based tracking

Many cost tools, for right or wrong, are now almost entirely Control Account based. This leads to some conceptual issues where people have been use to managing data in a more transaction way.

Additionally, when we begin to establish defined control accounts, picking the right level of detail, and how changes are managed between Controls Accounts, requires a lot of creative accounting (thoughtful process mapping through all your systems & Digital Strategy)

The below is just a primer for a potential discussion. This is a post on what it means to pick a correct level of detail and what it really means to how you manage your costs.

Transaction Management

This is my wheelhouse, the way my brain primarily works when dealing with projects. List Management. Everything is a new record.

We have contracts with detailed line items, we want to retain our budget line items, each contract line item will have various columns for Committed, Forecasts, Incurred and Paid values. We manage these detail items in this way. Below is a example of how we really manage costs (and progress and deliverable). Excel (sharepoint, or a simple flexible database) provides an ideal solution for users to manage this detail.


However, the new age of cost tools want us to view projects at a more “control account” level. In the above example, I have created a control account to a WBS and Commodity code level of detail.

In the above example, we have 4 contractors working on this scope in various capacities. Although, its way more subtle then that, we actually only have 1 contract and 3 expected contracts. We have parsed our budget into what we expect to be 4 different contracts. Thus only 1 contract has a commitment, but yet we have a forecast (and budget) for all 4. Each contract will have a full detailed list of detail items that we will manage. We will items for specified growth, perhaps contingency, maybe a few site instructions. A transactional list!

Quantity Growth – new line or modify existing?

Here again is one of the conundrums of how we manage (specifically related to progress measurement. Consider a project with some concrete and steel.

If we have a change in quantity for a foundation, where do we capture the change and what does it look like in our database. Too often, we look at this and manage it using a simple excel file – which can make the process easy. However, this is a very complex issue. If we add a line item and base our progress off committed quantities, we will have to update 2 line items with %’s. However, so many options exist to capture this.

And again, if instead this item is managed at the “control account” level, all we need is the total actual quantity, or simply the overall % for the control account. When you look at the above from a control account level, you capture all the detail, but yet for % management, you can disregard all the %’s to the details and only insert a % to the control account.

Which method is right, which method fits into your cost/progress system, which approach aligned to your specifications?

In the second method above, you loose the ability to calculate a specific % for variations. So again, we have taken just a simple issue, and created a complex nightmare.  Obviously, we all solve these problems day in and day out. The issue here is again just to bring this topic to light and how the new range of cost tools may not be flexible enough to really capture what we do – nor should they! The real answer is as we all do now, some detail is managed inside excel and some abstraction ends up in the system.

Control Account Management

In the above, we have seen the importance of picking the right control account level of detail, but, we perhaps haven’t conceptualized what a controls account is in the first place. For “control account” management, we want to manage “SCOPE”. For this package of scope, we sum up all the detail coded to the same codes.


When we look at scope, it is much easier to compare against our estimate which was built to this level before we had to detail with specified growth, claims, site instruction and even contractor commitment. This is why we want control account management and why so many cost tools are forcing us down this path.

Whats the Problem?

In the above example, the “control account” is meaningless. We can not “manage” anything at the control account level. The control account is only a metric.

Instead we are going to manage our contracts in isolation. Each contract will have its own specifics and likely its own approvals when we modify a forecast or a commitment.

A solution to this conundrum is to split the above into 4 control accounts (or more). However, that creates a nightmare for everyone dealing with the new cost systems where creating cost accounts, loading budgets and costs is not straight forward. Doubly so as we haven’t even begun to discuss at what level we manage our time phased data.

All the new tools also allow us to manage “detail items”. Budget again, as soon as you start to push the level of detail of management into the detail items, you may as well make the detail item its own control account.

The Problem is – Whats the right Level of Detail?

You can run this problem down rabbit holes with how we manage engineering deliverables, how we manage progress items, manhours, quantity management, etc. Here I have just presented the problem related to strictly just a cost control level. But yet the dimensions for each of the items above is multiplied by each of the additional management datasets we also track.

Picking the right level of detail that goes into our cost tools, is more of an artform than it is a science.

My view is that we need easy flexible transactional capabilities from cost systems to ease the excel hell aspects. But yet at the same time, need to understand how the transactional records join up to perhaps a more formal CTR or Control Account level of detail.

Construction Progress Report – PowerBI – by Darrin Kinney

A quick and easy construction progress and schedule dashboard.

I have previously outlined an approach that can be used for Engineering Progress.

This post is an extension to that which instead of looking at engineering model development, instead looks at construction development. I don’t want to delve too much into the details about exactly how this was built (again see the post above).

Some big differences is that I have used a resource assignment view. in addition to the date metrics This allows for resources histogram and progress curves to be quickly sorted down to an activity level. This approach also follows a prior post Resource Analysis Dashboard .


The data


The underlying data is very similar to our engineering progress example. We can use a flat file export direct from P6 with a standard set of columns. As I have mentioned before, you can achieve this in a SQL query as part of a larger data model, although with everything, a delicate balance is needed (balancing database formalism and easy excel solution)

We will also have the resource assignment data


The WBS Slicer and Area Selection


This design element doesn’t work for project with too many WBS elements. For this example, each major area only has about 10 WBS elements, therefore I could pull this off with no drama. I really prefer this selection as opposed to drop downs where it is often difficult to quickly make  selection.

The Pie and Metrics


Here we follow much of the look and feel I used with the engineering progress; however instead of just using activity count metrics, I have also inserted hour and percent complete metrics. There is nothing fancy about these.

The Data Table


I’ll sound like a broken record again, when you have a good design with one aspect of a project, you can likely take that and run with it for many other areas. In a following post I will detail this systems engineering aspect to nearly everything we touch.

Obviously the key inclusion into the table is the budget units and %’s. I still prefer these tables views vs the GANTT views. Having clear visibility into the last month dates, the prior month dates,  and variances is the purpose of this view.

The Future

Again, the extension of this are endless. At this stage, we are starting to see how pre filtered views provide more focused dashboard as compared to a one size fits all. Sitting in an EPCM world, most of the detailed activities and schedules are managed by our contractors. Thus, this construction view is more suited to using an export from a contractor Level 4 schedule.

At some point, we will need to begin to discuss an overarching design where a user can navigate to our various dashboard in a logic way.

Happy data wrangling!