Wee1 Forum 423Answers s 31Homework 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.  Interested in thoughts this  week.