Moving pattern to a different section in the README. Also updating status to reflect the new maturity levels.

Author: spier

README.md

@@ -52,7 +52,6 @@ possible to either deploy the same service in independent environments with sepa
 * [Overcome Acquisition Based Silos - Developers](patterns/2-structured/overcome-acquisition-based-silos-developer.md)
 * [Overcome Acquisition Based Silos - Managers](patterns/2-structured/overcome-acquisition-based-silos-manager.md)
 * [Open Source Trumps InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/46) - *People find the InnerSource project but, after all things are considered, even if the InnerSource component meets their needs, they still go with the open source component.*
-* [Overcoming Project Management Time Pressures](patterns/1-initial/overcoming-project-management-time-pressures.md) - *Project management believes timeline pressure and commitments on feature content does not allow for developers to spend the time needed to develop shareable code and provide support.*
 * [Start as Experiment](patterns/2-structured/start-as-experiment.md) - *An inner source initiative is considered but not started, because management is unsure about its outcome and therefore unwilling to commit to the investment.*
 * [Include Product Owners](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/71) - *Key Performance Indicators (KPIs) for Product Owners are primarily product focused, and don't consider areas such as collaborative development. This results in a lower level of engagement with inner source projects.*
 * [Provide standard base documentation through a README](patterns/2-structured/project-setup/base-documentation.md)
@@ -64,6 +63,7 @@ possible to either deploy the same service in independent environments with sepa
 
 * [Modular Code](patterns/1-initial/modular-code.md) - *Management does not want to spend the extra resources needed to develop modular components and make them available in a visible repository for others to use.*
 * [Improve Findability](patterns/1-initial/improve-findability.md) - *People can't find the internally developed solutions that they need due to poor naming conventions. This causes frustration in finding inner source solutions and a reduction in code reuse.*
+* [Overcoming Project Management Time Pressures](patterns/1-initial/overcoming-project-management-time-pressures.md) - *Project management believes timeline pressure and commitments on feature content does not allow for developers to spend the time needed to develop shareable code and provide support.*
 
 #### Pattern Ideas (not yet proven; brainstormed)
 

patterns/1-initial/overcoming-project-management-time-pressures.md

@@ -10,38 +10,38 @@ TBD
 
 Project management believes that timeline pressures and feature content commitments do not allow Developers to spend the time needed to develop shareable, reusable code and provide support. As a result, there is currently no code available for reuse, and Developers are writing redundant code.
 
-## Context 
+## Context
 
 Customer deadlines and delivery commitments for feature content do not change.  
 
 ## Forces
 
 - Aggressive roadmaps for delivery
-- Project management concern that engagement will lead to missed deadlines 
+- Project management concern that engagement will lead to missed deadlines
 - Project management concern that Code contribution and/or mentoring may lead to dilution of subject matter expert time spent on their own projects (other teams may require their time).
 + Elimination of rewriting common code saves time (write once, use many times)
 + Crowd-based testing and debugging saves time (and improves quality)
 + The collaboration and synergy of inner sourcing can generate new, innovative features  .
 + Test Driven Development could mitigate some of the above forces
 
-## Solutions 
+## Solutions
 
 - Known pattern: temporary fork by product team, merging changes back later to component team
 - Known anti-pattern: surreptitious temporary fork, no communication
 - New Pattern: Pre-pull request (prior to release), to ensure component team has buy-in, to avoid breakage for temporary fork
 - Allocate time into Development sprint/release schedules to allow for inner sourcing
 - Provide education to product owners and Development leads regarding time saving benefits of Inner Source
 
-## Resulting Context 
+## Resulting Context
 
 Time is allotted in the schedule for inner sourcing. Less duplicative development due to availability of reusable code. (No negative impact on customer deadlines or content delivery commitments.)
 
 ## Known Instances
 
 TBD
-  
+
 ## Authors
-  
+
 - Tim Yao
 - Nick Stahl
 - Guy Martin
@@ -50,4 +50,4 @@ TBD
 
 ## Status
 
-Draft Pattern (old status)
+Initial