Some day, somewhere in the net there was iBlog. It was about everything and nothing. A few persons was reading it, some of them maybe even liked it. But I am not interested in writing about myself anymore. This blog will be about Project Management. Less personal, but in fact it will be my personal tool: to not forget what I have learnt. And what I ll learn in future.
RSS
piątek, 22 lutego 2008

Some people think processes are unneeded bueraucratic burden. Some people think processes make engineers' work unpleasant make them sink in papers, instead of doing their job. Some people think processes forbid them to improve anything, change the way they work even if the way is silly, inefficient or error prone.

But a good process description can be a one screen long Wiki page, with a snapshot of a handwritten lifecycle drawn on your whiteboard. And such a process description may be good enough to pass a CMMI audit.

But do you know why I do like processes so much? ...

Because I like to change them. It is very difficult to change something if something does not exist. If you don't have your baseline, you don't know what the f**k is going on and what to change.

Writing a one-pager process description is about two-three hours of talking with engineers and one hour of writing. Then you can change the way your people work in any way you could imagine. Try to do this if you don't have a process.

 

czwartek, 21 lutego 2008

Where is Quality? Who creates Quality? Who can improve Quality? When should you check Quality?

Quality is not free. Everyone who knows ISO or CMMI, knows this fact and knows that even if not free, Quality is still cheaper than lack of Quality.

But not everyone realizes that Quality is Everywhere.  And you cannot have Quality by having a one, big check after some stage. There are some methodologies having lengthy audits and review phases at the end of each stage of the project. And these methodologies either fail or make your project ridicously long. And make your people to paint the grass green.

And there are also aproaches knowing about Quality is Everywhere. These approaches measure everything in background. They foster open communication and innovative thinking. They give managers quick feedback and prompt warnings, just after something wrong could happen - not months or years after.  They detect real problems and not only issues of "not enough kilogrammes of documents" class.

If you choose any methodology to improve your quality and your projects, whether it is ADP, CMMI, ISO, PMBOK, PMI, whatever - remember:

  • Quality is Everywhere: measure it as early as possible, only when you trust data is reliable, and in background
  • Quality is Everywhere: defects prevention is always better then defects detection
  • Quality is Everywhere: never blame people on errors. If you are Quality Manager, Project Manager, Engineering Manager - low quality is always your fault because you haven't set up proper Quality Management System. It's not a fault of your people, it's not a fault of engineers.
  • Quality is Everywhere: but you cannot have it without time spent for it.

So you can ask: I have a low quality project. I don't have resources for improving quality. What should I do. Where should I look for help?

LEAN can respond to your question: help yourself and clean up the things first. This doesn't cost you a broken penny. Ensure that you use bug tracking system. Ensure that your people know what to do next. Ensure they know what they do. Ensure that they have some backup and are not irreplacable heroes, because it's too big responsibility for any single person to be irreplaceable. Then - you'll easily find out next steps.

I hope I'm also able to clean up the things first and find out next steps.

Gdy przychodzi mail z recepcji że przyszedł pan sprzedający kanapki, a Ty, czytając ten mail popołudniu, pół minuty zastanawiasz się, czy można już go oznaczyć jako przeczytany.

(zdarzenie autentyczne)

niedziela, 17 lutego 2008

Stary osioł wpadł do wyschniętej studni. Gospodarz stwierdził że nie da rady go wydostać, osioł już stary, strata niewielka, więc trzeba go pogrzebać. Zaczął więc sypać ziemię do studni. Osioł na początku ryczał w niebogłosy, ale po chwili ucichł zupełnie. Gospodarz sypie, sypie, ale w końcu cisza go zaniepokoiła, więc zajrzał do studni.

Co się okazało? Osioł po każdej łopacie ziemi otrzepywał się z niej i udeptywał pod sobą. Jeszcze kilka łopat, wygramolił się ze studni i zadowolony podreptał na łąkę.

czwartek, 07 lutego 2008

Dzisiaj na SPIN pan Bogdan Bereza-Jarociński reklamował nową metodologię, z której będzie prowadził szkolenia i certyfikował: Automated Defect Prevention .

Wykład był naprawdę fajny, pan Bereza wykazał się nie tylko wiedzą ale i swoim talentem oratorskim. Automated Defect Prevention, to świetna filozofia. I tylko jedna rzecz mnie wkurzyła: przeciwstawianie na siłę standardu CMMI do tego nowego, kochanego przez Pana Bogdana ADP.

Wdrażałem CMMI. Znam go na wyrywki. Przeczytałem od dechy do dechy specyfikację modelu. Zgłaszałem do autorów błędy modelu. Wiem, jak zaimplementować High Maturity Levels (poziom 4 i 5). I nie zgodzę się na deprecjonowanie CMMI jako czegoś ciężkiego, biurokratycznego i nie promującego doskonałości.

Każdy, kto widział dobrze zrobionego CMMI, wie co to znaczy:

  • lekkie, automatycznie mierzalne procesy
  • procesy projektowane przez ich wykonawców (inżynierów), którzy wkładają w to serce i swoje niezrównane umiejętności, wiedzę i inteligencję
  • procesy doskonalone przy każdej okazji
  • automatyzowane testy, buildy, release'y, code review, pomiary
  • procesy, o które staramy się żeby były ergonomiczne i przyjazne dla ludzi (ADP'owskie Happy People)
  • wykształcenie kultury firmowej promującej szacunek do standardów i procesów
  • ale też promującej świadomość, że procesy są po to, żeby było wiadomo co się zmienia

Ja nie wyobrażam sobie innego CMMI. A takiemu CMMI nie brakuje żadnego ze składników, które pretenduje sobie ADP.

Tak, słyszałem o takich wdrożeniach CMMI, o jakich mówił Pan Bogdan. Tak, można spierdolić CMMI.

I gwarantuję, że za 3 lata będzie mnóstwo firm które będą twierdzić że mają ADP, a tak naprawdę (a) nie będą miały nic, albo (b) będą miały równie ciężkie i sztywne procesy jak te, którymi tak straszył Pan Bogdan w CMMI.

Podsumowując: przeczytajcie o ADP. A następnie: wdrażajcie CMMI, pamiętając o tym co przeczytaliście.