Eric:

My name is Eric and I’m joined today by Nate, ProjecTools’ channel manager. I’m very pleased to be joined by Mary Williams, the president of MSS project analytics. She is an expert at primavera integration and project management. We will be discussing how Data Silos and Spreadsheets hurt energy projects, but just to get started here today, I’m going to tell you just a little bit about ProjecTools real quick and then I will talk a little bit about MSS Project Analytics, and get into the content. ProjecTools was founded in 1994. It started out as a project management consulting company for oil and gas projects. They built an application to help manage these projects. Over time the application got bigger and deeper and became a pendulum product, which they launched as a staff application in 2000. The application is divine for oil and gas and capital construction projects. ProjecTools has headquarters outside of Houston, Texas.

Don’t let these small town roots fool you. ProjecTools has thousands of users from over 50 countries. Now let’s talk a little bit about project analytics. Mary, would you like to tell us a little bit about that.

Mary:

Yes, thank you. Good morning, folks and thank you for joining us this morning. My name is Mary Williams and I’m the president of MSS Projects Analytics. Our company is a privately owned business and we were founded in 1985. Our primary focus since our inception has been to provide project control solutions and education to clients in the AEC, oil and gas, and air, space, and defense industries. We actually specialize in planning and scheduling for oil and gas projects. MSS is headquartered in Houston, Texas with satellite offices in Tampa, Los Angeles, and Seattle. We are a ProjecTools partner. We’re an Oracle Primavera partner. We’re also a certified education provider for Oracle University.

Eric:

Perfect. Thank you, Mary. We are very proud to have MSS project analytics as a partner. Real quick, before we get to the meat and potato, Nate will you tell us a little bit about why we’re here.

Nathan:

Sure, thanks Eric. Morning folks, thanks for joining us. It doesn’t make a lot of sense in the beginning to try and address problems in capital instruction without and oil and gas products without establishing that there are problems in capital instruction and oil and gas products. You can see here, this data is not provided by us. We did not come up with this data. This is not a wild guess. This is the a couple years of survey and research compiled by IPA which is a third party project analytics company. You can see here the issues that they found. These are median and mean, meaning that this is compilation data and this is what it averaged out to. This is not a one-off situation. This is across the board. You’ll see 15% cost deviation, 18% scheduled deviation, totaling to 55-75 million dollars in work scope and delay. The issues can be significant. This isn’t necessarily a statement about the oil and gas industry as a whole, it’s more a statement or a nod to the complexity of these projects.

Eric:

All right, thanks Nate. Jumping right in, the first part is talking about spreadsheets, and we’ll get to silos in a second. Nate, you’re very knowledgeable about spreadsheets. You’ve done all the research. Will you take us through the spreadsheet portion?

Nathan:

Sure, sure. The thing about spreadsheets is, first of all, they’re ubiquitous, everyone uses them. We acknowledge that. Even here inside of ProjecTools for some things. Where we believe that the line should be drawn is that you can’t use spreadsheets to manage very large and complex things. Where lots of money, lots of people depend on. Excel is a very powerful tool. We all agree and we all acknowledge that. Here at ProjecTools we use Excel. Here at ProjecTools we’ve made mistakes with Excel. Equally importantly all of our clients use Excel or did use Excel before switching to ProjecTools. It’s almost across the board that we talk to our clients and say hey what were you using before ProjecTools. It will be some combination of disparate systems that update, always including Excel. There are some issues with Excel. If you do a simple Google search with this, the Google machine will tell you that there are standards that there are many, many cases and many news reports about Excel costing companies millions and even billions of dollars.

The problems with spreadsheets as a whole can be boiled down to the fact they’re a stand alone system. They don’t encourage collaboration. 88% of spreadsheets actually contain errors. 1% of formula cells contain errors. The last two here are kind of interesting. Don’t mess with my spreadsheet is something that we hear internally and we’re sure that everyone else here has heard it too, and them as well. What that means is someone spent an inordinate amount of time creating a very complex spreadsheet that is no doubt very powerful. They need to share that data and get input from other project teams and things like that. They send that, maybe they send that Excel spreadsheet in an email and someone opens it up. In that email, there’s also hey don’t change anything in here, because even one transcription error or small change in the spreadsheets can effectively wipe out the whole thing. The last one is, I think the buzz word around is corporate data loss, or memory loss. Effectively what it is is, let’s use Bob for an example here. Bob creates this spreadsheet. It’s complex. It’s very powerful.

It manages a lot of things and many other project teams or kind of other project data is tied into that particular spreadsheet. Bob goes on vacation to the Bahamas. He’s unreachable for a couple of weeks and we all need access to the data inside the spreadsheet, but none of us really knows where to find that data and how to get a hold of it. Or, even worse, Bob takes another job somewhere, so then he’s completely off the grid. We’re unable to contact him and with him goes that knowledge that we need to operate that spreadsheet. Getting into a couple of actual examples, we’re going to use some fairly high profile examples. There are many, many others out there. In 2013, Forbes had an article titled Microsoft Excel Might Be The Most Dangerous Software on the Planet. That’s kind of a bold claim, but they do a pretty good job backing it up. In this particular case, the case study that they used is Excel was being used to move billions of dollars in JP Morgan. There was a very simple transcription error. That error cost them and JP Morgan several billions of dollars.

Obviously, all their stakeholders suffered as well. People working in the company suffered. It actually impacted the financial market, the entire financial market. Equally interesting is this quote that we pulled out of there, a collection integrated automated software would have avoided it. The implication there is that Excel was actually at fault. Human error is a given. It’s going to happen and so you should do everything in your power to avoid that. Another example is a company called Red Envelope. They’re an ecommerce platform and when they were hoarding financial metrics, they were using Excel to do so. There was one wrong number in one cell and that error made the stock lose a quarter of its value in a single day. There was a human cost to this. The CFO resigned immediately. All of this once again could have been avoided using integrated automated software rather than spreadsheets. If we haven’t convinced you that spreadsheets are dangerous, that’s fine. We encourage you to do your own research on that. Even in 1999 which seems like a very long time ago, 15 years ago, there was an entire conference founded upon the risks of Excel.

In that there’s a mint amount of research on that, on that particular website. I encourage you to go look around. One of the things that really came across was that 50% of the executives that they surveyed have actually dismissed that due to spreadsheet errors. There’s a significant human cost associated with the spreadsheet errors which is something that doesn’t get reported all the time. They also break down what their buckets are in terms of what the causes of spreadsheets are. Human error obviously being a big one. Fraud, over competence, interpretation, and archiving. The fraud one isn’t one that we really talk about that much or we hadn’t really thought of. Over competence kind of falls in that same category.

Eric:

Thanks, Nate. That was a pretty categorical explanation of why you shouldn’t be using spreadsheets to manage your energy projects. Because it’s just too complex and too sensitive. The next part of the presentation is we’re going to talk about data silos. First thing is what is a data silo. Data silo is a stockpile of information held by a department team or person. It’s information that can’t be accessed by other teams or departments, so it’s in silo. I saw some information that doesn’t interact with complimenting information from other teams. A good example of this is the project document don’t interact with the procurement department and that link between the data doesn’t seem like it involves much emails, maybe even a paper file, which isn’t the way to go. Moving on a little bit, why are data silos harmful? Why are we talking about them? If information’s been siloed, teams don’t have access to other team’s information. They probably shouldn’t have access to all the other team’s information, but some information can lead to better decisions. If you’re not making informed decisions based on the whole data set for the project, you’re probably making misinformed decisions.

There’s also a contextual issue. When data is in silos and then it gets shared around, the teams that didn’t build that information, they don’t know how it’s built so when they finally get their hands on it they might interpret that data differently or not know what it means and that can lead to issues as well. Another issue is redundant effort. If Nate and his team are working on a project that affects my area and I’m expected to produce the results for this project or the purple part of it and I don’t have access to what he’s doing, I might be doing the same thing. That’s redundant effort. It’s a waste of time, a waste of money and time that would be better spent working together. Then you also get into reformatting when it comes to sharing information that’s in silos. If Nate sends something to me and I need to use some of his data, it’s probably not going to be in a useful format for me. I have to go and reformat that and that takes time and effort kind of sucks that we’re doing that.

Then when information from silos you also encounter visibility and accountability issues. By the nature of having integrated information, a lot of that accountability, visibility, takes care of itself because everybody can see, at least aspects of other team’s and other department’s data. What is the opposite of a data silo because we’ve established that that’s not bad. The answer is integrated. Integrated data and integrated team. The definition of integrated is having different parts working together as a unit. When these information silos are connected, they’re no longer silos, they’re a unit. Integrated also means that allowing all types of people to participate or be included. Once you have an integrated team and integrated data, the data doesn’t have to flow completely freely. I don’t need access to everything Nate’s doing. I just might need to see a little piece of it that pertains to me. Your integration should be thoughtful, not wide open. Now that we’ve covered that a little bit, Mary, who clearly rose as an expert on integration, will you tell us the reasons to integrate.

Mary:

Yes, thanks Eric. As we noticed in the previous slides, Nate and Eric did a great job outlining the risks involved with managing project data in multiple non-integrated silos. When we as a project team don’t have access to one centralized integrated set of project data to be used for decision making we don’t have any basis for holding anyone accountable for any project deviations. Since we have no established reliable centralized source of project data, we are also unable to really determine the health of our project. The results will be cost overruns, schedule delays, and ultimately liquidated damages. Now, the data on the slide that we’re doing at this moment is provided by IPA. It illustrates that projects managed in an integrated environment experience significantly less deviation in cost growth and schedule slippage than projects managed in a non-integrated environment. This data suggests that projects managed with integrated data experience less than 10% deviation in cross growth and schedule slippage versus non-integrated projects. In other words, project teams using integrated data are able to make better, more informed decisions and are better able to predict the ultimate outcome of their projects.

One of the most strategic areas of integration involve integrating the procurement and scheduling process. Now, we all know that procurement, or contracts, and those requirements affect the cost, schedule, and resource plans and that the results of the procurement process actually become inputs into the planning, scheduling, estimating, and budgeting processes. One error in the procurement process has a domino effect on all of those other phases of the project plan. When you couple that with a lack of communication existing because we’re operating in separate silos, it makes the situation even worse. When we have access to an integrated environment, we actually can benefit by having real time, accurate and reliable data. That data enables everyone to make decisions because it’s the same centralized set of data. Our data integrity is improved because we are removing all of the human intervention required to keep these systems standing up together. We’re able to lower our project costs and improve our project efficiency. I’m not going to cite two examples that we’ve experienced at MSS with several of our clients. The first is going to be a discussion where we integrated an estimating tool with a primavera p6 schedule.

Our client was required to produce a cost voted schedule and submit that schedule to the stakeholder. You all have probably had to do that at some point or another. Not only did they have to load that schedule and submit it to the stakeholder, but that schedule was then going to be used as a basis for billing that stakeholder and ultimately being paid. Our client needed to replace our existing manual method of transferring data form their estimating tool to the P6 schedule. We helped them to integrate their estimating tool with primavera. As a result, they significantly reduced the time to load the schedule with all of that cost information. They improved the accuracy of the data and the reporting to the stakeholder and were therefore able to bill and get paid more expeditiously. It also enabled them to respond to any changes in the scope of the project much more quickly. The second example that I’d like to cite is for an oil and gas client that we helped integrate their procurement and scheduling process. The problem that this client encountered is that their contract award and delivery dates were not accurately updated on the schedule.

Once again, due to the fact that they were being manually transferred. This caused delays to important schedule milestones, to deliverables, and to the overall project schedule. More importantly, the stakeholder lost confidence in the schedule. We assisted them with integrating that procurement process with the schedule. Afterwards the schedule obviously more accurately reflected those procurement dates, allowing the client to deliver the project on time and avoid liquidated damages. Additionally, they were able to establish much better communication with the stakeholder of the project. An added benefit is it even improved the process of integrating those two systems. Improved communication within their own organization.

Eric:

Thank you, Mary. Now we’re going to talk about the solutions here. Nate, will you take us through that?

Nathan:

Sure. Thanks Eric. Your solution to many of these problems can be boiled down to integration. As we saw in the data sets from IPA, having an integrated projects, having integrated teams is crucial. In fact, when we talk to many of our clients we ask them things like hey what’s the definition of project success. Typically in the cost and scheduling department it means less than 10% cost growth and less than 10% schedule slips. According to the data we saw bacK there in IPA, simply put, the difference between successful and unsuccessful projects is integrating those teams and those departments. The solution is use software that encourages that. Use software that encourages people to work together, different departments to work together, and centralizes that data so it’s always up to date. Use software that also integrates the project stakeholders, not just your project teams, your third parties, your contractors, and your suppliers. You don’t want them to have access to all of the data inside your system. You want them to have access to the right data based upon rule based access.

What we mean by that is that a supplier should only see what a supplier should see within the system. You want to use the software that encourages that. Moving your systems online to empower departments with real time data without sacrificing economy. What we mean there is that we want to have all of the latest data in one place where people can access it through their web browser having an on premise system doesn’t make sense anymore when you have offices in multiple places, when you have contracts and suppliers all over the world. You also quit using email spreadsheets, share folders, file structures, and stand alone systems to manage your projects. The truth is – those can work for smaller projects, but they dramatically inhibit your ability to react to change, your ability to make good decisions. It has been proven to hurt both cost and scheduling. A lot of people say well how does ProjecTools do this. The answer is – that we have broken our product into four separate modules based upon kind of a combination of job rule and a project team mentality. It all integrates to the same central data set.

ProjecTools is a centralized database with each one of these four modules built into it operating on the same data. It’s entirely integrated, and integrated in a way that most software systems can’t be in that ProjecTools was actually built together and built to work together. They can be deployed individually or as a single unit. That integration is inherent within the ProjecTools application. We talked a little bit about online access. Let’s talk about what that really means. You want to have that centralized data set and you want to have it somewhere where people can access it in real time from anywhere in the world at any time. If you have somebody working on one area of the project from Louisiana, one area of the project in Texas, and another area of the project in Singapore, which is actually what some of our clients do, the ability to have that data just a couple of mouse clicks away is incredibly important. It also allows your third parties, your contractors, suppliers, and owners to have a very simple point of access to the right project data.

Once again, you don’t share everything across the board, but you do give them rule based access to that data.

Eric:

Thanks, Nate. Mary, having covered all of that, what does this all mean to us?

Mary:

Okay, thanks Eric. Well let’s recap what we’ve learned this morning. First of all, we’ve learned that integrated teams in conjunction with integrated software will give you a competitive advantage particularly on large complex projects and that managing those large projects with spreadsheets, emails, stand alone systems, is a distinct disadvantage. The right software, such as ProjecTools, combined with online accessibility facilitates integration of the software as well as our project teams. The next question is well okay, how do we get there? How do we actually get to the point where we are integrated? Obviously the first step is that we need to identify what the critical integration points are through our project life cycle. We need to take into consideration the schedule, document control, cost control, procurement, commissioning. The next step is to identify which data sets that we want to integrate. The example on the slide is that we want to integrate accounting data with cost control data. Other examples are integrate the procurement process with the schedule or integrate the estimate with the schedule. Always take into consideration what future needs you might need to take into account.

What types of projects are you planning to seek in the future? Once you’ve established what you want to do, the next step is to get it done. Develop your implementation plan. The first step in the process is to clearly identify and explain your business need and objectives. Next, figure out which resources you need to get it done. You’ll have some internal resources and you’ll probably want to use some external resources such as ProjecTools and MSS as we do that every day. Try it on for size. Request a free trial of ProjecTools. We’ll help you get it set up. It’s important to put the proper planning into this implementation plan so that you’re doing it right the first time. In conclusion then, we all know software is powerful, but integrated software is more powerful. Don’t overlook the fact that through integrating your software systems you also have the opportunity to integrate your various project teams and improve the communication process. Seek support from outside resources. Use your own IT department. Decision makers in your organization, third party experts, and don’t forget that end users are a very valuable resource as well.

Develop your implementation plan, execute it, and evaluate it. Remember that it’s a competitive advantage. Hopefully you’ve been able to see that throughout the course of the morning in our discussion. It’s a competitive advantage to move toward integrated systems and integrated teams.

Nathan:

We’re going to take a minute here and just wrap up and do one final overview on what ProjecTools does. This is a common question at the end of our webinars here. ProjecTools is a single, centralized, online, cloud based, backed up, secure database that has four separate modules that can be deployed independently or together to create either one aspect of the project team’s database or to serve as an entirely integrated project management sweep. We integrate with a variety of third party applications. Primavera, for scheduling, is a very common one. Other common ones include accounting and many of our clients come to us with that question. It’s typically Microsoft Dynamics SL. There are a variety of other things that we can integrate to. We’ve had document integrations with other things like Documentum and things like that. We go through the entire concept of the ProjecTools application is to have a single set of accurate data that can be accessed in real time and to have that integrated, to move and flow smoothly between project departments. If you want to see more, the thing to do, we encourage you to go to MSSProjectsAnalytics.com.

They have an excellent website. You can click on the products tab. Click on ProjecTools and there’s a form below it to get you set up with a free trial. They can answer questions. They will get a little bit more data from you and we can spin up an essence of ProjecTools and deliver that to you so you can try it before you buy it.

Eric:

Cool, thank you Nate. A free trial doesn’t sound like what you’re after, I encourage you to contact MSS Project Analytics directly. AJ Williams is the guy to contact there. His number here is on the side, along with his email address. Feel free to take a screenshot if that interests you. The next thing we have is questions, but before we get into this, I want to thank Mary for joining us today. It was a pleasure having you on the call and we appreciate your insight.

Mary:

Thank you very much, it was a pleasure to work with you.

Eric:

Thank you. First question, how do you integrate primavera with ProjecTools. Mary, since you’re the expert here, will you answer that one for us?

Mary:

Sure. I’d be happy to. All integrations take a different flavor. It’s difficult to describe one particular integration. What I would like to say is because integrations are different, our typical process is to have a thorough needs analysis with each client where we determine what their specific integration requirement is. Then we proceed to develop that. If anyone has any questions about that, please feel free to reach out to us and we can discuss it further.

Eric:

Thank you. The next question is, is ProjecTools integrated with accounting. I’ll take that one. Short answer is yes. Many clients of ProjecTools have integrated their accounting systems with ProjecTools cloud control. How that generally works to the actual financial data gets pushed to ProjecTools. The relevant data, commitments and so forth gets pushed to the accounting system. That’s cool because it eliminates a lot of the interface between cop controllers and accounting. Cop controllers help control the project on schedule and accounting do whatever accounting does. The next question is what does an implementation look like? Mary, do you mind answering this one for us.

Mary:

Once again, implementation times can vary based on the needs of the client and the software that they’re trying to deploy. I’ll give a range. First of all, some of the clients that we work with already have resources on their staff that have used ProjecTools in previous positions. In that kind of a scenario, you could literally deploy ProjecTools in a day. Other more complex systems where the client is purchasing document control, cost procurement, and commissioning will require a little bit longer implementation time. Let’s just say a week or two. The important thing to remember is that the Project Tool staff along with our staff at MSS will help you go through the implementation, help you set up numbering, structures, work flows, permissions, and then actually help you load your data so that you’re off and running as quickly as possible.

Eric:

Perfect, thank you. Last one I have here is, kind of around cough. Nate, we talked about the pricing ProjecTools.

Nathan:

Sure. One of the areas that ProjecTools differs pretty significantly from many other similar applications is that ProjecTools is a stacked application which stands for software of service. That is a subscription fee for access to the system. We managed all of the technicalities on our side. We keep the severs up. We keep all your data secure. We do everything along that. We employ the staff that are experts in those areas so that you don’t have to do that. We procure all the hard work. What this means is, it’s very, very cost effective to get into. In fact, I was at my client’s to prepare the two different cost scenarios for ProjecTools, one being and on premise application and another being SAS application. The difference for the first year was about six times the cost the ProjecTools staff application. Then for the maintenance of the hardware alone, it was about 2 or 3 times the cost of ProjecTools. Fact application. Every year. The answer is, it’s very very horrible for a company to get into ProjecTools at that level. If you want to get more information, we encourage you to go to ProjecTools.com/get-started.

Eric:

Thanks. Just to add a little bit, more than cows. I mean with the SAS act you can get more benefits when they fax us. Especially when you have global things.

Nathan:

It helps to Mary’s point there when we can deploy a couple days as opposed to what the alternative is for an on premises application, where you end up having to wait a couple of weeks to buy the hardware. The hardware comes in. You have to hire some specialists to set up the hardware. Then you have to actually deploy all the software systems to on the hardware in order to support our software. It dramatically decreases the implementation of costs as well.

Eric:

I mean, I’m sure we’ve all heard the horror stories of implementing things on premis systems, implementation and installation of the last big month or even years.

Nathan:

Years. Certainly years. That just doesn’t happen. Plain old, that’s not happening at a Project Tool level. All right.

Eric:

It looks like that is the end of our questions and I appreciate all of you guys joining us today. Thank you very much. We will have another webinar next month. I don’t know exactly what the topic’s going to be, but I will send an email and let you know. Thank you guys for carving out some time out of your Wednesday and joining us.