Po to, aby dokonać analizy rentowności, potrzebne są dane wejściowe, czyli m.in. koszty pracy przeznaczonej na dany projekt. Jednak aby je policzyć, informatyk musi dostarczyć - np. cotygodniowe - rozliczenie godzin pracy poświęconej na dany projekt. Zasadniczo w firmach informatycznych istnieją trzy modele pracy: jedna osoba Ű Ű pracuje tylko nad jednym projektem, poświęca czas na kilka projektów jednocześnie (ale np. jednego dnia pracuje tylko nad jednym projektem), pracuje nad zadaniami ogólnymi (np. tworzy rozwiązanie, które będzie wykorzystywane przez wiele systemów i wielu klientów, np. uniwersalny system zarządzania wydrukami). Każde z tych rozwiązań wymaga rozliczenia kosztów i dział finansowy firmy jest bezradny, jeżeli informatycy takiego rozliczenia nie dostarczą.

Pierwsza reguła brzmiałaby więc tak: rozliczać czas pracy przeznaczony na konkretny projekt. Niestety, menedżer może się spodziewać, że informatycy natychmiast uznają to za zamach na ich swobodę planowania swojego czasu pracy. Trudno jest poradzić sobie z takim oporem. Informatycy powinni mieć jasność, że takie informacje nie służą do pilnowania dyscypliny pracy, w przeciwnym razie manipulowaliby nimi i stałyby się bezwartościowe.

Reakcja na błędy

Druga dziedzina, którą trzeba koniecznie zawrzeć w procedurach, to reakcja na błędy. Większość kosztów systemu to wcale nie koszty jego tworzenia, a koszty naprawiania błędów. Jeżeli od programistów wychodzi produkt, który ma poważne błędy i taki produkt przekazywany jest do klienta, to takie braki prędzej czy później wyjdą. Każda naprawa to koszty dwojakiego rodzaju: naniesienie tej poprawki (często oznacza to także dodatkowe czynności, np. przekompilowanie całości) i jej dystrybucja, czyli dostarczenie nowej wersji do klienta. To także koszt ukryty, koszt mniejszej satysfakcji klienta - ten rodzaj wydatku pojawi się, gdy trzeba będzie np. udzielić klientowi specjalnej zniżki na uaktualnienie, aby wynagrodzić mu niską jakość poprzedniej wersji systemu.

"Koszty organizacyjne" błędu są z reguły znacznie większe niż jego "koszty techniczne". Niestety, informatycy rzadko to rozumieją. Zdefiniowanie całej ścieżki, jaką przechodzi uaktualnienie od momentu, gdy ktoś je zaprogramuje, do momentu, kiedy zaczyna przynosić korzyść klientowi, pozwala na wyznaczenie ram czasowych takiego uaktualnienia (np. aby zamiast nierealnie obiecywać klientowi realizację zlecenia na jutro, podać termin wykonania za tydzień), wskazać osoby odpowiedzialne za poszczególne fazy, a także - znowu - dokładnie policzyć, ile kosztują błędy popełniane przez poszczególne osoby. Taka informacja może przydać się przy okresowej ocenie pracowników - i także z tego powodu procedury są konieczne.

Bardzo istotne jest, aby informacje o błędach, niedociągnięciach i pytaniach klientów nie były gubione. Taka "lista życzeń" stanowi podstawę do dalszego rozwoju systemu, ilustruje bowiem, jakie cechy użytkowe są ważne dla jego odbiorców. Pozwala utrzymać stały kontakt z klientami i dostosować kierunki rozwoju do ich życzeń.

Kontrola jakości

Warto wdrożyć prawidłowe procedury obsługi błędów. Ale jeszcze lepiej jest opracować i stosować procedury zapobiegania błędom. Aby zapewnić możliwie dobrą jakość systemu informatycznego, potrzeba inteligentnego mariażu technologii z zarządzaniem. Po pierwsze, firma powinna zapewnić, że żaden element systemu nie będzie włączony do produktu, zanim nie zostanie gruntownie przetestowany. W jednej z metod tworzenia oprogramowania, zwanej Extreme Programming, testy dla komponentów są pisane przed powstaniem samych komponentów! Po drugie, istotnym elementem kontroli jakości są procedury testowe. Takie procedury to dokładne opisy czynności, które musi wykonać osoba testująca system, aby zweryfikować, czy dana funkcja rzeczywiście działa prawidłowo. Nie trzeba chyba dodawać, że weryfikacji trzeba dokonać w rzeczywistym środowisku klienta. Innymi słowy, jeżeli klient korzysta z przeglądarki Netscape Navigator, to nie wystarczy np. za pomocą Internet Explorera przetestować serwisu internetowego.

Biblioteki

Siłą każdej firmy informatycznej jest biblioteka rozwiązań, które stworzono wcześniej, a które mogą być zastosowane także do innych zadań. Taka biblioteka to skarb. Pozwala wielokrotnie czerpać korzyść z już raz dokonanej inwestycji. Dlatego bardzo istotne jest, aby pobieranie rozwiązań z takiej biblioteki, a także ich umieszczanie w niej, było ujęte w pewne reguły i procedury.

Procedury umieszczania elementów w takiej bibliotece mają na celu zapewnienie, aby nie mogło się tam znaleźć nic, co nie jest dokładnie przetestowane i odpowiednio uniwersalne. Firmy informatyczne zwykle wypracowują też pewien zestaw standardów projektowych i programistycznych (np. funkcja ma się nazywać pobierzPlik, a nie pobierz_plik) i ważne jest, aby wszystko, co znajdzie się w takiej bibliotece, stosowało się do tego standardu. Procedura powinna jednoznacznie określać, jakie warunki ma spełniać element biblioteczny, a także wskazywać osoby odpowiedzialne za kontrolę przed umieszczeniem w bibliotece.