經理人需要為其特定的市場和競爭戰略尋求恰到好處的柔性，效率和質量。什麼是恰到好處，依次如下，取決於客戶需求，競爭對手的能力以及其他因素，如市場的不確定性，或者政府政策（例如在醫療保健和通訊方面的政策）。但是經理人可以使用某些槓桿來平衡柔性，效率和質量，這一點是很清楚的。這可以取決於技術，比如可程式設計的自動裝置。儘管特定的生產管理技術和管理供應商、工人、產品開發策略（例如企業模組化，或者使用企業內部平臺的程度）可能更加有用。
產品開發與柔性
引入注目的是柔性相對於技術本身與非技術因素有很大的關係。工人參與問題解決小組，特別是與供應商，產品設計中零部件重用相關的方法在確定柔性時似乎更重要些。擁有最多計算機（可程式設計自動裝置）的工廠事實上柔性最小。這一發現對組織使用其資源，理論能力，選擇提高柔性所需的投資型別方式具有重要的啟示。例如，經理人在購買最新的技術之前，將會更好地最大化他們現有的工廠，裝置和供應商的柔性。
研究表明組織能夠使用某些方式來變得非常柔性，也可以用另外的方式來使得工廠有較小的柔性。所以專注於“柔性工廠”或“柔性生產體系”就不是特別有用。而且，我們的研究結果表明，某些柔性型別往往同時改變，如產品組合和新產品柔性，但是產量柔性的動力不同。這一點又有重要的啟示：經理人可以選擇他們想要的廠商（以及其組織）在哪些方面變得柔性。企業根據環境可能會要求有更多特定的柔性型別，當然，柔性的實現不能以質量或者顧客的安全為代價。
正如我們能夠分析在產品製造中的不同柔性型別，我們也能夠分析在產品開發中的柔性及其權衡。我研究中的最好的例子又將重溫微軟為PC和因特網市場進行的敏捷式，或者迭代式的軟體開發：相對於為大型計算機所使用的更為緩慢，更為結構化的軟體工程。對PC和網際網路軟體，管理的挑戰迅速變成了如何增加足夠的結構來避免工程的混亂，但仍然鼓勵個人創造力，產品創新，對市場的快速響應，不可預知變化的技術以及顧客需求。
“舊的”軟體工程以及許多其他型別的產品開發的結構設計，採取“瀑布”式的或甚至是不那麼嚴格的“階段一出口”過程，根據這種順序的工藝過程來執行規則。例如，瀑布式工程中的經理人，通常需要設計詳細的需求文件以及詳細的設計文件。然後，經理人就會嘗試著“凍結”設計，程式設計師將會根據最初的要求和詳細的設計，使得編碼和測試的改變最小化。當然，不嚴格的“瀑布式”或者“階段一出口”式的過程，在某種意義上來說能使專案更加有效，因為不允許某點之後改變設計，那麼就可以使返工以及再測試的工作最小化。但是，在快節奏的市場中面臨的挑戰是發明創造和創新，或者處於開發與顧客提供的頻繁反饋相關聯的環境下，“瀑布式”的和“階段一出口”式過程就變得非常缺乏柔性。在某種程度上這常常導致無效的過程，如果不能滿足顧客的期望，或者與時俱進的市場需求時，專案的成員將不得不返工改變其設計，或者是前功盡棄。
比爾·蓋茨早年的成功秘笈
在快速變化的市場，比如20世紀80年代和20世紀90年代期間PC和網際網路軟體，比爾·蓋茨以及其他微軟的經理人試圖保留靈敏的和柔性的小團隊，即使產品規模和產品複雜性急劇增加。這發生在當PC產業從基於字元的DOS作業系統和簡單的DOS作業系統的應用發展到應用圖形程式，就像1984年的麥金塔計算機和1990年Windows PC。微軟的“組建可以像小團隊那樣工作的大團隊”嘗試並不是一帆風順的，尤其是在開發Windows Vista其開發團隊達到數千人之際。但是，微軟已經足夠成功了，尤其是在像Word和Excel（現在是Office的一部分）應用專案上，這兩款軟體首先是為麥金塔計算機開發，其後為PC開發。公司還遵循相同的敏捷或迭代原理，這些原理在Windows 7專案中被再一次證明是非常有用的。微軟在退役軍人史帝文·斯諾夫斯基和喬恩·德瓦恩的帶領下，在2009年秋天完成了這個專案。他們兩人都曾經領導過Office小組，管理過Windows團隊以及“修復”過Vista中的問題。斯諾夫斯基德瓦恩在20世紀90年代初幫助提煉的原理，以及這些原理對Windows 7的適用性是後面討論的重點。
使大團隊像小團隊那樣工作
我們也許可以發現對這個表述的最佳解釋需要結合柔性和結構，在我最喜歡引用之一中的《微軟的秘密》（1995）。微軟的前任Windows 95的測試經理戴夫·馮瑞茲，解釋瞭如何利用他作為以色列坦克指揮官的背景，施加簡單但是嚴格的規則，以保持高度個人主義的軟體開發商之間的協調：
在軍隊中，當發生坦克戰而我就在坦克裡進行戰鬥，沒有什麼比從無線電對講機中聽到指揮官的聲音更加令人感到安慰了。即使是一團糟，仍然有一個人正在負責一切……如果有15分鐘到半個小時以上聽不到時[指揮官的聲音]，發生了什麼事情呢？他負傷了嗎？他失去了控制嗎？他知道現在的情況嗎？你就會十分焦慮。這也是微軟所面臨的情形。這些小辦公室，門一關就與世隔絕。如果你不時時刻刻透過電子郵件發出權威的命令，公司就會停止運轉。我現在做的一切都是從軍隊學到的……如果沒有組織性，你就不可能做成任何複雜的事情……你要做的就是使這種組織性儘量隱蔽起來，並且要給所有這些傲慢的傢伙造成一種印象，覺得他們仍然可以喜歡什麼就幹什麼。誰去在乎一個傢伙是否整天不穿鞋子到處亂走？誰去在乎這個傢伙上班時間鬍子亂糟糟的？我是不在乎。我只想知道……是否有人在5點之前沒有登記他的程式。如果有的話，那個傢伙就肯定知道我要闖進他的辦公室。
馮瑞茲描述的這幅場面就像高度靈活但是協調的軍隊：在各自辦公室（類似於個人坦克）工作的微軟程式設計師的所屬部門透過電子郵件和公共過程來協調。5點鐘就是關於Windows 95組檢查每天所編寫程式碼的截止時間。此外，編碼創造了產品的工作版本，以便於工程師能夠測試新增的功能，確保在現有的特色仍能正常運轉。每日構建是其“嚴格”組織目標之一，使得每個人都集中在一個專案之中。
絕大多數微軟的經理人和程式設計師同樣地避免了更高層次的結構和官僚主義，我們可以從日本的軟體廠商，或者在印度符合美國軟體工程研究所的實踐（CMMI 4級和5級）的先進的軟體工程設施中看到這種更高層次的結構和官僚主義。相反，微軟的經理人和程式設計師往往試圖將非正式化的小團隊風格“按比例放大”進行軟體開發，依靠每日構建和持續的測試來整合一些相對小的核心團隊的工作。這些團隊一般由5到8個軟體開發人員，“結對”測試者和一個專案經理（組成。這些團隊遵循一些高層次的法則（阿德勒稱之為“元程式”）。
保持小團隊一個顯而易見好處就是使專案小型化，如透過限制他們的規模和範圍。例如，相對於做一個需要4年的大專案，最好是將目標和團隊減少一半，計劃為兩個18個月或24個月的專案。這種計劃安排在20世紀90年代後期和21世紀初期變得更加困難，因為微軟想要趕超網景，增加了成百成千的程式設計師到Windows團隊。首要目標就是給Windows增加一個瀏覽器視窗，然後微軟需要一個媒體播放器，一個搜尋引擎和其他各種技術以及更好的安全特性，同時與谷歌，Linux，太陽微系統（Tava語言）以及其他的公司競爭。儘管如此，經理人需要給每個專案試圖完成的目標設定界限的想法是正確的。在汽車行業，某種程度的設計改變需要在生產裝置上如金屬衝壓模具，塑膠模具和物理上有影響的相鄰元件，發生了高昂的變化。汽車公司也要為每一種新的模型應對數以百計的供應商。因此，汽車設計相對於軟體的開發在有關改變控制方面，除了像太空梭上的軟體，SDC或東芝公司專業的核電廠商控制軟體程式設計應用是真正的關鍵任務之外，通常有更多的紀律。
要限定好團隊規模
汽車公司通常儘可能地將設計變更限制在建模和原型階段，使用計算機及其他技術來增加其柔性，這樣生產許多原型和測試模型就變得更容易。汽車設計者也大量使用計算機輔助工具，模擬程式和能夠允許專案在計劃表的儘量延遲某些最終決定的其他方法。例如，工程師可以鎖定某些規範和介面，如汽車門要設計多大，如何適應汽車車架，並允許同步進行做一些生產準備和模切。但是他們可以延遲最終的決定，即直到最後一刻才確定車門外表面準確輪廓。
限定能在任何一個專案工作的人數也是有用的。微軟在應用專案如Word，Excel和Oflfice套件上比Windows更為成功。這些應用在歷史上比作業系統組具有更簡明扼要的目標。此外，專案經理透過設定時間限制，如用12個月或28個月生產一個軟體產品的新版本，或用四年為一輛汽車生產一個新的模型能夠聚焦專案。時間的限制，尤其是與員工的限制相結合就可以使團隊做出利用所分配資源的決定。這提高了效率併產生了創造力。專案團隊沒有優先順序和時間的限制往往會嘗試去做太多的事情，但是卻沒有一樣事情能夠做得非常好。
再次重申，微軟案例中應用組通常比Windows組更擅長於規定時間和員工的限制，Windows組往往目標模糊，對時間或人力資源沒有實際的限制。應用系統增加功能比作業系統的技術上更加簡單，所以在工作一段時間後更容易停下工作釋出一個應用產品。應用組能夠推遲未完成的功能到下一個版本，應用系統版本通常比作業系統版本更頻繁地釋出。
微軟的應用系統開發和作業系統開發之間的柔性程度有所不同，也反映了產品不同產品架構以及不同的競爭情況。Windows是DOS程式碼庫基礎上演化出的特定方式，導致了更復雜的相互依賴的功能。Windows組幾乎沒有什麼競爭力，通常計劃專案要持續若干年，並已學會了將重點放在可靠性，與以前的應用程式和硬體的相容性和安全性上。這些屬性現在需要多年的測試，因為程式的規模大和過度複雜的架構。應用組已經將重點放在模組化和易用性上，通常組織更小的，時間更短的和重點突出的專案。
微軟的例子表明，即使是對專案資源如時間和人員更多的限制，產品架構在提高柔性以及使大團隊像小團隊那樣工作中扮演著至關重要的角色。產品架構被廣泛應用於許多產業的核心技術就是模組化，將大的，複雜的系統分解成一組更小的和更獨立的特徵，功能部分或者子系統。因此，經理人能夠將大的專案細分成更小的子專案和團隊，在邏輯上能夠反射出產品細分的結構。例如，微軟通常將其應用產品和專案劃分為相對較小的功能和核心團隊。這種架構使得優先開發這些功能，將其歸為一個團隊並把最重要的或技術上相互依賴的部分優先構建，然後再輪到另一組特徵等等。
里程碑的價值
另一個有用的方法是將一個大專案分成子專案，微軟被稱之為里程碑。微軟在移向下一個里程碑之前，核心團隊透過為每一個特性，或者元件的子集進行一個完整的開發（設計和編碼），測試和穩定的週期。目的就是避免構建並且同時試圖整合太多的特性。專案經理也想要避免對未來太遙遠的目標，考慮到會發生太多的變化。微軟至少在Windows 7之前，應用程式在限制變化以及密集的里程碑進度計劃方面更為成功。隨著產品被分成更小的特性，甚至這些特徵又被分成子特性，使得專案能夠將工程分解成小塊，少數人通常就能夠在短的時間內完成，例如半天完成。小型團隊和個人也對其工作負有更加直接的責任，擁有知識和自主權來調整或者修改其產品中的某些部分。
現在我們來談論該過程的關鍵之處：某些硬性規定使得個人和小團體像一個團隊那樣工作（即效率），但是沒有過度地抑制個人的創造力，或者作出產品設計改變的能力（即柔性）。我們在20世紀90年代觀察微軟的時候，塞爾比和我發現了完成這個目標的三種實踐。
1、每個專案都必須要創造一個每日構建。
2、沒有一個登記新程式碼的人被允許打破構建，程式設計師必須立馬解決任何問題或收回其改變。
3、專案必須再細分為里程碑子專案來減少他們所做事情的複雜性並且更加聚焦於團隊。
我們為其他規則的不足而感到震驚。例如，開發人員可以自由地在他們高興的時候來上班，只要他們喜歡，既可以很頻繁地也可以很少地為產品構建做出貢獻。然而，開發人員必須在一個規定的時間裡檢查其工作，不允許登記會導致演化中的產品停止工作的程式碼。這就需要可觀的投資來做持續的測試：每個開發人員分配了對應的測試人員，以及一系列的自動化測試工具和測試用例。
沒有良好的人際溝通和正式或非正式的實踐促成適當的資訊交換，那麼基於團隊的過程就不可能變得有效。我們看到了在微軟中有效的若干實踐。例如，儘管有職能的專業化和勞動分工，但人員間還是共同承擔絕大多數的任務和責任。專案經理和生產經理在撰寫產品願景陳述時通常承擔共同的責任。專案經理和開發人員也一起定義產品的特性。開發人員和測試人員一起測試程式碼。專案經理，開發人員和測試人員在新產品釋出後都幫助回答客戶支援電話。此外，微軟儘可能使同一個產品在同一地點進行開發，使用共同的程式語言以及其他的工具。絕大多數的團隊也儘可能避免官僚化，儘管這在公司和團隊規模壯大的時候變得更加困難。
最後，我們發現如何使設計柔性到過程並能夠適應意料之外的變化。尤其是微軟假設產品的規範將持續演化到專案的終點。這是為了吸收原型內部使用者的反饋，可用性實驗室透過典型客戶和測試使用者嘗試新的功能。願景陳述引導了一個專案的整體目標，但這與瀑布式的說明檔案不同。至少在20世紀90年代中期，專案經理預計微軟最終的產品目錄將會改變，相對於專案剛開始的原始估計要增加20%—30%。此外，專案為了適應變化，包含了事先安排了緩衝時間（應用專案大約20%的時間，作業系統專案和全新的產品50%的時間）。每一件重大事件發生後都要舉行事後反思會議並撰寫報告，專案結論也鼓勵了員工隨著團隊經驗的累積而與時俱進，並持續地演化其開發過程。
這些實踐沒有一種是軟體開發所特有的。幾乎在任何一個產業，時間和人員限制都是有意義的。因為這些限制能使得團隊在競爭面前專心致志，並提供給客戶一些有用的東西。正如在軟體工廠或者多專案管理中一樣，將複雜的系統分成模組或子系統，以及元件的重用和設計一些元件，以便複用等都是良好的工程實踐。創造專案團隊對映到產品的架構，元件或子系統中是很好的管理實踐。如果團隊具有實驗的自主權改進其正在進行的設計或過程，也將變得更加有效和具有創新性。
與此同時，專案需要一些嚴格的規則使得個人進行頻繁的溝通來協同其工作。良好的溝通機制，同一場所（或國家最先進的通訊技術）工作，共享工具和技術，官僚陳規陋習最小化等能夠鼓勵進行有效地協同。眾所周知，專案經理應該允許產品規範的演化，安排緩衝時間，包括即時的過程改進。專案經理在快節奏的開發週期短的產業中需要適應許多的未知事件以及進行有用的學習。當然，企業必須聘用能夠應用最少規則來運作和應用判斷力的人才使其行動方法最佳並在其他場合具有柔性。
惠普之道
我的合作者和我在惠普（和研究期間分出來的安捷倫科技）開展這項研究之前，對各種技術做了更詳細的分析。我們的目標是比較強調迭代或者敏捷技術的專案與強調瀑布式技術專案的績效。
最重要的發現是至少在單一的開發文化（惠普和安捷倫），尤其是技術似乎作為一組相關的實踐在起作用。當相互結合在一起使用的時候，消除了彼此間效率和柔性的折中。惠普和安捷倫將幾種技術而不僅僅是選擇其中的一種或兩種技術結合起來使用時，軟體專案能在對質量影響最小的情況下調整後期設計，使之變得更加柔性。具體地說，當惠普和安捷倫使用初期原型的測試版本來獲得使用者的反饋，管理設計審查，對每個版本進行迴歸測試，或者整合測試（即在每次改變，或者產品新增新的附加功能）時，開始編碼時不完整的設計和“錯誤”間的相關性就消失了。
統計分析（多變量回歸分析）也提供了一些非常詳細的洞察力。三個因素解釋了專案之間將近四分之三（74%）的缺陷的不同：客戶多早能夠看見到原型，專案是否做了設計審查，專案是否對每個版本進行了迴歸測試和整合測試。關於質量和生產率水平，相對於中位專案，我們也發現了一些令人震驚的結果：
更早釋出原型（即用20%的功能與中位水平的40%進行比較），與缺陷率減少27%和程式碼行生產率增加35%相關。
對每個程式碼進行整合，或者回歸測試檢查與缺陷率下降36%相關，這是與中位專案的再一次比較得到的。
進行設計審查與缺陷率減少了將近55%相關。
進行每日程式碼構建與將近兩位數（93%增長）的程式碼行生產率相關。
當然，度量生產率和質量有不同的方式，尤其程式碼行是一個非常粗略的度量標準，每一程式碼行的缺陷不會顯示出客戶的滿意，或者產品的經濟價值。尤其是我們有一些來自大樣本研究的具體的成果，可以肯定在其他研究中發現的觀察結果。尤其某些實踐被一起應用的時候，似乎能夠消除生產率，質量和柔性之間的折衷的結果，與PCB的研究有明顯的相似之處。與許多研究者在其他製造和工程運作研究中所發現的是一致。