Reference no: EM131670794

Assignment

Forum Questions:

1. Explain the importance of properly defining program requirements to meet mission objectives.

2. Do you agree with the Navy's method? Why or why not?

3. Search online or from any other source that indicates or shows how bad or faulty or changing requirements lead to a contracting problem.

4. Using your own experience give an example of when you worked on a contract or project and the requirements changed.

Instructions for a successful Forum:

Your initial post should be at least 250 words. Please respond to at least 2 other students. Responses should be a minimum of 100 words and should include at least one direct question related to what that another student posted or in response to a student's posting to your initial post.

Response question 1

Properly identifying the requirement that is needed to meet the mission you are supporting is the most important part of the process. If everything beyond that point worked perfectly and the requirement was wrong you still have total failure.

The contract that comes to mind with changing requirements is a contract that came in as a smoking area pavilion type of structure. The scope creep went on here and there with first the people inside the facility wanting 2 walls added to break up the wind in the winter. That soon became 4 walls and a covered walkway to keep dry on the walk. Then a small heater and air conditioning unit was added with the now fully enclosed space. Because there was then electricity added and the pavilion was attached to the main facility fire suppression needed to be added. Then management wanted glass walls so they could see outside to monitor that people were not hiding out too much in the pavilion. Then they realized that with it attached to the original facility they were not allowed to smoke in it. Thankfully this was realized before we actually built the thing. It ended up a pavilion with 2 walls in the end.

I found a good article on boardroom metrics addressing this issue. In a lot of cases changing requirements are the result of inadequate scope definition. The research they quote says that 71% of software projects fail due to poor requirements management. The three most common reasons they fail were lack of user input, incomplete requirements and changing requirements. The remedy for this with IT projects is to create more flexible requirements and to closely track the changes to anticipate how the changes could cause issues down the road. This might work to a limited degree for non-IT projects as well. (The Impact of Incomplete or Changing Requirements on IT Project Success).

Response question 2

Good morning. The importance of defining requirements is paramount to the success of the program. "Requirements creep" slows the process down, causes schedule delays and increases in cost. Identifying the requirements in detail upfront allows the program to plan for and drive towards meeting those on time and hopefully, under budget. In my limited experience, the DoD (Navy/Marine Corps) does not do a great job of identifying requirements. I think that the Navy's method works when followed and when those involved understand the acquisition and requirements world. There is a significant gap in the knowledge of the USN/USMC when it comes to establishing requirements, exploring contracts, etc. Over the past few years, this has started to come to light and appears that, in the Marine Corps specifically, a push to bridge that gap and make us smarter when it comes to these types of issues.

CH-53K Heavy Lift Replacement Helicopter immediately comes to mind when thinking about how requirements issues lead to contracting problems. A GAO report dated November 2016 provides a great summarization of this problem. This program began in 2005. A lack of communication on specific requirements by the Marine Corps and disagreements with the prime contractor on what systems engineering tasks would be required and caused an increase in cost and schedule. As the program continued, additional problems were encountered and in 2010 the program had to be re-baselined to meet the requirements. As a result, the program is 51 percent over initial cost estimates and behind schedule by 5 years.

Personal experience is with the F-35 program. This is obviously a large one and is well advertised. We continue to struggle with requirements, cost, schedule and performance concerns to date. A major problem with this program is the size and complexity. You have a joint program with (3) different services and multiple countries of which none operate the same. An additional problem with this program is that they attempted to perform simultaneous T&E while going into production. This has been a major contributor to cost overruns with the F-35.

In closing, it is my opinion that we focus too much on the cost and try to shape our requirements around a dollar amount instead of establishing a requirement and working with the cost.

Attachment:- Getting-the-Requirements-Right.pdf