Myślę, że zależy to od tego, ile informacji chcesz i jak formalnie chcesz je śledzić. Wygląda na to, że obecnie żadna z tych informacji nie jest nigdzie zapisana, co jest oczywiście pierwszym problemem. Ale umieszczenie informacji na temat rozwiązania, którego nie zamierzasz realizować, jest w najlepszym razie mniej niż optymalnym wykorzystaniem czasu. Musisz określić, które pomysły są wystarczająco rozwinięte, aby je zarejestrować. Jeśli masz spotkanie i na stole pojawi się kilkanaście pomysłów, ale połowa z nich jest prawie natychmiast odrzucana, czy chcesz zanotować, jakie były te pomysły i dlaczego zostały odrzucone? Jest to duży wysiłek w przypadku analizy, która była prawdopodobnie bardzo niskim poziomem, ale nadal są to decyzje projektowe.
Bardziej intuicyjne wydaje mi się robienie tego tylko w przypadku pomysłów, które osiągają etap faktycznej pracy nad nimi. W ten sposób masz już coś namacalnego, a to po prostu musi być zapisane w pliku projektu, co, mam nadzieję, jest już czymś, co już masz. Ponieważ ten system naprawdę będzie generował tylko materiały referencyjne dla przyszłych projektów, nie sądzę, że dobrym pomysłem byłoby stworzenie zupełnie nowego systemu do archiwizacji tych materiałów lub przeglądu istniejącego systemu. Znajdź sposób na zintegrowanie go z obecnym systemem zarządzania projektami.
Jedynym kluczem, który powinienem upewnić się, że masz, jest sposób klasyfikowania różnych projektów według ich kluczowych parametrów. Nie wiem dużo o twojej dziedzinie, ale zakładam, że istnieją pewne parametry projektowe, które musi spełnić każdy projekt (wielkość fizyczna, wydajność, rodzaj instalacji itp.). Upewnij się, że są one gdzieś łatwo widoczne, aby podczas rozpoczynania nowego projektu można było zidentyfikować stare projekty, które są podobne pod różnymi względami. Jeśli przechowujesz odrzucone pomysły w tych folderach, będziesz mógł przeanalizować ich użyteczność w bieżącym projekcie.
Chcę jednak ogólnie ostrzec o zbyt głębokim wchodzeniu w to. Ponownie pracuję w innej branży, w której projekty są znacznie krótsze i jako takie jest ich o wiele więcej, ale niektóre produkty istniały w jakiejś formie od dziesięcioleci i jest ich 15-20 wersji. Utrzymywanie historii zmian dla faktycznych zmian projektowych, które zostały wprowadzone, jest bardzo ważne. Wiedza o tym, co klient otrzymał w przeszłości, kiedy wprowadzono zmiany i dlaczego zostały wprowadzone, jest kluczem do tego, aby nie powtarzać przeszłych błędów i poprawnie obsługiwać stare projekty. Ale kiedy katalogujesz projekty, które nigdy nie zostały w pełni zrealizowane, dodajesz zbędne dane do podstawowych danych, a tylko tyle możesz posortować, zanim sprawy zaczną się gubić. Brzmi jak ty szukam zamiennika solidnej komunikacji i dobrego doświadczenia. Gdy projekty te zmieniają właściciela, zaangażowani inżynierowie muszą przekazać wszystkie istotne informacje. Rozumiem, że chcę się upewnić, że wiesz, co zostało wzięte pod uwagę, ale radzę ci uspokoić to pragnienie, aby nie zalać twoich rekordów niepotrzebnymi danymi.