NASA Apollo Cost Tracker

Quick how to guide on building my NASA cost tracker.

To follow up a recent video showcasing the NASA Apollo Costs, I wanted to illustrate how easy it is to use PowerBI to generate quick program of works dashboard. If you have several projects following a pipeline of work, some features here might spur some discussions or thoughts on what is possible.

The Data

I have sourced data from a google drive folder

NASA COSTS

However, like most data you find, the format is not suited to analytics. So a little manipulation was in order. Firstly, I had to create a WBS structure.  Typically, information we find is buried under headers, however for databases, we need to turn group headings into a column data field.

We can see I have inserted a 3 layer WBS structure, plus a company name field. This will allow me the flexibility to add subsequent data to this file from perhaps multiple companies, not just NASA. Again, when you build flexible data structures, the way you can use the structure is much more powerful

I know that I also want more contextual information displayed on the dashboard beyond simple data. Specifically, I want a description blurb to be viewable on a tool tip, along with a picture. Additionally, I want to display the leading contractor as well. Therefore, I added a few columns to the excel file. When you import the data into PowerBI, the URL needs to be set as a special format of “Image URL”. Took for some time to find that setting: its under “data category” on the column tools tab.

At some point, I will hopefully build out this dataset to include subsequent NASA budgets, and also publish this data through an API that everyone can access. However, there are limitation to what I can do and what I want to do typically far outstrips my abilities.

The Dashboard

Importing the data is quite straight forward, we do need our usual “unpivot” trick to convert the year information (which is contained inside columns) into row based data. However once that is done, lets look the various parts of the dashboard.

Before I jump into the various aspects of the dashboard, what really gives a dashboard a little polish is the use of a background image. Here is my go to ground image. Just a little playing around with Paint can produce something very valuable to your end product.

The dashboard utilizes 3 slicers. Each has a slightly different formatting. I definitely recommend playing around with the formatting of your slicers

The TREEMAP is where I have put a little extra bit of attention

What pops out here is the tooltip. I have created a separate page just for this tooltip. I am by no means an expert in designing tooltip, but know the power of inserting extra dimensions of data that again allows your dashboard to pop. This specific tooltip includes the blurb, an image URL and the main contractors. This information would be too dense for the overall dashboard and perhaps not dense enough for its own dash, therefore a tooltip is a perfect medium between.

The final element of the dashboard is the line graph and histogram. I still find creating line graphs difficult and in this case I had to add a measure to my data. I think there is a much easier way to achieve rolling sum data, but in my case, the below measure works easy enough for me.

CTD_line = CALCULATE(SUM(NASA_Budgets[Value]),filter(ALLSELECTED(NASA_Budgets),NASA_Budgets[Year]<=MAX(NASA_Budgets[Year])))

And with that, we have our completed dashboard

Extensions

There is a lot I can do with this framework now. We have a cost file that is quite generic and a dashboard that is also generic. We can in theory use this to outline any type of project pipeline. Although this dashboard is looking in the past, we can also have a rolling wave where we can see past spend on specific projects and what our future pipeline of work looks like. I love seeing project pipelines and following my NASA theme for the moment, here is a great view of what the NASA project pipeline looked like in 1973

Integrated EPCM Management – Engineering Progress

How is an engineering deliverable list a bit of a misnomer? Find out of a web page with editable fields can streamline the tracking of progress on list items.

I am a firm believer in the use of a standard project website portal from which the project team at large can quickly access key data and metrics about the project. This is not meant to be confused with a project dashboard, or PowerBI visualization. This is simple html file linked to a database with key flat-file information. Using smart JavaScript code, it is also possible to EDIT some of the key information.

With everything, before we even begin, we want to focus on what core digital strategies we are trying to tackle. Again, the project website is just a tactical approach, underlying it are the more relevant strategic goals we want to operate under.

Digital Strategy – Make Information easy to access

Digital Strategy – Agile Construction Management

Digital Strategy – Allow people to EDIT key data

The features discussed in this blog can be seen showcased in the following video. This is not a pipe dream. This is a functional application.

The video can be viewed in a separate window at https://www.youtube.com/watch?v=0XNA9xJS2yY

The Data

The key data sources involved with engineering progress will be:

  • Engineering Deliverable List
  • Manhours per WBS

Your engineering deliverable list is a bit of a misnomer. A lot of engineering and design tasks are not specifically related to a “deliverable.” In my view of the world, while you will have specific deliverables and need to track them, your progress list should also include everything else you are doing too – up to a point where perhaps the level of detail is too small.

For analysis, productivity factors for engineering are critical. As such, this post would not be complete without a discussion and visibility into hours and productivity factors.

The Menu

Our menu follows many of the key functions of project controls. However this specific post will dive into the ENGINEERING section only.

If we expand our menu, we see various views into our data: by project, discipline, contracts, schedule IDs and a unique view for controls engineering

Detail Views / EDIT MODE

Perhaps before we look at our summary and drill downs, the main control screen we would use on a day to day basis would be the Deliverables by WBS and Discipline

In the below screen, we can see all out progress items, our budget hours, progress% as well as the mapping to P6 ID (as all progress items should be mapped to into your schedule)

This view into deliverables by itself is not specifically unique. Where the magic happens is when we enter EDIT MODE.

Inside our EDIT MODE, we can directly update the progress %, and update our mapping to schedule ID. These features in my mind are your killer features that distinguish this from any other app. The shear ease in updating items in this way is a breath of fresh air, not to mention the live feedback and visibility throughout your team.

JIRA

Each combination of WBS and Discipline can be mapped to a JIRA task. Obviously we know our WBS can be considered an EPIC. The power in using a tool such as JIRA is that we can now track more detailed L4/5 tasks using JIRA Subtasks. These are completely flexible to allow the user to manage their own tasks.

Additionally, the ability to embed commentary and status is a brilliant way to distribute and communicate key status and blockers if any.

 

Summary Pages

Now that we have seen how we will actually interact with a project website, we can now showcase the summary level reporting. Specifics of how you report can often times be better captured using an analytics platform like PowerBI; however, more often then not, simple summaries and metrics are what drive our business.

In the summary by project, we can easily see key metrics per project. Each project would have a link to allow us to drill into the details for each project

In the above, we are now looking at the individual functional delivery areas (disciplines) for our project. Again we can see key budgets, spent hours, progress and productivity measures too. By clicking each discipline, we further dive into our project by now looking into the detailed WBS elements for that Discipline

It is in this view that we can see detailed metrics per WBS/Discipline pair.

Understanding our Spent Hours from time sheets is a critical management function. As such, the SAP actuals here is a link that takes us to a screen where we can view the detailed weekly time sheet data to see who (and when) has book to this element.

Conclusion

In summary we started with some key strategic thinking and built out a tool that ticks a lot of boxes in the EPCM construction world.

More often then not, I am confronted with technology that “shows me” but doesn’t allow me to interact, edit, or collaborate. Everyone wants to solve the “one source of truth” however, information changes and is updated by people. That is the missing link in a lot of our data analytics. Look into the work processes that generate information in the first place. Look at what people need to better capture their raw information into a data format and platform that others can now use.

This approach to put management of engineering items to plain sight, with ease of access is just one approach. There are 100s of ways to approach this, but if you stick to core strategic ideals, you can’t go wrong.

Data Integration – Commissioning Test Sheets / P6

Digital Strategy is an enabler to allow you to tackle problems, however, unless you have a clear vision for the required data integration that follows, it doesn’t make a difference what your strategy is. What follows is a worked example that really dives into the heart of where your head needs to be in using the smart technologies that exist today

I’ve previously written some of my thoughts related to Data Integration and Digital Strategy, however, perhaps I haven’t made it absolutely clear what I mean.

Digital Strategy is an enabler to allow you to tackle problems, however, unless you have a clear vision for the required data integration that follows, it doesn’t make a difference what your strategy is. What follows is a worked example that really dives into the heart of where your head needs to be in using the smart technologies that exist today

I’ve created a companion video that allows you to see this in action. The focus to have a user managed data integration layer is just awesome in my mind and allows for a seamless integration experience for a major project.

Commissioning Test Sheets

Commissioning Systems View

Here is a typical commissioning report. We are looking into the projects key systems. We see the number of subsystems, number of tests and total completed for each system.

We can follow the link on system to view what will will be subsystems

Commissioning SubSystem View

In our subsystem view we are obviously looking a bit in dept, and as we can see, this is our Integration Level. Each Subsystem/Disc pair is linked to a P6 Schedule ID. This is integration. However, we really need to dive into this and understand the process. We have 3 groups

  • Project Controls
  • Commissioning
  • Construction

The commissioning team will be updating our commissioning database, usually by close interfaces with engineering to define all the tests. They will be the hands on users of the commissioning system.

The project controls team will own the schedule, and will be responsible for updating and maintaining the schedule.

The construction team will know the detailed sequencing and duration that would be required.

Obviously each team will have discussions related to schedule and scope, however, your commissioning database is likely NOT updated with P6 IDs. Additionally, and here is the rub, when things change and perhaps more detail is added to the schedule, what is the mechanism for those changes to filter into the schedule. And when the magnitude and status of actual commissioning work changes, what is the mechanism for that information to be visible to the project controls team (in an smart way)

In the above example, all commissioning activities are assigned to 1 schedule ID. This is quite common when schedules are initially developed as projects enter execution. However, when additional detail is needed, it becomes hard to ensure systems STAY INTEGRATED.

Updated Data Integration

SubSystem EDIT MODE

The biggest weakness I see in many data integration efforts is they do not incorporate the step above. They do not allow edit capabilities into the data integration layers of the project.

In our worked example, we want to update the mapping between subsystems to schedule ID. We have added detailed activities into our schedule (I have left that step off, but imagine you have updated your schedule with additional commissioning activities), but do not yet have that new schedule information available in our commissioning system.

Enter Edit Mode and the world is your oyster. In the above screen we can now update the schedule ID mapping for each subsystem.

Updating the mapping to ScheduleID

Now that we have updated our mapping between our SubSystem / Discipline pairs, we can exit our edit mode and now see what we are left with

Now this is what proper Data Integration is all about. We have empowered our users to be able to flexibly manage their schedule, their commissioning system tree and update the mapping between the 2. Not to mention having everything at the fingertips of everyone involved in the process.

Extensions – JIRA

When we talk about Digital Strategy, we want users to be engaged and empowered to communicate. In the examples above, hopefully it was hard not to notice the “Jira Task” link that was available on the pages. Each of the subsystem discipline pairs is a critical discussion topic and as such deserves a Jira task page. This allows the team to openly discuss requirements and status. Indicate blocking tasks and interfaces (both preceeding and after completion of the task) is vital information.

Again, we want our users empowered to manage and communicate information on the project. This example really blows down barriers that I have seen. It is my passion to push the boundaries in the way we execute project. It is my passion to engage people and extract their knowledge as best as possible. Never before has technologies been so readily available to achieve these ends and I am really looking forward to seeing our business embrace some of my passion.

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.