Mac Lister: Thanks very much, Mike. And thanks really, to all of our presenters for doing a nice job of talking about this issue. With that, I think I will start through the questions here. We have several excellent questions.
Mac Lister: Q. Does the INCOSE systems engineering certification have application in cross training transportation engineers and systems engineers?
Mac Lister: I'm going to direct that one to you, Emiliano and see what your comments are. Mike and Amy, if you have thoughts, certainly join in also.
A. Emiliano Lopez: To be honest with you, Mac, and I know Frank's on the line, so I'm not going to over speak my boundaries. I'm not familiar enough with the INCOSE system engineering certification to make really a comment on this application and cross training of transportation engineers. I will make one note though. Many times I think it's optimistic thinking that we can take, whether they're a transportation engineer or a civil engineer and make them a system engineer. I say that from the perspective of in addition to being a system engineer, they're probably responsible for doing a bunch of other duties. When we talk about ITS and we talk about systems engineering, we are really talking holistically about an integrated approach of having people who are classically trained in system engineering to become part of the team that involves transportation engineers and planners so that they bring to the table their level of expertise.
Mac Lister: For those of you without a background, but it's an association for systems engineering, International Council of Systems Engineers. But they have standards and guidebooks and chapters in most cities. They actually provide a lot of excellent information on systems engineering. Amy and Mike, do you have any thoughts about INCOSE or is that even an issue for you?
Amy Tang McElwain: No, no comment on that.
Michael Stokes: Here in Mississippi, we've recently had some contact with the local INCOSE chapter and we're exploring the possibilities of joining that chapter. This particular chapter is heavily a Department of Defense chapter. But they have demonstrated a willingness and an openness to make it a very versatile chapter, as far as dealing with transportation. The point I'd like to make out too, is those members, at least in this chapter for us, the Department of Defense is a huge stakeholder in this state and generates a lot of traffic in this state. So they're also deploying systems and fiber communication lines and those kind of things. If nothing else, for building the relationship with possible ITS stakeholders, I think there's some benefit to participating in the local INCOSE chapters. My interest has been piqued about the systems engineering certification process, but I'm like Emiliano. I haven't really researched it enough to know whether I would recommend it or not. But we are going to look into it and see if that can't be a method of better training our staff in systems engineering.
Mac Lister: Q. The next question, I think Amy is specifically for you. Is VDOT NRO organized like other regions? How is statewide coordination managed?
A: Amy Tang McElwain: All five regions have organizational structure to cover all functions that we have, but not all are structured exactly the same. They would have one person probably take care of the two, for example. Most of them are still in the early stage for establishing their organization. We just had established organizationally for the five regions since last year. So it would still come at an early stage. But the five regional directors meet monthly. So they're able to share experiences and leverage each other's accomplishments. I had presented this process to them and they were very interested in moving toward the same process for their region as well. In terms of statewide coordination, central office of VDOT is recently just starting to develop a statewide operating concept in architecture. For years, we don't have that as a guiding formula for our architectural development. But since they're working on it, it will become a significant input in the framework for our plan update. The central office is also developing publishing annual fiscal strategic focus every year. That becomes the framework for our strategic focus as well. That is how we tie the annual focus together emphasis. A very recent development is just last month, some of the funding that we used to manage are now consolidated into statewide money. Therefore, we need to submit our projects for statewide prioritization and compete for money among regions, which is a very new development for us. It adds another complication to our programming process. But that's another example illustrating how we tie it back to the statewide effort in terms of from the programming perspective how we are going to be part of the statewide investment plan development.
Mac Lister: Q. Are you using any requirements management tools, such as DOORS, SLATE, or RECPRO?
Mac Lister: Let me direct that to the two states first and then Emiliano, you may have a comment also.
back to top
A: Amy Tang McElwain: My answer will be very quick. Not really. We're looking to them to see if maybe there is some way that we can adopt one of them or more.
Michael Stokes: That's the same answer we have in Mississippi
Mac Lister: Okay, great. Emiliano, do you have a comment?
Emiliano Lopez: I know we're right now taking a look at some of the different tools. I think the big question right now is the application of the tool, as far as project complexity. When do you use something? The tool itself, I think the point has been made within Federal Highways that awareness of the tool is one thing, but a tool that someone doesn't know how to use could be dangerous. There's a lot that still needs to be researched in this area, as far as requirements tracking as well as some of the other system engineering tools that will become available. It is definitely becoming a high priority for Federal Highways [inaudible] that information out there as well.
Mac Lister: Q. Do you have any warrants or guidelines that tell project designers which ITS elements might be justified in a given situation?
Mac Lister: I think that's for Amy and Mike.
A: Amy Tang McElwain: Okay, I'll start again. We are currently developing a decision tool we call Toolbox. It will be a web-based sort of knowledge library that would help people to identify given certain situations what kind of ITS elements they need to look into further. That's something that we're looking to developing such a tool so that we all could use it.
Michael Stokes: Here in Mississippi, we don't really have any tools that would determine that for us. We have just recently implemented where the ITS section here reviews all of the planned construction projects and then we label those construction projects as having ITS interest. Then, we come back and then the ITS section would develop what ITS components would be needed in that project. Then we would present that to the district, which would then sign off on it and put it into the planning and budgeting.
Mac Lister: Q. We have often found that we get better bid prices and contractor response from separate ITS contracts, rather than including ITS work into larger construction contracts. A road contractor with, for example, a $40 million road project does not always give high priority to the $1 million ITS portion. Do you have any experience with this area?
Amy Tang McElwain: Yes, certainly. I think that's probably a shared very common experience most of our ITS professionals face. However, I would also bring up there is some positive experience that we have had as well. A very high priced Walter Wilson Bridge replacement project actually does include ITS components from the very early conceptual phase all the way through the construction and implementation and operations. That is a huge project. I think it's a $100 million-ish kind of project. Don't quote me on that. It's very high priced roadway project that does actually include ITS as part of their project component. But the majority of our roadway projects, when we phase the ITS elements, when they actually consider there are ITS elements, sometimes they do prefer to have separate ITS contracts just for the ease of the management purpose.
Michael Stokes: Here in Mississippi, I think any type of technology or system that you can break out into a separate contract, you would probably get a better bid price. For example, if you could break out your signal installations, you'd probably get a better bid price from the road builder contractor or get a better price from the signal contractor. So, we have found that it's better to leave these ITS projects in these construction projects. That way, we're applying that technology to the road surface transportation. So if a design or change takes place in the building of the road or the freeway, then we know that it's automatically got to be affected to make a change to the ITS system. So we probably could get a cheaper price if we separated it out, but we're not guaranteed to get a cheaper price.
Michael Stokes: Here in Mississippi, I think any type of technology or system that you can break out into a separate contract, you would probably get a better bid price. For example, if you could break out your signal installations, you'd probably get a better bid price from the road builder contractor or get a better price from the signal contractor. So, we have found that it's better to leave these ITS projects in these construction projects. That way, we're applying that technology to the road surface transportation. So if a design or change takes place in the building of the road or the freeway, then we know that it's automatically got to be affected to make a change to the ITS system. So we probably could get a cheaper price if we separated it out, but we're not guaranteed to get a cheaper price.
Mac Lister: Thanks very much, Amy and Mike. Emiliano, before you became a Fed, do you have any experience with this? Do you have any comments?
Emiliano Lopez: Yeah. It's exactly what both of them said. The only way really to address-- I think what Mike said is actually more along the lines of what I've experienced. When you have someone who specializes in that, they can give you unit costs that are more in line, because you're both on the same wave length of what you're looking for there. What you typically get in the big contracts is that that is not their expertise, those smaller ITS projects. They usually use unit prices that are generic. Again, because of the uncertainty on their part when they're doing the bid development, there's I won't say a jacking up of price, but there definitely is an escalation of price, because of uncertainties. Possibly so, as is pointed out in the question, they don't know if they're going to be giving it the attention that they need to give it. So they build in quite a bit of overhead.
Michael Stokes: Well, the thing, too, is remember you do have to have it. This is one reason you need very good detailed specifications and testing procedures for these projects that are in large construction projects. But also remember that if that prime contractor jacks the price up too high, then he's going to risk losing the overall project. So I think we find that the more discussions that take place between the large road building contractors and maybe the smaller, more specialized subcontractors the better. There's a certain amount of education that needs to go toward the big road builder contractors. But I don't know that they're going to jack the price up too much or they're going to price themselves out of the bid.
Emiliano Lopez: I totally agree with you.
Mac Lister: I'm not sure how this question is directly linked to systems engineering, but we'll see if anybody has an answer for it.
Mac Lister: Q. What legal action could be taken against the contractor or the engineering firm the contractor hired that knowingly falsified tests on a project? Was the project federally funded?
Mac Lister: I'm not sure why the questioner is asking that last part of it. Maybe that means if the project was federally funded.
A. Emiliano Lopez: It sounds like that one's directed towards Mike and I'm guessing it was in reference to the fiber portion of the contract.
back to top
Michael Stokes: Yeah. It's not so much that we were looking for legal repercussions. It was our own oversight that allowed that to happen. I was just trying to point out the benefits of documentation through the systems engineering process to prevent that from happening in the future. That particular project, we would have had very little recourse, because we had already signed. We thought the project met and the project did meet the existing specifications. We had already closed out the project through a final inspection and accepted the project. By the time we realized and got ready to light that dark fiber and realized what had happened, we had already accepted the project as is and so there was probably very little legal recourse on that.
Emiliano Lopez: Yeah, Mike. I've also had a similar experience working on a fiber project in which it was the way we wrote up the specifications. We wrote light loss as one unit versus it being per connection, a minimum loss per connection. So the noise that was basically applied along the entire length of the fiber. What they did was they said "average." Because we wrote the specifications poorly, there were definitely some links that were very bad and we had no recourse on that as well.
Mac Lister: Amy, do you have any comments on this?
Amy Tang McElwain: No. I actually would like to learn about any legal action that could be taken. I'm sure every agency has a certain ramification if a contractor falsely tests a project. But I'm not really familiar with that.
Mac Lister: Q. How has the systems engineering process been incorporated and included into the MPO process?
Mac Lister: This is for both of you guys.
Amy Tang McElwain: A. From our agency, we are actually in two MPO regions. One's the Washington, D.C. Regional MPO. We actually have an architecture working group that is shared by Peter Meenehan, who is still in this conference call, to ensure consistencies among multiple architectures in our region. Our region consists of Maryland, the transit agency that Peter represents, D.C., Virginia, VDOT, and DC regional architectures. So that's probably at this point of the stage, that's where it ends at this point in terms of relating to systems engineering process. But I know that that group's goal is to move on to facilitating an implementation through the system engineering process. I'm also aware that Washington, D.C. Regional MPO, the TIP amendment or TIP form does have a Rule 940 Checklist as one of the checklists. It somehow is incorporated in that way. Another MPO that we're a part of is the Fredericksburg MPO, south of our Northern Virginia area. We just began establishing a working relationship with them. They have not, that I'm aware of, adopted any system engineering or architecture and so forth. We're still a work in progress with them.
Mac Lister: Mike, what's your relationship with MPOs?
Michael Stokes: We are having to educate the MPOs on the national ITS standards, the systems engineering processes. That's been a real challenge for us. We haven't been able to hit the ground running in that area. As we're developing the regional architectures, we are involving the MPOs. Some MPOs are more involved and more cooperative than others. We have a local planning guide that I mentioned that the MPOs follow when they're developing their local projects. We have modified that local planning guide to go ahead and refer to define what an ITS project is. We mentioned that it must follow the regional architectures. Then we also went ahead and referred to our Systems Engineering Management Plan. Even though the plan is not completed, we can't just overnight complete this plan. But as the sections and chapters are completed, then they will know to access this plan on the website or through me and if they have any questions, that refers them back to me on areas that might not have been completed in the plan yet. The main thing we found - of course our MPOs are not as large as some city MPOs in some of the other states. It's been a real challenge for us, a smaller state, to have to educate the MPOs before we could actually start working with them on these processes.
Mac Lister: The next one is a question and some opinion stated in the question. I'm thinking Emiliano is probably the best first answer on this and then others of you as you feel appropriate.
Mac Lister: Q. I do not understand the distinction being given to centralized versus decentralized organizational structure in your presentation when the discussion is SE process used in other states. I don't see any distinction. We're talking SE processes here, not organizational structure. Your next slides then show how you are indeed integrating your internal traditional and SE processes. This is no different than what California or Florida or Virginia have done. Lastly, the SE Handbook and the SE Guidebook speak nothing about organizational structure. They are guides to the use of SE processes, no matter how your organization is structured.
back to top
Mac Lister: The next one is a question and some opinion stated in the question. I'm thinking Emiliano is probably the best first answer on this and then others of you as you feel appropriate.
A. Michael Stokes: Mac, I think that's probably directed at my presentation. I don't mind fielding that question.
Mac Lister: Okay. I suspect there may be a Federal Highway comment on that as well, because it talks about the Handbook and the Guidebook. But go ahead and start.
Michael Stokes: He's correct. The Handbook and the Guidebook do not necessarily speak to organizational structure. It is about systems engineering processes. But today's presentation was not just about systems engineering processes in other states. It was about how Mississippi was going to apply systems engineering to our business model or our business plan. And a business model and a business plan are going to contain an organizational structure. It's just that you have to address it on a day-to-day operations. If we don't have enough staff to have out there in the districts, then we've got a very centralized ITS program here. We do all the ITS inspections of projects here. Whereas, other states will decentralize that and go and train numerous districts to do their own ITS inspections. Now these states, it works well for them. They have a lot more ITS projects than we do in our state. But we do not think it's economically feasible at this time for us to go to six or seven districts and number one, have the personnel in each district to handle it. Then have to perform the training of those personnel so that they can adequately carry out something as simple as inspections. That's the only point that I was trying to make. I am not slamming California or Florida at all. I think I gave them credit as being the premier programs. But they do not operate like a smaller, more rural state. There's several different SE processes. It doesn't mean that we have to follow exactly to the law how California did it or how Florida did it or how Virginia did it. Each state has to find the process that works best for them. If I just take their process and slap an MDOT logo on it and say that I have a process and I don't know what it says on the inside, then I haven't really done any good. There's been no benefit to the agency at all. That was my only point about a decentralized or a centralized organizational structure. Emiliano, I don't know if you have anything to add to that or not.
Emiliano Lopez: I think everything you said is right on, Mike. What we're not trying to say is system engineering is a one size fits all and that you need to do every little system engineering step to reduce risk. I think at this point in time in my presentation, baby steps is really my buzz word for the day. You've got to take a look a what your organization's willing to handle or swallow. When you find those pieces, that's what you build off of. You've already articulated to everyone that you are continuing to look at improving your system engineering process. To me, you've got your foot in the door and you've got foresight to know that's not the end of it. You need to get into the door and you need to do lots more once you get into the room. I totally agree with everything you said.
Mac Lister: Okay, great. Thanks you two. Amy, you had previously commented on the relationship of your district to other districts. Do you have anything to add to this question?
Amy Tang McElwain: No. I don't think I'm very qualified to answer this one.
Mac Lister: Okay. We have a rather long description with a good question at the end, so bear with me while I try and read this from a very small screen with very old eyes.
Mac Lister: Q. "When writing technical specifications, I try to cover each product and installation standard and requirement to include a step-by-step guide for the contractor to use, so that installation software and hardware requirements are left with little doubt or question. I had done this to reduce any and all risk to the agency, client, and contractor. However, I have found that instead of contractor bids going down in price, it appears that contractor bids have returned exceptionally high. On the inverse, when the specs are vague, it appears the bids are then received at more competitive and reasonable rates. However, like the example you gave about not having the fiber optic strands properly tested, poor testing and operability are the result. Is there a strategy recommendation on how a systems engineering team/firm can provide specs and drawings that will satisfy that the end result of the system will be a fully operable system, but also help to ensure that the returned bids will not be ludicrous and ensure the contractors will provide the required test results? At what point of the project would you recommend systems or integration inspectors to come on board? How can inspectors be justified earlier within the project to include a review of the initial design specs and drawings?"
Mac Lister: There are multiple questions here, but who wants to start?
A. Emiliano Lopez: I'll go ahead and start. The system engineering process is iterative. I think the approach of very detailed specifications are what we're trying to get away from, for the primary reason that technology and processes change so quickly, you kind of build yourself into a corner. I'm somewhat perplexed at the comment or the notion that when you're loose, that the bid prices are competitive again. I would question the change orders, as well as delays and a number of other issues that arise from having such vague. The preparing process really calls out for defining the system building off. It's again iterative. From the concept of operations, you'll get your high level system requirements and at some point, you actually turn it over to those experts that can turn that into more detailed design specifications. So early on, at the bid letting and at the RFP stage, you are defining what your functional requirements and needs are and not so much the equipment that's going to be providing that.
Mac Lister:Emiliano, I have a condensed version of the question, an amendment to it, a focusing on it from the questioner. Thanks to the questioner for doing that. Perhaps you can all take a quick crack at this one. I would like to condense my previous question down to when do you recommend at what point should inspectors be introduced to the project? It appears it is too late when specs and drawings are released for construction. The knowledge of the inspectors should accompany the systems engineering and design engineers. Comment on that, anybody?
back to top
Amy Tang McElwain:I would agree from the last comment about the inspector accompany the systems engineering and design engineers. The way our organization is structured, we have an inspection and installation construction group. They do the inspection work and they actually do work with our system engineering groups very closely at the up front specification phase. But also, I want to point out that if you do specify so detailed to the point, you are geared toward a product that's not even available on the market. That may drive up the price. I'm just guessing that might be the case for that situation. We did face one of that experience. That's why we added the feasibility review up front, to see if there's anything that's actually available out there, so that we don't go through our resources and time to go through this bidding process to want to find something to meet our need. A very elaborate system, which doesn't even exist in the market.
Mac Lister:Mike, any thoughts you want to share?
Michael Stokes:We do all of the inspections here. You're right. I think there is some benefit to educating the staff that's doing the design and planning of the project. Whether it has to be the inspectors, I don't know. I can't really speak to that.
Mac Lister: Q. How do you feel about the introduction of the Penta-P program? The Penta-P program in allowing contractors to be handled under private and public partnerships, specifically for light rail projects. How should agencies handle oversight of public-private partnerships?
Mac Lister:: Any thoughts on that? Do either of you have experience with public-private partnerships and how you relate to that? Does that relate to your systems engineering processes at all?
A. Amy Tang McElwain: I can't speak for the Penta-P, which I'm not familiar with what that is. I'm not going to address specific partnership for light rail projects, but I would say that in VDOT we're actually going through two very major PPTA projects, public-private partnerships, for our hotline construction operation. We have so many different various planning documentations that before the agreement would be signed. I would say that what we've done up to this point, I would highly recommend everyone else would do is insist on having a very good acceptable concept of operation document before you move on to the agreement phase. That's actually something that we have been spending hours and hours of our time and our operations group has reviewed and discussed and to make sure that's something that has a minimal negative impact during the construction and after construction in terms of how it can be operated for our customers. That's something that we focus on from the concept of operation phase. We also review all the design plans to make sure that ITS and operations are addressed properly.
Mac Lister: Okay. Mike, have you guys done any public-private partnership exploration or implementation?
Michael Stokes: No. Not at this time.
Mac Lister: Okay. In your previous life, Emiliano, how about you?
Emiliano Lopez: We did the fiber resource sharing project out of [?] and VDOT. I think the key thing here to remember is in a public partnership, the private entity is just an additional stakeholder. So as long as you keep in mind that your needs, the agency's needs, are coordinated and integrated into the private sector's as well, all the system engineering quality control assurance measures need to be kept intact, at least from the perspective of the agency, as well as the risk management. There's always that risk that the private entity-- the benefit of bringing in the private entity is that their hands aren't tied to some of the government agency processes. So there's where you get a little bit of benefit with that private partnership part. But in general, there are still a number of needs that you're getting into the partnership for and those need to be maintained, as well as the quality assurance and control to make sure that you get the final product or the final services that the public agency was expecting. They still get those and on time and within the budget scope.
back to top
