技術規劃/規劃之前
在真正撰寫有意義的技術規劃之前，至關重要的是要啟動一個包容性的流程，從相關技術社群的所有成員那裡收集意見。應組建一個戰略規劃委員會，其成員來自所有對您將要規劃和最終實施的內容有利益關係的領域。儘可能地瞭解其中涉及的政治問題，並努力不要遺漏任何在以後可能會抵消積極努力的人。在這種努力中，您甚至可以“讓敵人靠近”。最好在委員會討論中解決一個可能成為阻礙的問題，而不是讓它在您提交最終計劃的關鍵時刻出現，從而對任何建議的成功或早期採用造成重大損害。該委員會將為需求分析提供意見和討論，這有助於形成真正的基於資料的結論，並最大限度地減少假設。它還有助於防止思維侷限，更糟糕的是，繼續以相同的方式做事，因為這樣做很舒服。需求分析將推動技術規劃的目標和願景決策。沒有透徹地瞭解您所在學區或機構的需求，您就無法撰寫有效的技術規劃。
該委員會不應僅由瞭解技術的人員組成。事實上，從學術和行政領域以及一到兩名學生代表那裡廣泛地獲取代表性會更有用。請記住，目標之一是最小化錯誤的假設或過快地對應該做什麼或我們實際上能負擔什麼做出判斷。嘗試將委員會成員數量控制在合理範圍內，這樣才能很好地運作，而不是一大群人。此外，請務必選擇可預測的會議時間 - 例如，每月同一天，同一時間 - 大多數人都可以參加。一個簡單的方法可能是每個月的第二個星期二下午 2:00（2,2,2）。這種一致性使所有成員更容易記錄並出席會議。將整個流程對學校其他可能沒有參加規劃委員會的成員開放。向所有成員及時釋出會議紀要，並考慮在您的主網站上建立一個存檔，其中列出委員會成員，包括他們的聯絡資訊和職稱。也在此位置釋出會議紀要。向成員強調出席每次會議的重要性，如果您在任何時候發現應該包含另一個人，請嘗試新增那個人。作為規劃委員會主席，您需要讓每個人都專注於任務，並應提前為每次會議做好準備，以確保每個人投入的時間的有效性。使用實際事實，不要讓政治或個人恩怨在討論中出現，並快速地對任何出現的東西進行交通管制。將委員會的重點保持在委員會內部，並寫一份簡要的指令，解釋該小組的作用和範圍。最後，隨著討論的出現，請務必朝著共識努力，而不是讓一個人比任何人都說得更響亮或更熱情。
對技術實際使用者進行採訪並確定其現有操作中最緊迫的不足之處非常重要。讓使用者描述問題、需求，而不是他們認為需要的特定解決方案。請記住，此時您僅處於資訊收集模式，而不是測試解決方案。需求的描述可能涉及稍後需要檢查可行性的多個解決方案。一個使用者可能讀到了一種強大的開源解決方案，他們非常想要在自己的教室裡使用它，但可能沒有考慮該解決方案在後臺需要什麼樣的額外程式設計支援。這些問題將在稍後解決。請務必涵蓋所有可以提供意見的相關參與者，而不僅僅是部門主管，例如，部門主管可能忽略了走廊或其他建築物中正在進行的獨特應用。不要承諾任何快速修復或即時供應商購買，而是澄清這只是一個探索性工作，委員會將審查所有資料。對問題要精確，並提出一個最終的開放式問題，例如“如果您能解決一個或兩個阻礙您的技術問題，那是什麼？”需求分析資料應提供給委員會的每個成員。此外，讓為這一步提供意見的使用者知道，他們可以坦誠地說話，他們的姓名不會與特定的評論聯絡在一起。您可能會發現一些關鍵資訊，這些資訊在最終的技術規劃中很重要。
請記住，技術既不好也不壞。是我們在特定環境中，為了特定目的“使用”技術工具，才能產生影響（Katz，2008 年）。徹底的需求分析將作為規劃流程中下一步的橋樑，併成為後續關鍵決策的基礎。請確保您提供一個堅實的基礎作為成果。
Katz, R. (2008)。塔與雲 - 雲計算時代的高等教育。EDUCAUSE。科羅拉多州博爾德。