Podręcznik wyceny i specyfikacji C2g 29510 jest dokumentem, który zawiera zalecenia dotyczące wyceny i specyfikacji dla systemów bezprzewodowych i okablowanych. Podręcznik służy do tworzenia dokumentacji, a także do wyceny i specyfikacji materiałów i usług, które są niezbędne do wykonania całego systemu bezprzewodowego i okablowanego. Podręcznik zawiera wytyczne, które należy przestrzegać podczas tworzenia dokumentacji, wyceny i specyfikacji materiałów i usług systemu. Podręcznik zawiera również szczegóły dotyczące wyceny i specyfikacji wszystkich materiałów i usług niezbędnych do wykonania całego systemu bezprzewodowego i okablowanego.
Ostatnia aktualizacja: Podręcznik wyceny i specyfikacji C2g 29510
Na podstawie art. 103 ust. 4 ustawy z dnia 11 września 2019 r. - Prawo zamówień publicznych (Dz. U. z 2021 r. poz. 1129, 1598, 2054 i 2269) zarządza się, co następuje:
Rozdział 1
Przepisy ogólne
§ 1. [Definicje]
Ilekroć w rozporządzeniu jest mowa o:
1) grupach, klasach, kategoriach robót - należy przez to rozumieć grupy, klasy, kategorie określone w rozporządzeniu (WE) nr 2195/2002 Parlamentu Europejskiego i Rady z dnia 5 listopada 2002 r. w sprawie Wspólnego Słownika Zamówień (CPV) (Dz. Urz. WE L 340 z 16. 12. 2002, str. 1, z późn. zm. 2) - Dz. UE Polskie wydanie specjalne rozdz. 6, t. 5, str. 3, z późn. ), zwanym dalej "Wspólnym Słownikiem Zamówień";
2) pracach towarzyszących - należy przez to rozumieć prace niezbędne do wykonania robót podstawowych niezaliczane do robót tymczasowych, w tym wytyczanie geodezyjne i inwentaryzację powykonawczą;
3) robotach podstawowych - należy przez to rozumieć minimalny zakres prac, które po wykonaniu są możliwe do odebrania pod względem ilości i wymogów jakościowych oraz uwzględniają przyjęty stopień zagregowania robót;
4) robotach tymczasowych - należy przez to rozumieć prace, które są projektowane i wykonywane jako potrzebne do wykonania robót podstawowych, ale nie są przekazywane zamawiającemu i są usuwane po wykonaniu robót podstawowych.
§ 2. [Dokumentacja projektowa, specyfikacje techniczne wykonania i odbioru robót budowlanych]
1. Dokumentacja projektowa, specyfikacje techniczne wykonania i odbioru robót budowlanych oraz program funkcjonalno-użytkowy są odrębnymi opracowaniami, w których wydziela się tomy zgodnie z przyjętą systematyką podziału robót budowlanych.
2. Opracowania, o których mowa w ust. 1, mogą być sporządzone w formie papierowej lub w formie elektronicznej w postaci plików komputerowych w formacie PDF.
3. W przypadku opracowania sporządzonego w formie papierowej wszystkie strony w każdym tomie są trwale spięte i ponumerowane.
Rozdział 2
Zakres i forma dokumentacji projektowej
§ 3. [Zakres dokumentacji projektowej]
Zakres dokumentacji projektowej ustala zamawiający, biorąc pod uwagę tryb udzielenia zamówienia publicznego, zwanego dalej "zamówieniem", oraz wymagania dotyczące postępowania poprzedzającego rozpoczęcie robót budowlanych wynikające z ustawy z dnia 7 lipca 1994 r. - Prawo budowlane (Dz. 2351).
§ 4. [Informacje zawarte w dokumentacji projektowej służącej do opisu przedmiotu zamówienia na wykonanie robót budowlanych]
1. Dokumentacja projektowa służąca do opisu przedmiotu zamówienia na wykonanie robót budowlanych, dla których jest wymagane uzyskanie pozwolenia na budowę albo zgłoszenie robót budowlanych, do którego dołącza się projekt budowlany zgodnie z przepisami ustawy z dnia 7 lipca 1994 r. - Prawo budowlane, składa się w szczególności z:
1) projektu budowlanego w zakresie uwzględniającym specyfikę robót budowlanych;
2) projektu wykonawczego w zakresie, o którym mowa w § 5;
3) przedmiaru robót w zakresie, o którym mowa w § 6.
2. Dokumentacja projektowa służąca do opisu przedmiotu zamówienia na wykonanie robót budowlanych, dla których nie jest wymagane uzyskanie pozwolenia na budowę albo zgłoszenie robót budowlanych, do którego dołącza się projekt budowlany zgodnie z przepisami ustawy z dnia 7 lipca 1994 r. - Prawo budowlane, składa się w szczególności z:
1) planów, rysunków lub innych dokumentów umożliwiających jednoznaczne określenie rodzaju i zakresu robót podstawowych oraz uwarunkowań i dokładnej lokalizacji ich wykonywania;
2) przedmiaru robót w zakresie, o którym mowa w § 6;
3) projektów, pozwoleń, uzgodnień i opinii wymaganych odrębnymi przepisami. Jeżeli zamówienie na roboty budowlane, o których mowa w ust. 1 i 2, jest udzielane w trybie zamówienia z wolnej ręki lub w projektowanych postanowieniach umowy przyjęto zasadę wynagrodzenia ryczałtowego, dokumentacja projektowa może nie obejmować przedmiaru robót.
§ 5. [Projekt wykonawczy]
1. Projekt wykonawczy stanowi uzupełnienie i uszczegółowienie projektu budowlanego w zakresie i stopniu dokładności niezbędnych do sporządzenia przedmiaru robót, kosztorysu inwestorskiego, przygotowania oferty przez wykonawcę i realizacji robót budowlanych. Projekt wykonawczy zawiera rysunki w skali uwzględniającej specyfikę zamawianych robót i zastosowanych skal rysunków w projekcie budowlanym wraz z wyjaśnieniami opisowymi, które dotyczą:
1) części obiektu,
2) rozwiązań budowlano-konstrukcyjnych i materiałowych,
3) detali architektonicznych oraz urządzeń budowlanych,
4) sieci uzbrojenia terenu, instalacji i wyposażenia technicznego
- których odzwierciedlenie na rysunkach projektu budowlanego nie jest wystarczające dla potrzeb, o których mowa w ust. 1. Projekt wykonawczy, w zależności od zakresu i rodzaju robót budowlanych stanowiących przedmiot zamówienia, dotyczy:
1) przygotowania terenu pod budowę;
2) robót budowlanych w zakresie wznoszenia kompletnych obiektów budowlanych lub ich części oraz robót w zakresie inżynierii lądowej i wodnej, włącznie z robotami wykończeniowymi w zakresie obiektów budowlanych;
3) robót w zakresie instalacji budowlanych;
4) robót związanych z zagospodarowaniem terenu.
4. Wymagania dotyczące formy projektu wykonawczego przyjmuje się odpowiednio jak dla projektu budowlanego.
§ 6. [Przedmiar robót]
1. Przedmiar robót zawiera zestawienie przewidywanych do wykonania robót podstawowych w kolejności technologicznej ich wykonania wraz z ich szczegółowym opisem lub ze wskazaniem podstaw ustalających szczegółowy opis oraz wraz ze wskazaniem właściwych specyfikacji technicznych wykonania i odbioru robót budowlanych, a także z obliczeniem i zestawieniem liczby jednostek przedmiarowych robót podstawowych. Przedmiar robót składa się z następujących elementów:
1) strony tytułowej przedmiaru robót;
2) spisu działów przedmiaru robót;
3) tabeli przedmiaru robót.
§ 7. [Strona tytułowa przedmiaru robót]
1. Strona tytułowa przedmiaru robót zawiera następujące informacje:
1) nazwę nadaną zamówieniu przez zamawiającego;
2) adres obiektu budowlanego, a w przypadku braku adresu - opis lokalizacji obiektu budowlanego;
3) w zależności od zakresu robót budowlanych objętych przedmiotem zamówienia - nazwy i kody:
a) grup robót,
b) klas robót,
c) kategorii robót;
4) nazwę i adres zamawiającego;
5) imię i nazwisko osoby opracowującej przedmiar robót oraz - o ile występują - nazwę i adres podmiotu opracowującego przedmiar robót, oraz datę opracowania. Jeżeli objętość informacji, o których mowa w ust. 1, uniemożliwia zamieszczenie ich na stronie tytułowej, dopuszcza się zamieszczenie tych informacji na kolejnych stronach albo w postaci załącznika do strony tytułowej.
§ 8. [Spis działów przedmiaru robót]
1. Spis działów przedmiaru robót przedstawia podział wszystkich robót budowlanych w danym obiekcie na grupy robót zgodnie ze Wspólnym Słownikiem Zamówień. Dalszy podział przedmiaru robót należy opracować według systematyki ustalonej indywidualnie lub na podstawie systematyki stosowanej w publikacjach zawierających kosztorysowe normy nakładów rzeczowych. W przypadku robót budowlanych dotyczących wielu obiektów spisem działów przedmiaru robót należy objąć dodatkowo podział całej inwestycji na obiekty budowlane. Grupa robót dotycząca przygotowania terenu stanowi odrębny dział przedmiaru dla wszystkich obiektów.
§ 9. [Tabela przedmiaru robót]
1. Tabela przedmiaru robót zawiera pozycje przedmiarowe odpowiadające robotom podstawowym. W tabeli przedmiaru robót nie uwzględnia się robót tymczasowych, z wyłączeniem przypadków, gdy istnieją uzasadnione podstawy do ich odrębnego rozliczania.
§ 10. [Informacje podawane dla każdej pozycji przedmiaru robót]
1. Dla każdej pozycji przedmiaru robót należy podać następujące informacje:
1) numer pozycji przedmiaru;
2) kod pozycji przedmiaru, określony zgodnie z ustaloną indywidualnie systematyką robót lub na podstawie wskazanych publikacji zawierających kosztorysowe normy nakładów rzeczowych;
3) numer specyfikacji technicznej wykonania i odbioru robót budowlanych, zawierającej wymagania dla danej pozycji przedmiaru;
4) nazwę i opis pozycji przedmiaru oraz obliczenia liczby jednostek miary dla pozycji przedmiarowej;
5) jednostkę miary, której dotyczy pozycja przedmiaru;
6) liczbę jednostek miary pozycji przedmiaru. Liczbę jednostek miary podaną w przedmiarze oblicza się na podstawie rysunków w dokumentacji projektowej w sposób zgodny z zasadami podanymi w specyfikacjach technicznych wykonania i odbioru robót budowlanych. Obliczenia liczby jednostek miary - jeżeli nie są zamieszczone w danej pozycji przedmiaru - dołącza się do przedmiaru robót.
§ 11. [Strona tytułowa dołączana do dokumentacji projektowej]
1. Do dokumentacji projektowej, o której mowa w § 4 ust. 2, dołącza się stronę tytułową, która zawiera w szczególności:
1) nazwę nadaną zamówieniu przez zamawiającego;
2) adres obiektu budowlanego, którego dotyczy dokumentacja projektowa, a w przypadku braku adresu - opis lokalizacji obiektu budowlanego;
3) w zależności od zakresu robót budowlanych objętych przedmiotem zamówienia - nazwy i kody:
a) grup robót,
b) klas robót,
c) kategorii robót;
4) nazwę i adres zamawiającego;
5) spis zawartości dokumentacji projektowej;
6) imię i nazwisko osoby opracowującej części składowe dokumentacji projektowej oraz - o ile występują - nazwę i adres podmiotu, oraz datę opracowania.
Rozdział 3
Zakres i forma specyfikacji technicznych wykonania i odbioru robót budowlanych
§ 12. [Specyfikacje techniczne wykonania i odbioru robót budowlanych]
Specyfikacje techniczne wykonania i odbioru robót budowlanych stanowią opracowania zawierające w szczególności zbiory wymagań, które są niezbędne do określenia standardu i jakości wykonania robót, w zakresie sposobu wykonania robót budowlanych, właściwości wyrobów budowlanych oraz oceny prawidłowości wykonania poszczególnych robót.
§ 13. [Zakres specyfikacji technicznej wykonania i odbioru robót budowlanych]
1. Specyfikacje techniczne wykonania i odbioru robót budowlanych, w zależności od stopnia skomplikowania robót budowlanych, składają się ze specyfikacji technicznych wykonania i odbioru robót podstawowych, rodzajów robót według przyjętej systematyki lub grup robót. Specyfikacje techniczne wykonania i odbioru robót budowlanych dla budowy w rozumieniu ustawy z dnia 7 lipca 1994 r. - Prawo budowlane należy opracować z uwzględnieniem podziału grup robót według Wspólnego Słownika Zamówień, określając w nich co najmniej:
1) roboty budowlane w zakresie przygotowania terenu pod budowę;
2) roboty budowlane w zakresie wznoszenia kompletnych obiektów budowlanych lub ich części oraz roboty w zakresie inżynierii lądowej i wodnej;
3) roboty w zakresie instalacji budowlanych;
4) roboty wykończeniowe w zakresie obiektów budowlanych. Wspólne wymagania dotyczące robót budowlanych objętych przedmiotem zamówienia mogą być ujęte w ogólnej specyfikacji technicznej wykonania i odbioru robót budowlanych. Podział grup robót, o którym mowa w ust. 2, stosuje się odpowiednio do robót budowlanych polegających na remoncie obiektu budowlanego.
§ 14. [Informacje zawarte w specyfikacji technicznej wykonania i odbioru robót budowlanych]
1. Specyfikacje techniczne wykonania i odbioru robót budowlanych zawierają co najmniej:
1) stronę tytułową, która obejmuje:
a) nazwę nadaną zamówieniu przez zamawiającego,
b) adres obiektu budowlanego, którego dotyczy specyfikacja techniczna wykonania i odbioru robót budowlanych, a w przypadku braku adresu - opis lokalizacji obiektu,
c) w zależności od zakresu robót budowlanych objętych przedmiotem zamówienia - nazwy i kody:
- grup robót,
- klas robót,
- kategorii robót,
d) nazwę i adres zamawiającego,
e) nazwę specyfikacji technicznej wykonania odbioru robót budowlanych i jej numer,
f) imię i nazwisko osoby opracowującej specyfikację techniczną wykonania i odbioru robót budowlanych oraz - o ile występują - nazwę i adres podmiotu opracowującego specyfikację techniczną wykonania i odbioru robót budowlanych;
2) część ogólną, która obejmuje:
a) przedmiot i zakres robót budowlanych,
b) wyszczególnienie i opis prac towarzyszących i robót tymczasowych,
c) informacje o terenie budowy zawierające wszystkie niezbędne dane istotne z uwagi na:
- organizację robót budowlanych,
- zabezpieczenie interesów osób trzecich,
- ochronę środowiska,
- warunki bezpieczeństwa pracy,
- zaplecze dla potrzeb wykonawcy,
- warunki organizacji ruchu,
- ogrodzenie,
- zabezpieczenie chodników i jezdni,
d) określenia podstawowe, zawierające definicje pojęć i określeń nigdzie wcześniej niezdefiniowanych, a wymagających zdefiniowania w celu jednoznacznego rozumienia zapisów dokumentacji projektowej i specyfikacji technicznej wykonania i odbioru robót budowlanych;
3) wymagania dotyczące właściwości wyrobów budowlanych oraz niezbędne wymagania związane z ich przechowywaniem, transportem, warunkami dostawy, składowaniem i kontrolą jakości - poszczególne wymagania odnosi się do postanowień norm;
4) wymagania dotyczące sprzętu i maszyn niezbędnych lub zalecanych do wykonania robót budowlanych zgodnie z założoną jakością;
5) wymagania dotyczące środków transportu;
6) wymagania dotyczące wykonania robót budowlanych z podaniem sposobu wykończenia poszczególnych elementów, tolerancji wymiarowych i szczegółów technologicznych oraz niezbędne informacje dotyczące odcinków robót budowlanych, przerw i ograniczeń, a także wymagania specjalne;
7) opis działań związanych z kontrolą, badaniami oraz odbiorem wyrobów i robót budowlanych w nawiązaniu do dokumentów odniesienia;
8) wymagania dotyczące przedmiaru i obmiaru robót;
9) opis sposobu odbioru robót budowlanych;
10) opis sposobu rozliczenia robót tymczasowych i prac towarzyszących;
11) dokumenty odniesienia - dokumenty będące podstawą do wykonania robót budowlanych, w tym wszystkie elementy dokumentacji projektowej, normy oraz inne dokumenty i ustalenia techniczne. 1 pkt 1, uniemożliwia zamieszczenie ich na stronie tytułowej, dopuszcza się zamieszczenie tych informacji na kolejnych stronach albo w postaci załącznika do strony tytułowej.
Rozdział 4
Zakres i forma programu funkcjonalno-użytkowego
§ 15. [Program funkcjonalno-użytkowy]
Program funkcjonalno-użytkowy służy do opisu przedmiotu zamówienia, ustalenia planowanych kosztów prac projektowych i robót budowlanych, przygotowania oferty - szczególnie w zakresie obliczenia ceny oferty oraz wykonania prac projektowych.
§ 16. [Zakres programu funkcjonalno-użytkowego]
Program funkcjonalno-użytkowy składa się z następujących elementów:
1) strony tytułowej;
2) części opisowej;
3) części informacyjnej.
§ 17. [Strona tytułowa programu funkcjonalno-użytkowego]
1. Strona tytułowa programu funkcjonalno-użytkowego obejmuje:
1) nazwę nadaną zamówieniu przez zamawiającego;
2) adres obiektu budowlanego, którego dotyczy program funkcjonalno-użytkowy, a w przypadku braku adresu - opis lokalizacji obiektu budowlanego;
3) w zależności od zakresu robót budowlanych objętych przedmiotem zamówienia - nazwy i kody:
a) grup robót,
b) klas robót,
c) kategorii robót;
4) nazwę i adres zamawiającego;
5) spis zawartości programu funkcjonalno-użytkowego;
6) imię i nazwisko osoby opracowującej program funkcjonalno-użytkowy oraz - o ile występują - nazwę i adres podmiotu opracowującego program funkcjonalno-użytkowy.
§ 18. [Część opisowa programu funkcjonalno-użytkowego]
1. Część opisowa programu funkcjonalno-użytkowego obejmuje:
1) opis ogólny przedmiotu zamówienia;
2) opis wymagań zamawiającego w stosunku do przedmiotu zamówienia. Opis ogólny przedmiotu zamówienia obejmuje:
1) charakterystyczne parametry określające wielkość obiektu lub zakres robót budowlanych;
2) aktualne uwarunkowania wykonania przedmiotu zamówienia;
3) ogólne właściwości funkcjonalno-użytkowe;
4) szczegółowe właściwości funkcjonalno-użytkowe wyrażone we wskaźnikach powierzchniowo-kubaturowych, ustalone zgodnie z najnowszą opublikowaną w języku polskim Polską Normą PN-ISO 9836 "Właściwości użytkowe w budownictwie. Określanie i obliczanie wskaźników powierzchniowych i kubaturowych", jeżeli wymaga tego specyfika obiektu budowlanego, w szczególności:
a) powierzchnie użytkowe poszczególnych pomieszczeń wraz z określeniem ich funkcji,
b) wskaźniki powierzchniowo-kubaturowe, w tym wskaźnik określający udział powierzchni ruchu w powierzchni netto,
c) inne powierzchnie, jeżeli nie są pochodną powierzchni użytkowej opisanych wcześniej wskaźników,
d) określenie wielkości możliwych przekroczeń lub pomniejszenia przyjętych parametrów powierzchni i kubatur lub wskaźników. W przypadku budynków, w odniesieniu do szczegółowych właściwości funkcjonalno-użytkowych wyrażonych we wskaźnikach powierzchniowo-kubaturowych, o których mowa w ust. 2 pkt 4, uwzględnia się wymagania zawarte w przepisach wydanych na podstawie art. 34 ust. 6 pkt 1 ustawy z dnia 7 lipca 1994 r. - Prawo budowlane. Wymagania zamawiającego w stosunku do przedmiotu zamówienia określa się, podając odpowiednio, w zależności od specyfiki obiektu budowlanego, wymagania dotyczące:
1) przygotowania terenu budowy;
2) architektury;
3) konstrukcji;
4) instalacji budowlanych;
5) wykończenia;
6) zagospodarowania terenu.
5. Opis wymagań, o których mowa w ust. 4, obejmuje:
1) cechy obiektu dotyczące rozwiązań budowlano-konstrukcyjnych i wskaźników ekonomicznych;
2) warunki wykonania i odbioru robót budowlanych odpowiadających zawartości specyfikacji technicznych wykonania i odbioru robót budowlanych, o których mowa w rozdziale 3.
§ 19. [Część informacyjna programu funkcjonalno-użytkowego]
Część informacyjna programu funkcjonalno-użytkowego obejmuje:
1) dokumenty potwierdzające zgodność zamierzenia budowlanego z wymaganiami wynikającymi z odrębnych przepisów;
2) oświadczenie zamawiającego o posiadanym prawie do dysponowania nieruchomością na cele budowlane;
3) wskazanie przepisów prawnych i norm związanych z projektowaniem i wykonaniem zamierzenia budowlanego;
4) inne posiadane informacje i dokumenty niezbędne do zaprojektowania robót budowlanych, w szczególności:
a) kopię mapy zasadniczej,
b) wyniki badań gruntowo-wodnych,
c) zalecenia konserwatorskie konserwatora zabytków,
d) inwentaryzację zieleni,
e) dane dotyczące zanieczyszczeń atmosfery niezbędne do analizy ochrony powietrza oraz posiadane raporty, opinie lub ekspertyzy z zakresu ochrony środowiska,
f) pomiary ruchu drogowego, hałasu i innych uciążliwości,
g) inwentaryzację lub dokumentację obiektów budowlanych, jeżeli podlegają one przebudowie, odbudowie, rozbudowie, nadbudowie, rozbiórkom lub remontom w zakresie architektury, konstrukcji, instalacji i urządzeń technologicznych, a także wskazania zamawiającego dotyczące urządzeń naziemnych i podziemnych przewidzianych do zachowania oraz obiektów przewidzianych do rozbiórki i ewentualne uwarunkowania rozbiórek,
h) porozumienia, zgody lub pozwolenia oraz warunki techniczne i realizacyjne związane z przyłączeniem obiektu do istniejących sieci wodociągowych, kanalizacyjnych, cieplnych, gazowych, energetycznych i teletechnicznych oraz dróg publicznych, kolejowych lub wodnych,
i) dodatkowe wytyczne inwestorskie i uwarunkowania związane z budową i jej przeprowadzeniem.
§ 20. [Przepisy wyłączone]
Przepisu § 19 pkt 2 nie stosuje się do zamówień na roboty budowlane dotyczące inwestycji w zakresie:
1) linii kolejowych, linii metra i linii tramwajowych realizowanych na podstawie rozdziału 2b ustawy z dnia 28 marca 2003 r. o transporcie kolejowym (Dz. 1984);
2) dróg publicznych realizowanych na podstawie ustawy z dnia 10 kwietnia 2003 r. o szczególnych zasadach przygotowania i realizacji inwestycji w zakresie dróg publicznych (Dz. z 2020 r. 1363 oraz z 2021 r. 784 i 1228);
3) lotnisk użytku publicznego realizowanych na podstawie ustawy z dnia 12 lutego 2009 r. o szczególnych zasadach przygotowania i realizacji inwestycji w zakresie lotnisk użytku publicznego (Dz. 1079);
4) budowli przeciwpowodziowych realizowanych na podstawie ustawy z dnia 8 lipca 2010 r. o szczególnych zasadach przygotowania do realizacji inwestycji w zakresie budowli przeciwpowodziowych (Dz. 1812);
5) regionalnych sieci szerokopasmowych realizowanych na podstawie ustawy z dnia 7 maja 2010 r. o wspieraniu rozwoju usług i sieci telekomunikacyjnych (Dz. 777, 784 i 2333);
6) terminalu lub inwestycji towarzyszących przygotowywanych i realizowanych na podstawie ustawy z dnia 24 kwietnia 2009 r. o inwestycjach w zakresie terminalu regazyfikacyjnego skroplonego gazu ziemnego w Świnoujściu (Dz. 1836);
7) sieci przesyłowych przygotowywanych i realizowanych na podstawie ustawy z dnia 24 lipca 2015 r. o przygotowaniu i realizacji strategicznych inwestycji w zakresie sieci przesyłowych (Dz. 428, 784 i 922);
8) zadań inwestycyjnych określonych w Programie Inwestycji Organizacji Traktatu Północnoatlantyckiego w Dziedzinie Bezpieczeństwa (NSIP), realizowanych na podstawie ustawy z dnia 25 maja 2001 r. o przebudowie i modernizacji technicznej oraz finansowaniu Sił Zbrojnych Rzeczypospolitej Polskiej (Dz. 1221 i 1535);
9) Inwestycji i Inwestycji Towarzyszących realizowanych na podstawie ustawy z dnia 10 maja 2018 r. o Centralnym Porcie Komunikacyjnym (Dz. 1354);
10) strategicznych inwestycji w sektorze naftowym realizowanych na podstawie ustawy z dnia 22 lutego 2019 r. o przygotowaniu i realizacji strategicznych inwestycji w sektorze naftowym (Dz. 1902);
11) inwestycji w zakresie budowy portu zewnętrznego realizowanych na podstawie ustawy z dnia 9 sierpnia 2019 r. o inwestycjach w zakresie budowy portów zewnętrznych (Dz. 1853 i 2368).
Rozdział 5
Przepis przejściowy i przepis końcowy
§ 21. [Stosowanie przepisów dotychczasowych]
1. Do postępowań o udzielenie zamówienia wszczętych i niezakończonych przed dniem 1 stycznia 2022 r., w zakresie opisu przedmiotu zamówienia, stosuje się przepisy dotychczasowe. W celu przygotowania lub przeprowadzenia postępowania o udzielenie zamówienia wszczynanego po dniu 31 grudnia 2021 r. zamawiający może korzystać z dokumentacji projektowej, specyfikacji technicznych wykonania i odbioru robót budowlanych lub programu funkcjonalno-użytkowego, sporządzonych przed dniem wejścia w życie rozporządzenia, o ile w dacie ich sporządzenia spełniały one wymagania określone w rozporządzeniu Ministra Infrastruktury z dnia 2 września 2004 r. w sprawie szczegółowego zakresu i formy dokumentacji projektowej, specyfikacji technicznych wykonania i odbioru robót budowlanych oraz programu funkcjonalno-użytkowego (Dz. z 2013 r. 1129).
§ 22. [Wejście w życie]
Rozporządzenie wchodzi w życie z dniem 1 stycznia 2022 r. 3)
Minister Rozwoju i Technologii: P. Nowak
1) Minister Rozwoju i Technologii kieruje działem administracji rządowej - budownictwo, planowanie i zagospodarowanie przestrzenne oraz mieszkalnictwo, na podstawie § 1 ust. 2 pkt 1 rozporządzenia Prezesa Rady Ministrów z dnia 27 października 2021 r. w sprawie szczegółowego zakresu działania Ministra Rozwoju i Technologii (Dz. 1945).
2) Zmiany wymienionego rozporządzenia zostały ogłoszone w Dz. UE L 329 z 17. 2003, str. 1 - Dz. 6, str. 72, Dz. UE L 74 z 15. 03. 2008, str. 1 oraz Dz. UE L 188 z 18. 07. 2009, str. 14.
3) Niniejsze rozporządzenie było poprzedzone rozporządzeniem Ministra Infrastruktury z dnia 2 września 2004 r. 1129), które traci moc z dniem wejścia w życie niniejszego rozporządzenia zgodnie z art. 97 ustawy z dnia 11 września 2019 r. – Przepisy wprowadzające ustawę – Prawo zamówień publicznych (Dz. 2020 oraz z 2020 r. 1086 i 2275).
- 1. Wstęp
- 2. Do kogo kierowany jest artykuł?
- 3. Przed wyceną
- 4. Doprecyzowanie specyfikacji
- 4. 1. Budowa zestawienia interpretacji i pytań
- 4. 2. Rozmowy z klientem
- 5. Podejścia do wycen
- 5. Top-down
- 5. Bottom-up
- 5. 3. Podsumowanie podejść do wyceny
- 6. Metody wycen
- 6. Problemy z metodami wycen
- 7. Wycena
- 7. Rozpisanie specyfikacji
- 7. Ustalenie priorytetów
- 7. Analiza historyczna
- 7. 4. Ustalenie wielkości velocity
- 7. 5. Estymowanie zadań
- 7. 6. Doliczenie buforów i premii
- 7. 7. Wyliczenie czasu i kosztów realizacji
- 7. 8. Doliczenie lub odliczenie kosztów komunikacji i nauki
- 7. 9. Doliczenie innych kosztów i marży
- 8. Wycena a realizacja
- 9. Podsumowanie
1. Wstęp
Wycena projektów IT zwana również wymiarowaniem i szacowaniem jest jednym z pierwszych procesów wykonywanych po stronie Dostawcy. W mojej pracy korzystałem z różnych metod wycen dostępnych na rynku i dokonując ich analizy, wybrałem praktyki, które moim zdaniem są najbardziej skuteczne w przygotowaniu wyceny.
2. Do kogo kierowany jest artykuł?
- Dostawcy, Właściciele firm IT – Jeśli przymierzasz się do wyceny projektu IT możesz poznać zastosowanie różnych metod wycen w praktyce. Sposób wyceniania opieram na własnych doświadczeniach.
- Osoby i firmy zlecające projekt IT – Jeśli chcesz zlecić wykonanie projektu IT możesz poznać proces wyceny po stronie Dostawcy. Podczas zamówienia i rozmów z Dostawcą jesteś w stanie wpłynąć na ostateczną cenę jaką otrzymasz.
3. Przed wyceną
Kluczowym warunkiem do wykonania wyceny jest specyfikacja przedmiotu, który będziemy wyceniać. Podczas mojej pracy spotkałem się z sytuacją, w której Klient prezentował głównie wizję oprogramowania, często jeszcze nie skończoną. W takich sytuacjach konieczne jest doprecyzowanie specyfikacji, o którym piszę w następnym rozdziale.
Elementy jakie powinna zawierać specyfikacja po krótce opisałem przy okazji wpisu Jak zlecić i przeprowadzić projekt IT?
Przed wykonaniem wyceny powinniśmy wstępnie zastanowić się czy czas poświęcony na wycenę będzie zasadny względem projektu, który wyceniamy? Wycenę można przeprowadzić z różną dokładnością, która pociąga za sobą czas i koszty takiego procesu. W przypadku mniejszych projektów IT długofalowy proces wyceny może być nieopłacalny.
Powinniśmy również zdawać sobie sprawę z ryzyka jakie niesie za sobą wykonanie wyceny. Głównym celem Klienta, który przesłał zapytanie może być tylko zebranie ofert z rynku (tzw. benchmark). Z uwagi na to, że wykonanie wyceny dla Klienta nie jest płatne, Klient może poprosić o nią szereg firm tak, aby dowiedzieć się jakie są różne stawki rynkowe. W takim przypadku praca poświęcona na wycenę nie przyniesie przychodu.
4. Doprecyzowanie specyfikacji
Kiedy spotykamy się z sytuacją, w której Klient przedstawia nam wizję projektu lub jego specyfikacja nie jest dopracowana, najlepszym rozwiązaniem na tym etapie jest przekonanie go do projektu dwuetapowego, który składa się z analizy i opracowania specyfikacji oraz realizacji.
4. Budowa zestawienia interpretacji i pytań
Przed rozpoczęciem rozmów z Klientem możemy przygotować zestawienie interpretacji i pytań, które będzie zawierać określone kolumny przedstawione w przykładzie poniżej:
| Zapisy ze specyfikacji | Interpretacje i pytania |
| WF 01. 001 – System musi pozwalać na obsługę zgłoszeń telefonicznych. | Czy zgłoszenie otrzymane drogą telefoniczną ma zostać zanotowane w systemie? |
| WF 01. 002 – System musi pozwalać na obsługę zgłoszeń mailowych. | Rozumiemy, że po otrzymaniu wiadomości ma ona zostać zarejestrowana w systemie i ma zostać nadany numer identyfikacyjny zgłoszenia. Prosimy o szczegółowe informację w jaki sposób obsługa zgłoszeń mailowych ma zostać zrealizowana? |
| WF 01. 003 – System musi posiadać opracowane skrypty, zgodnie z którymi będą obsługiwane zgłoszenia. | Czy system ma pozwalać na stworzenie skryptu na podstawie udzielonej odpowiedzi? Rozumiemy, że podczas wysyłania odpowiedzi na zgłoszenie operator będzie mógł wyszukać odpowiedni skrypt i wysłać wiadomość ręcznie. |
Z uwagi na powtórzenie w lewej kolumnie treści specyfikacji taka forma jest wygodna dla osób, które przygotowują zestawienie oraz dla Klienta, ponieważ w trakcie sporządzania i czytania nie trzeba szukać określonych punktów.
Jeśli zestawienie jest przesyłane do Klienta w wersji elektronicznej warto wstawić trzecią kolumnę na odpowiedzi.
Przygotowanie powyższego zestawienia może również otworzyć Ci drogę do konstruktywnych rozmów z Klientem na temat projektu dwuetapowego. Klient widząc szereg pytań do poszczególnych punktów specyfikacji sam zauważy, że koniczne jest przeprowadzenie dokładniejszej analizy.
W przypadku zapytań przetargowych również możesz zadawać pytania do Klienta, jednak muszą być one wysłane do połowy wyznaczonego terminu składania ofert. Do tego terminu Klient musi udzielić Ci odpowiedzi, po tym terminie nie ma już takiego obowiązku.
4. Rozmowy z klientem
Niezależnie od jakości specyfikacji bardzo dobrym rozwiązaniem jest nawiązanie relacji z Klientem. Prawdopodobnie podczas rozmowy będziesz mógł uzyskać informacje, które nie są podane w specyfikacji.
Jeśli wysłaliśmy do Klienta zestawienie interpretacji i pytań to powinieneś dążyć do umówienia spotkania roboczego, podczas którego będziesz mógł omówić poszczególne punkty.
Podczas rozmów z Klientem będziesz mógł rozwiać jego obawy związane z projektem dwuetapowym (analiza i opracowanie specyfikacji oraz realizacja).
Warto podkreślić, że w przypadku projektu dwuetapowego Klient tak naprawdę nie ryzykuje, ponieważ opracowana i rozliczona analiza wraz ze specyfikacją wykonana w pierwszym etapie pozostaje jego własnością i może zostać wykorzystana na potrzeby realizacji z innym Dostawcą.
Trzeba zwrócić uwagę, że pierwszy etap projektu obejmujący przeprowadzenie analizy i opracowanie specyfikacji pozwala Ci również na wykonanie szczegółowej wyceny oprogramowania.
Odpowiednia realizacja pierwszego etapu wiąże się również z mniejszym ryzykiem jakie niesie za sobą dalsze kontynuowanie projektu przez Klienta.
5. Podejścia do wycen
Posiadając już specyfikacje umożliwiającą wycenę możemy przejść do wyceny. Poniżej prezentuję dwa podejścia do wyceny: top-down (wycena rynkowa) oraz botom-up (wycena oparta na kosztach dostarczenia rezultatu).
5. Top-down
Jest to podejście, które opiera się na wyliczeniu ostatecznej ceny w oparciu o wartość rynkową oprogramowania.
Wartość rynkową oprogramowania możemy oprzeć na innych cenach, dostępnych publicznie w rozstrzygniętych przetargach. W celu uzyskania cen innych oferentów możemy wystartować w postępowaniu przetargowym z własną ofertą.
Dodatkowym sposobem jest również pozyskanie informacji rynkowych poprzez zapytania kierowane do porównywalnej konkurencji.
Wycenę top-down możemy również wyliczać na podstawie wcześniejszych zamówień danego Klienta oraz wielkości gwarancji jaka jest wymagana w ramach postępowania przetargowego.
Podejście top-down bardzo dobrze sprawdza się w przypadku oprogramowań specjalistycznych, w których jest mniejsza konkurencja na rynku.
W przypadku podejścia top-down ma znaczenie nasza pozycja specjalisty w danej dziedzinie. Jeśli nasza specjalizacja w określonej dziedzinie jest wysoko oceniana, to tym samym Klient jest w stanie zapłacić wyższą cenę, ponieważ gwarantujemy mu dostarczenie wyników wyższej jakości.
Zalety podejścia top-down
- Możliwość uzyskania zdecydowanie wyższej marży. W przypadku wyceny top-down dla określonego typu oprogramowania możemy podać cenę przewyższającą nasze koszty trzy/czterokrotnie (lub więcej). Jest to uzależnione specjalizacją określonego rozwiązania i możliwościami finansowymi po stronie klienta.
- Szybki proces wyceny. Wycena w podejściu top-down może być bardzo rozbudowana i długotrwała, jednak w większości przypadków jest szybsza niż podejście bottom-up.
Wady podejścia top-down
- Zbyt wysoka wycena dla Klienta. Ten przykład można bardzo wyraźnie zaobserwować w ofertach przetargowych, w których ceny oferentów przekraczają kwoty, jakie Klient przeznaczył na realizację przedmiotu zamówienia. Jednym słowem stosując podejście top-down możemy przestrzelić cenę.
- Ryzyko zbyt niskiej ceny. Wycena opierająca się tylko na podejściu bottom-up może pociągać za sobą ryzyko zbyt niskiej ceny, która może być poniżej kosztów realizacji. Rozwiązaniem w takiej sytuacji jest możliwość wykonania wyceny w dwóch podejściach.
5. Bottom-up
Większość metod wycen w przypadku projektów IT odnosi się do modelu bottom-up, czyli wyceny liczonej na podstawie zakresu oraz kosztów dostarczenia rozwiązania.
W dalszych rozdziałach przestawię Ci mój model wyceny bottom-up, który opiera się na istniejących modelach wyceny na rynku.
Zalety podejścia bottom-up
- Zaangażowanie zespołu w mojej ocenie jest ważnym czynnikiem podejścia bottom-up. Członkowie zespołu są zdecydowanie bardziej przekonani do szacunków jakie zostały wykonane, co przekłada się na inne elementy projektu (opisuję to niżej).
- Zmniejszenie ryzyka przekroczenia kosztów. Podejście bottom-up opiera się na analizie kosztów realizacji. Jeśli wycena zostanie przeprowadzona poprawnie (także pod względem ryzyka) nie powinno mieć miejsca przekroczenie kosztów.
Wady podejścia bottom-up
- Długi czas realizacji wyceny. W metodzie jaką prezentuję poniżej należy zaangażować członków zespołu. Analiza, rozpisanie zadań, estymacja mogą trwać zbyt długo i w przypadku mniejszych projektów IT ta metoda może być zbyt droga.
- Brak możliwości skorzystania w możliwości rynkowych. Oferty składane w ramach ofert przetargowych pokazują, że część z firm proponując rażąco niskie ceny traci możliwości rynkowe ustalenia wyższej ceny. Dodatkowo ich oferta może zostać odrzucona przez Klienta.
5. Podsumowanie podejść do wyceny
W przypadku wycen jakie wykonujemy możemy zastosować jedno podejście lub dwa podejścia jednocześnie (top-down i bottom-up). Wykonanie wycen wg dwóch podejść pokazuje nam jak bardzo nasza wycena oparta na kosztach odbiega od wyceny rynkowej.
Poniżej prezentuję przykładowe wyceny w dwóch podejściach wykonane dla dwóch różnych projektów.
Przykład z projektu 1
Jeśli jesteśmy przekonani co do wyceny top-down możemy ją zastosować uzyskując w ten sposób większą marżę w danym projekcie. Przy okazji możemy większą kwotę przeznaczyć na premie dla zespołu (które opisuję niżej).
Przykład z projektu 2
W przypadku, jeśli cena top-down jest niższa możemy ją zastosować obniżając marżę lub też oprzeć się na wycenie składającej się z bottom-up, premii i marży.
6. Metody wycen
Na rynku istnieje szereg metod wycen takich jak:
- Wycena przez analogię
- Wycena ekspercka (indywidualna i grupowa)
- Wycena metodą COCOMO
- Wycena oparta na dekompozycji i rekonstrukcji
- Wycena oparta na zastępstwie
- Wycena metodą punktów funkcyjnych (IFPUG)
- Wycena metodą przypadków użycia (Use Case Point)
- Wycena metodą COSMIC
- i inne
W niniejszym wpisie chciałbym podzielić się techniką, która wynika z mojego własnego doświadczenia i czerpie z wyższej wymienionych metod.
Napisz proszę w komentarzu poniżej lub wyślij wiadomość jeśli chcesz, abym opisał dla Ciebie poszczególne metody wycen.
6. Problemy z metodami wycen
Główny problem z metodami wycen przedstawionymi powyżej (poza Use Case Point – opisuję to poniżej) polega na tym, że nie biorą one pod uwagę kosztów komunikacji i nauki. Z mojego doświadczenia jest to jeden z głównych kosztów podczas realizacji.
Dobrym potwierdzeniem dla wielkości takiego kosztu jest prezentacja, jaką przeprowadził Sławomir Sobótka (link do minuty nagrania), który opowiedział historię i zadał pytanie do zgromadzonych na sali:
„Jeżeli piszemy kodzik przez 2 tygodnie powiedzmy i jakoś magicznie, nie wnikam dlaczego się nie scommitowaliśmy. To ten sam kodzik, jeśli ukradną wam laptopa w ile czasu napiszecie? ”
Z sali padła odpowiedź: „w 2 dni”.
Na prezentacji główną przyczyną takiej różnicy jest proces uczenia. Z mojego doświadczenia uważam, że główna przyczyna to komunikacja z klientem, komunikacja w zespole i proces uczenia się.
Podczas analizy innych projektów powinniśmy zdawać sobie sprawę z tego, że rezultat projektów może być podobny ale koszt komunikacji i nauki jest zazwyczaj zupełnie inny.
Dla przykładu prezentuję Ci poniżej dwa projekty w czasie, których rezultaty były do siebie bardzo zbliżone, jednak koszty komunikacji i nauki wyglądały już zupełnie inaczej.
Zwróć uwagę, mimo tego, że rezultat projektu był bardzo zbliżony to ostatecznie Projekt 1 jest droższy od Projektu 2 o 143 tys. zł.
7. Wycena
Opisane poniżej punkty dotyczące wyceny powinny być realizowane z zespołem, który będzie wykonywał projekt. Nie musi być to pełen zespół, ale np. dwie doświadczone osoby z zespołu.
Co z tego, że opracujemy najlepszą wycenę, zgodną ze standardami i metodologiami, jeśli nie będziemy w stanie zrealizować projektu w tej wycenie 😮
Dlatego uważam, że wycena prowadzona z zespołem jest bardzo ważna nie tylko ze względu na dokładność wyceny, ale również ze względu na późniejszą realizację projektu.
Zespół, który brał udział w procesie wyceny jest zdecydowanie bardziej przekonany do jej wiarygodności. Odpowiedzialność zespołu za taką wycenę jest zdecydowanie większa, co przekłada się również na zachowanie terminowości.
7. Rozpisanie specyfikacji
Pierwszym krokiem jest rozpisanie wymagań specyfikacji na user stores zgodnie ze specyfiką Scrum. Podczas rozpisywania poszczególnych wymagań należy również grupować stworzone user stores w epiki.
Po wykonanym zadaniu powstanie product backlog zgodny z frameworkiem Scrum. Poza samą wyceną stworzony backlog ułatwi również uruchomienie projektu po ewentualnym podpisaniu umowy z Klientem.
7. Ustalenie priorytetów
Jeśli istnieje taka możliwość to warto przeprowadzić ten krok z Klientem. Jeśli Klient zaproponował etapy lub harmonogram to również można go wykorzystać w zakresie ustalania priorytetów.
W innym przypadku ustalenie priorytetów powinno odbywać się na podstawie doświadczenia zespołu.
7. Analiza historyczna
Przegląd wraz z zespołem podobnych projektów pod względem rezultatu, zrealizowanych iteracji, wielkości velocity i wykresów spalania.
Na podstawie tej analizy można określić najbardziej zbliżony projekt i na jego podstawie będzie można oszacować dalsze kroki.
7. Ustalenie wielkości velocity
Wspólnie z zespołem na podstawie danych historycznych określamy wielkość velocity dla szacowanej iteracji, która uwzględnia podstawowy zespół wymagany do realizacji projektu. Dodatkowym szacunkiem, który ustalamy to velocity osoby, która może ewentualnie powiększyć skład zespołu.
Wartość ta będzie potrzeba do obliczenia czasu realizacji projektu.
7. Estymowanie zadań
Estymowanie może odbywać się elektronicznie (np. w arkuszu Google gdzie każdy estymujący ma swoją kolumnę) lub też za pomocą Scrum pokera. Zgodnie z szacowaniem Scrum wszyscy członkowie zespołu powinni się zgodzić co do estymacji danego user stories.
Scrum poker jest ciekawym rozwiązaniem, ponieważ dodatkowo integruje zespół i zachęca do rozmów o poszczególnych zadaniach. Z mojego doświadczenia wynika, że elektroniczne estymacje powodują mniejsze zaangażowanie członków zespołu.
Szacowanie może odbywać się za pomocą punktów 1/2, 1, 2, 3, 4 lub za pomocą ciągu Fibonacciego (1, 2, 3, 5, 8, 13, 21). Osobiście bardzo polecam szacowanie za pomocą ciągu Fibonacciego, w mojej ocenie zdecydowanie lepiej oddaje realia pracy.
Odnośnie samego ciągu Fibonacciego polecam również ten film.
7. Doliczenie buforów i premii
Bufory
W zależności od specyfiki danego projektu możesz doliczyć bufory czasowe. Bufory stosuje się zazwyczaj przed zakończeniem jakiegoś określonego etapu w projekcie. Zgodnie z własnym doświadczeniem – na bufory doliczam dodatkowo do szacowanego czasu od 10% do 30%.
Premie
Premie dla pracowników są wypłacane za dotrzymanie ustalonych terminów w projekcie. Wpływają one pozytywnie na zaangażowanie i motywację pracowników. Pracownicy czują się w większym stopniu właścicielami projektu jaki prowadzą.
W projektach bardzo często pojawiają się kary dla Dostawcy za niedotrzymanie terminu. W projektach przetargowych mogą dotyczyć każdego dnia opóźnienia. W celu obniżenia tego ryzyka lepszym rozwiązaniem jest ustalenie premii dla pracowników. Pracownicy będą mieli świadomość, że jeśli się spóźnią to nie otrzymają premii a środki finansowe będą przekazane na pokrycie kar.
7. Wyliczenie czasu i kosztów realizacji
Na podstawie szacowanego velocity iteracji oraz estymacji zadań jestem w stanie obliczyć czas realizacji projektu.
Przykładowo:
Planowana iteracja trwa tydzień czasu, w ciągu iteracji trzyosobowy zespół jest w stanie zrealizować zadania o łącznej wartości 46 punktów. Łączna liczba zadań oszacowanych w projekcie to 318 punktów.
Dzieląc 318 przez 46 otrzymujemy liczbę tygodni jaka jest potrzeba do przeprowadzenia projektu. W tym przykładzie wynosi ona 6, 91.
Do wyliczonej liczby tygodni dodajemy nasz bufor czasowy w wysokości 20% i otrzymujemy w zaokrągleniu wartość 8, 3 tygodnia.
Następnie uzyskany wynik mnożę przez liczbę członków zespołu i ich wynagrodzenia w skali tygodnia.
Otrzymuję w ten sposób kwotę kosztów realizacji wraz z buforem czasowym.
7. Doliczenie lub odliczenie kosztów komunikacji i nauki
W tym kroku doliczam, odliczam lub pozostawiam bez zmian szacowaną wartość projektu biorąc pod uwagę czynniki zewnętrzne, koszty komunikacji i nauki.
Kwota obliczona w poprzednim kroku zawiera już w sobie koszty czynników zewnętrznych, komunikacji oraz nauki, dlatego zadaniem na tym kroku jest określenie jakie są różnice pomiędzy projektem analogicznym a aktualnie wycenianym.
W zależności od różnic doliczam, odliczam lub pozostawiam bez zmian szacowaną wartość projektu. Działanie to wykonuję poprzez ustanie wartości procentowej.
Wyżej napisałem „poza metodą Use Case Point”. Jest to podyktowane tym, że metoda ta zakłada szacowanie złożoności środowiska. Wykorzystuję punkty z tej metody aby ocenić złożoność środowiska.
Punkty oceny złożoności środowiska z metody Use Case Point:
- E1 – Znajomość przez zespół dziedziny problemu, technicznych aspektów i metodyki w jakiej jest realizowany projekt.
- E2 – Doświadczenie zespołu (szeroko pojęte).
- E3 – Doświadczenie zespołu w projektowaniu aplikacji obiektowych i znajomość standardów projektowania.
- E4 – Doświadczenie i umiejętności analityka.
- E5 – Motywacja zespołu.
- E6 – Stabilność wymagań tworzonego systemu.
- E7 – Pracownicy nieetatowi zaangażowani w projekcie.
- E8 – Trudność języka programowania.
Dodatkowo oceniam również punkty:
- Relacja z Klientem, możliwości negocjacji i egzekucji odbiorów.
- Struktura organizacyjna Klienta:
Czy klient posiada rozbudowaną hierarchię, która ma wpływ na komunikację i odbiory w projekcie? Jest to ważny punkt w przypadku projektów realizowanych dla instytucji rządowych. - Wiedza technologiczna Klienta:
Czy klient po swojej stronie posiada kompetentną osobę w zakresie wytwarzania oprogramowania? - Forma i jakość komunikacji z Klientem:
Np. czy jest możliwa komunikacja za pomocą wideokonferencji. Wiem, że to standard, jednak są klienci, którzy nadal preferują klasyczne formy komunikacji (np. korespondencja listowna).
Przykładowo po sumarycznej analizie punktów wynik może wskazać, że w danym projekcie muszę zwiększyć wartość szacowanej wyceny o 30%.
7. Doliczenie innych kosztów i marży
Ostatnim z kroków jest doliczenie innych kosztów oraz marży. Inne koszty mogą wynikać z oceny ryzyka (np. projekt posiada wysoki poziom kar i krótkie terminy realizacji).
Do innych kosztów możemy również zaliczyć koszty pośrednie, takie jak: wynajmy, dojazdy, delegacje, koszty zarządu, księgowości i obsługi prawnej, itp.
Ostatnim punktem jest marża, która może być jednoznacznie ustalona przez firmę (np. 30-70% wartości szacowanego projektu) lub może być wyliczana indywidualnie dla projektu. W przypadku indywidualnego wyliczenia marży pomocne jest również przeprowadzenie wyceny podejściem top-down, którą opisałem powyżej.
8. Wycena a realizacja
Naturalne jest to, że wycena będzie odbiegać od realizacji i twarde trzymanie się jej może być szkodliwe dla rezultatów projektu.
Warto jednak posiadać wycenę, która jest spójna z frameworkiem Scrum, ponieważ podczas prowadzenia retrospektywy w zespole będziesz mógł wspólnie przeanalizować, jakie elementy wpłynęły na różnicę pomiędzy wyceną a realizacją.
Na podstawie realizacji można co pewien okres aktualizować dane szacunkowe (wprowadzać rzeczywistą wielkość velocity oraz wartość punktową poszczególnych zadań). W ten sposób będziesz mógł uzyskiwać coraz dokładniejszy plan oparty na rzeczywistym działaniu.
9. Podsumowanie
Opisana przeze mnie metoda nie jest najtańszą i najszybszą metodą wyceny, jednak bardzo dobrze się sprawdza. Z uwagi na koszy jej przeprowadzenia jest dedykowana dla projektów powyżej 100 tys. Poniżej takiej wartości projektu koszt angażowania całego zespołu do wyceny może być zbyt wysoki.
Projekt w dolnym przedziale powinien zająć ok. 8 godzin wyceny w zespole. Biorąc pod uwagę 3 osobowy zespół (PM + dwie doświadczonych developerów) to otrzymujemy koszt wyceny na poziomie od 2 do 3 tys.
W przypadku mniejszych projektów optymalnym rozwiązaniem jest indywidualna wycena eksperta. Jeśli dany ekspert będący na stanowisku Analityka lub PMa brał udział w wielu wycenach zespołowych będzie w stanie coraz lepiej oceniać koszty realizacji projektu.
Jeśli prowadziłeś już wycenę projektu IT podziel się proszę w komentarzu Twoimi doświadczeniami.
Zapraszam Cię również do subskrypcji bloga.
Od czterech lat nie pisaliśmy o specyfikacjach technicznych wykonania i odbioru robót, ale że nadal są one traktowane zarówno przez większość Zamawiających, jak i przez autorów piszących je (często poważne biura projektowe) jako opracowania zbędne, postanowiliśmy powrócić do tematu.
ZAWARTOŚĆ I UKŁAD SPECYFIKACJI
W rozporządzeniu Ministra Infrastruktury z 2 września 2004 r. ustalono jednolity, usystematyzowany układ specyfikacji, obowiązujący niezależnie od tego czy specyfikacje dotyczą grup robót, rodzajów robót czy robót podstawowych.
Zgodnie z rozporządzeniem nie występuje podział specyfikacji na szczegółowe i ogólne specyfikacje techniczne.
W rozporządzeniu jest mowa o specyfikacjach technicznych, przy czym przewidziano możliwość opracowania tzw. ogólnej specyfikacji technicznej, w której można ujmować wspólne wymagania dotyczące robót objętych przedmiotem zamówienia. Nie ma bowiem potrzeby aby powtarzać takie same informacje, dane i wymagania w poszczególnych specyfikacjach.
Specyfikacje techniczne wykonania i odbioru robót budowlanych są opracowaniami zawierającymi zbiory wymagań, które są niezbędne do określenia standardu i jakości wykonania robót, w zakresie sposobu wykonania robót budowlanych, właściwości wyrobów budowlanych oraz oceny prawidłowości wykonania poszczególnych robót.
W celu spełnienia tych zadań specyfikacje techniczne powinny jasno określać:
1) wymagane właściwości materiałów i wyrobów oraz sposób kontroli tych właściwości w warunkach budowy,
2) reguły jakie powinny być przestrzegane przy wykonywaniu robót, stanowiące uzupełnienie i uszczegółowienie opisów zawartych w projektach,
3) wymagania i podstawy techniczno-organizacyjne dla potrzeb odbiorów i rozliczeń wykonanych robót.
Określona w § 14 ust. 1 rozporządzenia zawartość specyfikacji ujęta w 10 punktach odpowiada stosowanej od lat w krajach zachodnich praktyce a także wprowadzonym w latach dziewięćdziesiątych i stosowanym w drogownictwie układem specyfikacji i obejmuje:
1) część ogólną,
2) wymagania dotyczące wyrobów budowlanych,
3) wymagania dotyczące sprzętu i maszyn,
4) wymagania dotyczące środków transportu,
5) wymagania dotyczące wykonania robót budowlanych,
6) opis działań związanych z kontrolą, badaniami oraz odbiorem wyrobów i robót budowlanych,
7) wymagania dotyczące przedmiaru i obmiaru robót,
8) opis sposobu odbioru robót budowlanych,
9) opis sposobu rozliczenia robót tymczasowych i prac towarzyszących,
10) dokumenty odniesienia.
W celu poprawnego opracowania specyfikacji technicznych każda specyfikacja, z wyłączeniem tzw. ogólnej specyfikacji, powinna składać się z 10 punktów, co nie oznacza, iż zawsze w każdym punkcie (w szczególności dotyczy to punktów 2-5) muszą być sformułowane szczególne wymagania.
W punkcie 1 specyfikacji, czyli w „części ogólnej” należy podać w szczególności:
- nazwę nadaną zamówieniu przez zamawiającego (chodzi o nazwę, która będzie wpisana przy wypełnianiu formularza ogłoszenia);
- przedmiot i zakres robót budowlanych, objętych daną specyfikacją, co jest szczególnie ważne dla potrzeb późniejszego opracowania przedmiaru,
- wyszczególnienie i opis prac towarzyszących i robót tymczasowych (przykładowo: prace towarzyszące obejmują opracowanie szczegółowego harmonogramu wykonania prac w poszczególnych pomieszczeniach, uzgodnionego z ich użytkownikami; roboty tymczasowe obejmują: wykonanie (montaż i demontaż) rusztowań klatek schodowych, wykonanie zabezpieczeń podłóg i sprzętu,...... ); w punkcie tym istotne jest wskazanie wszystkich robót i prac, których obowiązek wykonania należy do wykonawcy robót budowlanych, a których sposób wyceny i rozliczeń jest określony w dalszej części specyfikacji (patrz pkt 9);
- informacje o terenie budowy (nie ujęte w dokumentacji projektowej) zawierające wszystkie niezbędne dane istotne z punktu widzenia:
- organizacji robót budowlanych,
- zabezpieczenia interesów osób trzecich,
- ochrony środowiska,
- warunków bezpieczeństwa pracy,
- zaplecza dla potrzeb wykonawcy,
- warunków dotyczących organizacji ruchu,
- ogrodzenia,
- zabezpieczenia chodników i jezdni;
- w zależności od zakresu robót budowlanych objętych przedmiotem zamówienia nazwy i kody:
- grup robót,
- klas robót,
- kategorii robót;
- określenia podstawowe, zawierające definicje pojęć i określeń nigdzie wcześniej nie zdefiniowanych, a wymagających zdefiniowania w celu jednoznacznego rozumienia zapisów dokumentacji projektowej i specyfikacji technicznej wykonania i odbioru robót budowlanych.
W punkcie 2 specyfikacji należy wyszczególnić materiały, ze wskazaniem wyrobów budowlanych, stosowane do wykonania robót z określeniem ich właściwości, zakresu i metod badań w nawiązaniu do dokumentów odniesienia, a także sposób opakowania danego materiału, wymagania dotyczące transportu, wyładunku, składowania lub magazynowania, w zakresie mającym wpływ na wymagany standard i jakość wykonania robót; w szeregu wypadkach zamawiający w uzgodnieniu z autorem specyfikacji może podjąć decyzję, że zadowalające są wymagania określone projektami i wówczas w tym punkcie wystarczającym będzie zapis: „zgodnie z projektami”.
W punktach 3 i 4 należy podać wymagania dotyczące rodzaju i parametrów technicznych sprzętu oraz środków transportu wymaganych lub zalecanych do stosowania ze względu na rodzaje wbudowywanych materiałów, wyrobów, urządzeń i konstrukcji, a także warunki lokalizacyjne i organizacyjne; podobnie jak w punkcie 2 możliwa i spotykana jest sytuacja, gdy nie ma potrzeby formułowania ograniczeń i zaleceń odnośnie użycia sprzętu oraz środków transportu, ale wówczas należy o tym poinformować wykonawcę poprzez odpowiedni zapis np. „brak wymagań”, pamiętając o ewentualnych zapisach w SIWZ dotyczących wymagań odnośnie dysponowania przez Wykonawcę określonym potencjałem technicznym.
Punkt 5 specyfikacji powinien zawierać opis wymaganej techniki wykonania robót z podaniem sposobu wykończenia poszczególnych elementów, tolerancji wymiarowych, szczegółów technologicznych oraz wymagań specjalnych; możliwym i celowym jest przy tym odpowiednie wykorzystanie norm, aprobat technicznych oraz wydawnictw zawierających warunki techniczne wykonania i odbioru robót jako dokumentów odniesienia.
Zgodnie z rozporządzeniem punkt 6 specyfikacji ma zawierać opisać działań związanych z kontrolą, badaniami oraz odbiorem wyrobów i robót budowlanych w nawiązaniu do dokumentów odniesienia; w szczególności należy określić zasady kontroli jakości stosowanych wyrobów i wykonanych robót, w tym dotyczące pobierania próbek, badań i pomiarów zgodnie z wymaganiami norm, a w przypadku, gdy normy nie obejmują jakiegokolwiek badania stosując wytyczne krajowe albo inne procedury, zaakceptowane przez zarządzającego realizacją umowy.
Wyżej opisane punkty specyfikacji (od 2 do 6) mogą i powinny w jak najszerszym zakresie uwzględniać normy, aprobaty, specyfikacje techniczne i systemy odniesienia, o których mowa w art. 30 ust. 1÷3 ustawy Prawo zamówień publicznych. Należy bowiem pamiętać, że zgodnie z ustawą o normalizacji (art. 5 ust. 3) normy stosuje się na zasadzie dobrowolności. [1] Jednocześnie przy opisie wymagań za pomocą norm i innych wymienionych w ustawie dokumentów odniesienia, koniecznym jest wskazanie, że dopuszczalne są rozwiązania równoważne (art. 4 ustawy Pzp).
Punkt 7 dotyczący przedmiaru i obmiaru wymaga szczególnej uwagi, gdyż treść tego punktu warunkuje właściwe opracowanie przedmiaru a w konsekwencji w wielu wypadkach bezkonfliktowe rozliczenie robót z wynagrodzeniem kosztorysowym. Obecnie, w związku z odejściem przed wieloma laty od urzędowego charakteru bazy normatywnej do kosztorysowania (katalogów), zawierającej obowiązujące zasady opracowania przedmiarów dla poszczególnych rodzajów robót, żaden akt prawny nie określa jak opracować przedmiar robót. Tym samym, to
w specyfikacji technicznej należy dokładnie sprecyzować wg jakich reguł będą obmierzane i obliczane ilości robót. Wskazanym jest wykorzystanie odpowiednio zasad opisanych szczegółowo w bazie normatywnej – Katalogach Nakładów Rzeczowych (KNR) lub innych tego typu wydawnictwach.
Treść tego punktu będzie oczywiście zróżnicowana przede wszystkim w zależności od zakładanej formy wynagrodzenia oraz przyjętych podstaw i zasad kalkulacji ceny i rozliczenia robót budowlanych.
W punkcie 8 należy szczegółowo opisać procedury (zasady, tryb) i podstawy dokonywania odbiorów robót ze szczególnym uwzględnieniem robót zanikających, odbiorów częściowych, odbioru końcowego i odbioru pogwarancyjnego.
Punkt 9 specyfikacji powinien zawierać określenie sposobu rozliczenia robót tymczasowych i prac towarzyszących wymienionych w punkcie 1 specyfikacji w szczególności ustalenia dotyczące tego, czy będą rozliczane odrębnie czy w ramach rozliczenia robót podstawowych. Od tych ustaleń zależy bowiem, czy roboty tymczasowe mają stanowić odrębne pozycje przedmiarowe, a prace towarzyszące mają stanowić przedmiot odrębnej kalkulacji ceny i rozliczenia poza robotami budowlanymi.
W punkcie 10 specyfikacji technicznej należy wymienić wszystkie wskazane jako obowiązujące przy wykonywaniu określonych w specyfikacji robót budowlanych dokumenty odniesienia niezależnie od ich przywołania w specyfikacji, załączając te spośród nich, które mogą być niedostępne dla wykonawcy. Wpisanie jako dokumenty odniesienia norm krajowych innych krajów (np. DIN) oraz wydawnictw zagranicznych może skutkować zastrzeżeniami, pytaniami a nawet protestami wykonawców, domagających się przekazania /udostępnienia tych opracowań.
PODSUMOWANIE
Z przedstawionego zestawienia i opisu zawartości specyfikacji technicznej wykonania i odbioru robót budowlanych wynika, że:
- tylko część punktów może i powinna być opracowana w wyniku zlecenia na zewnątrz, np. przez biuro projektowe,
- ze względu na zakres danych zawartych w specyfikacji i przedmiarze, specyfikacje powinny być opracowane przed wykonaniem przedmiaru robót,
- specyfikacje techniczne, ponieważ zawsze występują łącznie z dokumentacją projektową, nie powinny dublować informacji, danych i wymagań zawartych w dokumentacji projektowej,
- w opracowanie specyfikacji powinien na bieżąco być zaangażowany zamawiający przekazując piszącemu specyfikacje ustalenia i wymagania będące w jego właściwości oraz uzgadniając proponowane rozwiązania.
W przypadku, gdy przedmiotem zamówienia jest wykonanie robót nieskomplikowanych pod względem technicznym i niewymagających pozwolenia na budowę, specyfikacje techniczne mogą być oczywiście w całości opracowane przez samego Zamawiającego.
Podsumowując, jeszcze raz warto podkreślić kluczowe znaczenie specyfikacji zarówno na etapie udzielania zamówienia jak i późniejszej jego realizacji, o czym powinni pamiętać przede wszystkim Zamawiający, ale również Wykonawcy ubiegający się o zamówienie.
[1] przyp. red. : zapraszamy do zapoznania się z zamieszczonym w Dziale Prawnym komunikatem MI "Stosowanie Eurokodów w projektowaniu budynków"
Wydanie:
BUDUJ Z GŁOWĄPoradnik Kosztorysanta nr 2/2010
