Implementing PPM for a Department of Transportation

My name is Diane East and I'm a DOT project manager, and I work for Xriver Technologies. Could you please describe your company? (0:12 to 0:38) Xriver is a small, integration systems company since 1984 and they've been building different kinds of project management systems. Some of them have been outside-the-box and some of them have been out-of-the-box. We've been a Planisware partner since 1999 when they first came to the United States and we're basically working on our second DOT, but we've also worked in pharma and a number of different industries doing Planisware implementations, so that's the role we function in. Please summarize your DOT experience. (0:40 to 01:08) Over the past 22 years, I've worked with 10 different DOTs in the process of either planning, implementing or post-implementation support of project management systems. For the Michigan DOT implementation, I was the project manager. And I worked with it from the very beginning with kickoff. We did extensive requirements, I worked through the system testing, user testing and training aspect, and now I'm currently supporting the post-implementation. What are the key challenges specific to DOT implementations? (01:10 to 02:12) One of the key discriminators between DOTs and R&D is their complex capital funding of projects, where they have specific funds that must be used within a period and, if they're not, then they lose the funding. So, what they have is a constantly changing program of projects ... Also, DOTs today are being asked to scrutinize their funding much more than what they have in the past. They're working with an aging infrastructure of roads and there are a lot of roads that are deteriorating. They're having to do more with less. And if you couple that with an ever-changing portfolio, their detail-to-schedule and have to focus on whether or not they can complete projects on time -- it's extremely important and costly for them. So, there are … another impact with DOTs is that they're working with very much old-school networks, so change management becomes a very integral part of putting in an implementation in the state government arena. The users tend to be change-resistant, so, it's a struggle to do that. It's a very important element to take into account. What is unique about DOT projects? (02:16 to 03:08) So, the thing about DOT projects is that they're very lengthy. They can range anywhere from a few months or a year to up to 20 years. DOT projects start with the identification of a need, for instance, there's too many accidents happening on a certain section of road to, ok, what can we do about that, what are the different options or alternatives we might consider in order to reduce the accidents there. And then it branches into well, who can we get to pay for that? Do we use federal, state, local funds? After all of that is settled and it gets programmed, then we start doing things like designing what will actually take place, taking the site into consideration so they can figure out if they just need to put an overlay and change the ramp on the road or whether they need to completely reconstruct the road bed. There are a lot of different variations, but it takes many years to get to the point where the design is then complete and it can then be awarded for construction. How do these challenges impact a DOT PPM implementation? (03:10 to 03:46) Some of the things that affect DOT is because they're overly structured is that they also tend to over-automate. So, the configuration can be a struggle when they want to keep these structures and systems in place. So, that and the resistance to change makes it a very difficult environment to implement. So, along with change resistance, the flexibility becomes limited and what that does in state government and DOT organizations is it tends to drive the information into data silos, which are also not integrated. The users are simply scrambling to get their job done. So, there's a lot of homegrown systems that come up in DOTs that we have to take into account as we bring in an application that may or may not replace those. Why was Planisware best-suited to meet Michigan DOT's needs? (03:48 to 04:45) Michigan had a completely customized system and I think that in almost all of the DOTs that I've touched, they've really -- at least in the past -- have had completely customized systems. But the trend in the industry is, in fact, to go to a COTs product that can be easily configured. So, they wanted to go that way, to do a COTs product. They wanted basic project management functionality, which is available in Planisware, plus a whole lot more. Plus, they wanted a tool they could grow with. But one of the things they had in their existing system was a network generator. They literally had the ability to produce project schedules so that they could take a project and simply tell you a few facts about that project, the characteristics of it, and put it through their network generator and generate those schedules that need to be out the door. So, when they looked at Planisware, being able to do that through the equations function, which is out-of-the-box in Planisware, really helped them with the amount of configuration they needed to do in order to repeat that functionality. How did XRiver approach the Michigan DOT implementation? (04:50 to 06:48) With the Michigan DOT implementation, we basically had the whole project funded, but we divided it into two different tasks. We did a requirements phase and through that requirements phase, we went through their matrix and we determined what would be out-of-the-box and what would be configuration. At the conclusion of requirements, we basically put out a statement of work for the development. So, we kind of had a division between the two. So, although it was all funded at once, we didn't have a scope of work until after we had done requirements and I think that was very useful to be able to sit down, rather than going blind straight from the RFP into a development mode. Taking the time to decide what was going to be configured and what wasn't going to be configured was really important. It ended up resulting in Michigan having a little bit of extra money left over because we actually were bidding on a fixed-price task, but when you bid it at fixed-price, you have to allow yourself cushion. You have no idea what the client is going to ask for. So, once we knew what it was they were going to ask for, we were able to do it and, as a result of that, they had a piece of money left over for enhancements and also for extra support they could do at the end of it. So, that was very useful. There were a total of five sprints and after each sprint, we basically walked through the functionality of those to see whether it would meet the business case and this is where we had instances where we really needed to take a look at whether or not it was a design that was missed or whether it was a new, out-of-scope idea and, again, Greg came in very handy in helping us to balance those things. But we basically went through all five of the sprints and went straight into system testing, very robust system testing. We did two weeks worth of user testing and then we rolled forward through our training and implementation. Over the next several months, we dealt with the delay on the Michigan side. They wanted to interface with another system and that system wasn't going to roll out for three months later, so what we did is we took that three months and we poured it into our training materials and into our change management aspect, and it ended up having a very positive impact on the overall implementation. How has Planisware benefitted Michigan DOT? (06:52 to 08:01) Users are making updates much more frequently than they used to because of the transparency in the system. They also have … through configuration they've automated getting their projects approved. There is another source that basically does the controlling of the programs and that's changed. It was not automated before Planisware came along. I can tell you that the PMO office is a lot happier with not being onslaught with massive updates all at once. They're basically being able to see things that they need to look at any week of the month, not just the one week a month that they happen to have the data in. So, that's been very helpful to the PMO office. Project schedule generation works pretty much as it did before in the system, thanks to the robust rules that they had available in that. Every week, things are getting a little bit stronger. Our implementation went live a few months ago and every week, I think they see that users are embracing it even more, although we had a very good response during our training. After going from a DOS-based system into Planisware, it was like going from a horse cart to a race car. It was just a very big transition for them, but it was a very positive response.