At Pinnacle, we strive to stay abreast of the latest and greatest software tools used in project management. As a partner with many industry-leading tool vendors it is incumbent upon us to know the available tools and how to use them to solve obstacles facing our clients.
I recently sat down with Brian Leach, Founder and CEO of Steelray Software, to see what his team has been up to and I was excited to hear that they have two new products, both designed to work with Oracle Primavera P6. In part one of our interview, Brian and I dive into schedule delays.
Jason: Hi Brian. To get started, I'll ask how the Steelray team has been doing over the last year and a half. Is everyone hanging in there?
Brian: Yes, I'm happy to say that we are. In March last year, we closed our office, and all worked from home, which we'd been doing on Fridays anyway. We reopened the office back in July but just go in on Tuesdays and Thursdays these days.
Jason: And what has Steelray the company been up to?
Brian: We've been heads down, working on two new technologies which are on their way to becoming products, and they both work with Primavera P6.
Jason: Tell me a little bit about them.
Brian: Well, the first project has been something we started working on back in 2018, about three years ago. Back in the days when we could go to conferences, I attended the PM College of Scheduling in Vancouver, British Columbia. I came home with the idea for this first project. I'd asked dozens of attendees to describe the parts of their job that they thought were most difficult or time-consuming, and I got an earful about schedule comparison and delay analysis and understanding the causes of delays. Some of the people I spoke with use Claim Digger, which Oracle renamed to the Schedule Comparison tool in Primavera P6's Visualizer. Others use Acumen Fuse, Ron Winter's Schedule Analyzer, or our Project Analyzer. All of these tools save you time but still leave you with a lot of detective work to do. They all go only so far.
Jason: Right, they still give you a huge amount of information to sift through.
Brian: They do, and even with those tools it takes the schedule analyst days to do a proper delay analysis and show exactly which changes moved the finish milestone. The common method is to conduct a windows analysis, where you apply each change, one by one, recalculate the schedule, and watch the impact on the finish. You figure out which changes actually mattered in pushing the end date.
Jason: You also must deal with parallel changes where multiple changes move the date, correct?
Brian: Yes, and sneaky changes like calendar changes, lag changes, changes to the logic. I remember thinking at the time, "Why has nobody done this yet in their schedule analysis tools? Why haven't we?"
Jason: So why hasn't anyone done this?
Brian: Okay, so three years later I know -- it's really [%$^%&$] hard!
Jason: Can't print that.
Brian: I know, sorry. So, what I thought would be about six months of work has turned into three years. We had to figure out some huge problems, but the feedback from early users is giving us cause to be excited. I think we've got it.
Jason: So how to you figure out things like parallel changes that both cause delays?
Brian: We break things down into much smaller time windows, essentially applying a fraction of each change minute-by-minute, simulating them happening in parallel.
Jason: I'm guessing that performance was a bit of a challenge?
Brian: A big issue, but we've got it to the point where we can process 30 schedule updates of a 1,000 activity schedule in just a few seconds. The current set we're working on is even more massive, and we've got that down from minutes to seconds.
Jason: Sounds like you built a really fast scheduling engine.
Brian: Yes, heavily optimized, but also using parallel processing - your laptop has four to eight cores, or processors, and we'll use all of them. On a good laptop, you're comparing eight schedule periods at the same time.
Jason: What type of report do I get when it finishes the analysis?
Brian: We've created three interactive report views: a more traditional delay analysis table where you see what changed but across a timeline, a network diagram with annotated changes for each comparison period, and a really cool Gantt view where you can drag the data date and see the Gantt change in real time, hour by hour if you want.
Jason: This sounds like an amazing product, built on the latest technology, does it have a name?
Brian: Steelray Delay Analyzer.
Jason: When do you expect Steelray Delay Analyzer to be released?
Brian: Great question. Best answer: when our early access users tell us it's ready. We have companies using early copies who perform delay analysis the time-consuming way, and they're comparing our results with theirs. It's not quite ready yet, but they're interested enough to spend the time helping us test it. When they tell us it's ready, it's ready.
Jason: Part of the DNA at Steelray is listening to your customers and it sounds like you have a great product that I’m sure the planning and scheduling community will be excited to get their hands on.
For more information visit steelray.com to see their entire product portfolio.
