Friday Oct 17, 2014

Când Alegem Agile?

Care este cea mai bună abordare pentru a realiza un proiect software?




Introducere
Ca Manager de Proiect, când începem un nou proiect software, avem mereu această dilemă: Care este cea mai bună abordare pentru dezvoltare, pe care să o utilizăm? Există mai multe modele şi abordări disponibile astăzi, care se potrivesc unei varietăţi de proiecte și procese organizaționale. Cele mai populare și de succes dintre acestea sunt Waterfall (Cascadă) şi Agile.

În continuare, voi prezenta cele două abordări, argumentele pro şi contra ale fiecăreia şi mai multe criterii pentru a decide care model ar fi cel mai potrivit pentru proiectul sau organizaţia dumneavoastră.

Waterfall (predictiv)
Abordarea Waterfall, uneori referită ca "Big Design Up Front", este un model care începe cu o fază de iniţiere şi apoi continuă de la o fază la alta într-o manieră pur secvenţială. Avem de obicei 5 faze principale: Cerinţe, Design, Implementare, Verificare şi Mentenanţă.





Agile (adaptiv)
Agile se referă la o abordare iterativă, în care cerinţele şi soluţiile evoluează prin colaborarea dintre client și echipa de dezvoltare. Cu alte cuvinte, abordarea Agile înseamna că tu creezi livrabilele mai devreme și le rafinezi cu clientul prin mai multe iteraţii.




Modelul Hibrid
Multe proiecte folosesc un model hibrid. În acest caz, există două abordări: Utilizare Agile în Waterfall şi Utilizare Waterfall în Agile.

Efectuarea alegerii între Agile şi Waterfall
Deci, cum alegem?
Luăm în considerare următorii factori (dar şi alţii) atunci când analizăm ce abordare vrem să utilizăm:

Factorii de mai sus nu sunt ponderaţi în mod egal; fiecare este evaluat în funcţie de proiect şi circumstanţe.

Este important, ca Manager de Proiect, să selectăm abordarea care satisface cel mai bine nevoile clientului. Fiecare abordare ne ajută să realizăm proiectul, dar trebuie să o alegem pe aceea care aduce cea mai mare valoare de business, respectând constrângerile proiectului.


When Choosing Agile?

What is the best approach to achieve a software project?


Introduction
As Project Manager, when we start a new software project, we always have this dilemma: What is the best development approach to use? There are many models and approaches available today that can suit a variety of projects and organizational processes. The most popular and successful of these have been the Waterfall and Agile.

Next, I will present the two approaches, the pros and cons of each one and several criteria to decide which model would be the best fit for your project or organization.

Waterfall (predictive)
The Waterfall approach, sometimes referred to as "Big Design Up Front", is a model that begins with one initiation phase and then proceeds from one phase to the next in a purely sequential manner. We have usually 5 main phases: Requirements, Design, Implementation, Verification and Maintenance.




Agile (adaptive)
Agile refers to an iterative approach, where requirements and solutions evolve through collaboration among customer and development team. In other words, the Agile approach means that you create deliverables early and refine them through several iterations with the customer.




Hybrid Model
Many projects use the hybrid model. In this case, there are two approaches: Using Agile within Waterfall and Using Waterfall within Agile.

Making the choice between Agile and Waterfall
So, how do we choose?
We consider the following factors (but also others) when analyzing which approach to use:

The factors above are not equally weighted; each is assessed depending on the project and circumstances.

It’s important, as Project Manager, to select the approach that best satisfies your customer needs. Each approach can deliver your project, but you have to choose the one that brings the greatest business value, within the project constraints.


Tuesday Jun 03, 2014

Shaving the Elephant (How Project Managers waste valuable time)



Introduction
Time is a very precious resource for every project. However, the project team wastes time with various ineffective activities. In this document I will present how Project Managers waste valuable time and how to avoid this. Some of the topics could be also applied to the project team.

Do we really need to shave the elephant?

Let's assume that one of the tasks of the project is to wash an elephant. We can do it simply and directly, or we can first shave the elephant. It’s really necessary to do this? Why people waste their time with useless activities?

The Project Management has become very complex, regardless of the chosen methodology. The project budgets and durations have decreased and the number of allocated resources is generally limited. In this situation, a Project Manager must simultaneously monitor the accomplishment of project objectives, overcome the constraints and be careful not to waste valuable time for unnecessary activities.

We don’t need to shave the elephant. We need to resist the temptation to add work that doesn’t directly contribute to the final deliverables. The Project Managers should determine what is a value-added to their project, processes and documentation. Replacing non value-added work to make more room for value-added work will increase the likelihood of project success.

12 reasons for wasting time by Project Managers

• Ineffective communication with the project stakeholders (poor Communication Plan, non-using collaborative tools, etc)
• Ineffective project planning (generating many subsequent changes and thus additional time for project monitoring)
• Ineffective risk management (too much time spent to define mitigation actions for low impact risks, etc)
• Roles, responsibilities and authorities are nor clearly defined (involving waste of time in resource allocation on tasks and making decisions)
• Random prioritization of activities
• Attending too many meetings
• Reading and writing a lot of emails (especially the useless ones)
• Performing micromanagement (excessive control or attention on details)
• Getting involved in "doing the work" (managing projects is a full-time job and taking your eye off the ball can lead to problems)
• Making larger documents than necessary or unnecessary documents
• Repetitive processes are not streamlined or automated
• Bad choice of project tools

How to avoid the wasting of time

Many people say "I need to get better organized" but this is not a specific goal. A better question is "What do I need to be more organized?". The Project Managers need to know the problems they are facing and what would be the specific ways to solve them.

How to avoid the wasting of time? First, eliminate the reasons presented in the previous section. Second, recognize that you’ll never get everything done, but you certainly can get the most important things done. Set a limited number of priorities per day and then enjoy getting all of them done, because progress is motivational.

Remember the Pareto Principle. The value of this for a Project Manager is that it reminds you to focus on the 20% of activities that matter. Of the activities you do during your project, only 20% are important. Those 20% produce 80% of your results. Identify and focus on those activities.

Don’t overestimate your forces and be realistic when you set deadlines. When you exceed the planned time, your self-confidence decreases and the delay increases much more. We have the same amount of working time like others: 8 hours per day. It’s our choice what and how we do in this time. Achieving small goals (and small successes) will lead to the fulfillment of bigger objectives (and great successes).

Conclusions
The Project Manager has to be far most selective. Instead of trying to do everything, he must pursue the right things, for the right reasons, at the right time. By doing fewer things, better he can make a higher contribution.

Shaving the elephant could be an excellent idea in a video advertising for the last razor model. But if we want to do a documentary about the animals life in savannah, I don’t believe is the most interesting thing.

Bărbierirea Elefantului (Cum pierd timp preţios Managerii de Proiect)




Introducere
Timpul este o resursă foarte preţioasă pentru fiecare proiect. Cu toate acestea, echipa de proiect pierde timpul cu diverse activităţi ineficiente. În acest document voi prezenta cum pierd timp preţios Managerii de Proiect şi cum se poate evita acest lucru. Unele aspecte ar putea fi de asemenea aplicate echipei de proiect.

Chiar avem nevoie să bărbierim elefantul?
Să presupunem că una dintre activităţile proiectului este spălarea unui elefant. Putem face acest lucru în mod simplu şi direct, sau putem mai întâi să bărbierim elefantul. Este într-adevăr necesar să facem aceasta? De ce oamenii îşi pierd timpul cu activităţi inutile?

Managementul de Proiect a devenit foarte complex, indiferent de metodologia aleasă. Bugetele şi duratele proiectelor au scăzut şi numărul de resurse alocate este în general limitat. În această situaţie, un Manager de Proiect trebuie simultan să monitorizeze realizarea obiectivelor proiectului, să depăşească constrângerile şi să aibă grijă să nu piardă timp preţios pentru activităţi care nu sunt necesare.

Nu avem nevoie să bărbierim elefantul. Avem nevoie să rezistăm tentaţiei de a adăuga muncă care nu contribuie în mod direct la livrabilele finale. Managerii de Proiect trebuie să determine ceea ce este valoare adaugată pentru proiectul lor, pentru procese şi documentaţie. Înlocuirea activităţilor fără valoare adăugată cu cele care aduc valoare adăugată, va creşte probabilitatea de succes a proiectului.

12 motive ale pierderii timpului de către Managerii de Proiect
• Comunicarea ineficientă cu actorii proiectului (eng: project stakeholders) (Plan de Comunicare deficitar, neutilizarea instrumentelor colaborative, etc)
• Planificarea necorespunzătoare a proiectului (care generează multe schimbări ulterioare şi implicit, timp suplimentar pentru monitorizarea proiectului)
• Managementul ineficient al riscurilor (prea mult timp dedicat pentru definirea acţiunilor de reducere a riscurilor cu impact redus, etc)
• Rolurile, responsabilităţile şi autorităţile nu sunt clar definite (care implică pierdere de timp în alocarea resurselor pe taskuri şi în luarea deciziilor)
• Prioritizarea aleatorie a activităţilor
• Participarea la prea multe reuniuni
• Citirea şi scrierea de foarte multe emailuri (în special a celor inutile)
• Efectuarea de micromanagement (control excesiv sau atenţie exagerată asupra detaliilor)
• Implicarea în "munca propriu-zisă" (gestionarea proiectelor este un job full-time şi dacă îţi iei ochii de pe minge, pot să apară probleme)
• Realizarea de documente mai voluminoase decât necesar sau care nu sunt necesare
• Procesele repetitive nu sunt simplificate sau automatizate
• Alegerea neinspirată a instrumentelor de proiect

Cum se poate evita pierderea timpului

Mulţi oameni spun "trebuie să fiu mai organizat" dar acest lucru nu este un obiectiv specific. O întrebare mai bună este "De ce am nevoie pentru a fi mai organizat?". Managerii de Proiect trebuie să cunoască problemele cu care se confruntă şi care ar fi modalităţile specifice pentru a le rezolva.

Cum se poate evita pierderea timpului? În primul rând, eliminaţi motivele prezentate anterior. În al doilea rând, recunoaşteţi că niciodată nu veţi putea face totul, dar cu siguranţă veţi putea face cele mai importante lucruri. Stabiliţi zilnic un număr limitat de priorităţi şi apoi vă puteţi bucura că le-aţi realizat pe toate, deoarece progresul este motivaţional.

Reamintiţi-vă Legea lui Pareto. Valoarea acesteia pentru un Manager de Proiect este că vă reaminteşte să vă concentraţi pe 20% din activităţile care contează. Dintre activităţile pe care le faceţi în timpul proiectului, numai 20% sunt importante. Acest 20% produce 80% din rezultatele voastre. Identificaţi aceste activităţi şi concentraţi-vă asupra lor.

Nu vă supraestimaţi forţele şi fiţi realişti atunci când stabiliţi termene. Când se depăşeşte timpul planificat, încrederea în sine scade şi întârzierea creşte şi mai mult. Avem aceeaşi cantitate de timp de lucru ca şi alţii: 8 ore pe zi. Este alegerea noastră ce şi cum facem în acest timp. Realizarea obiectivelor mici (şi a succeselor mici) va duce la îndeplinirea obiectivelor mai mari (şi a succeselor mari).

Concluzii
Managerul de Proiect trebuie să fie de departe cel mai selectiv. În loc să încerce să facă totul, el trebuie să facă lucrurile necesare, pentru motivele corecte, la momentul potrivit. Făcând mai puţine lucruri, el poate aduce o contribuţie mult mai bună.

Bărbierirea elefantului ar putea fi o idee excelentă într-un videoclip publicitar pentru ultimul model de aparat de ras. Dar dacă vrem să facem un film documentar despre viaţa animalelor în savană, nu cred că este cel mai interesant lucru.

Wednesday May 28, 2014

Monitorizarea platformelor virtuale cu Nagios

Introducere
Mediile virtuale necesita o atentie deosebita datorita importanţei lor din ce in ce mai mari. Pentru a le menţine în parametrii optimi de funcţionare sunt necesare diverse acţiuni administrative periodice. Prin monitorizare se pot reduce riscurile şi se poate îmbunătăţi performanţa globală a platformelor de virtualizare.
În acest post ne vom referi la nagios ca şi instrument de monitorizare, pentru urmatoarele motive :
• Este foarte cunoscut
• Are suport foarte bun din partea comunităţii de utilizatori
• Este gratuit
Nagios este considerat instrumentul tradiţional cel mai utilizat pentru monitorizarea reţelelor IT, fiind capabil să monitorizeze atât infrastructurile fizice cât şi cele virtuale, datorită numărului mare de plug-in-uri disponibile în cadrul comunităţii Nagios.




Exemplu de reţea monitorizată cu Nagios

Nagios nu este instrumentul ideal – are limitări:
• Metoda nativă de configurare este dificilă şi ineficientă
• Interfaţa WEB este urâtă şi nu poate fi personalizată
Cu toate acestea, Nagiosare şi avantaje:
• Este solid
• Poate monitoriza reţele foarte mari (este posibilă şi monitorizarea multi-nod)
• Există multe plug-in-uri native şi multe plug-in-uri disponibile în cadrul comunităţii de utilizatori
• Este relativ uşor să scrii propriile plug-in-uri
• Centreon este un instrument adiţional foarte bun, ce oferă posibilităţi excelente de configurare Nagios, depăşind astfel dificultatea de a configura Nagios prin metoda nativa

Deoarece din ce în ce mai multe maşini sunt virtualuizate, nevoia de monitorizare devine critică.

Monitorizarea platformelor virtuale
Principalii jucatori în piaţa soluţiilor de virtualizare sunt VMware şi Microsoft.

Deoarece produsul de virtualizare Microsoft – Hzper-V – rulează pe Windows , acest lucru nu pune probleme deosebite în legatură cu posibilitatea de monitorizare pentru că orice instrument de monitorizare (inclusiv Nagios) are plug-in-uri integrate pentru monitorizarea parametrilor Windows ca:
    - procese
    - servicii
    - încărcare CPU
    - spaţiu disc
    - evenimente Windows

Monitorizarea este mai dificil de configurat pentru VMware, platforma de virtualizare pe care noi o recomandăm.

Există mai multe moduri de abordare pentru a configura monitorizarea platformelor VMware :

Monitorizarea prin configurarea alertelor vCenter
Alertele vCenter pot fi definite prin setarea urmatorilor parametri:
    - Type (ex: Hosturi, Clustere, Datastore-uri,…)
    - Trigger (ex: spaţiul utilizat pe Datastore peste 80%,..)
    - Action (ex: trimitere email, execuţie script,…)

Avantaje:
    - integrate atât în clientul WEB cât şi în Vsphere Client
    - se poate monitoriza orice parametru
    -există diverse moduri de alertare

Dezavantaje:
    - dificil de vazut o lista a alertelor configurate
    - tabul Alerte prezintă doar problemele, nu şi senzorii care sunt “OK”
    - alertele se bazează pe vCcenter, dar ce se întâmplă dacă vCenter se defectează?
    - este un instrument dedicat, dificil de integrat în alte instrumente de monitorizare existente
    - adaugă complexitate în procesele de monitorizare existente (echipă, instrumente, proceduri)

Monitorizarea cu un instrument de monotorizare dedicat
Deoarece Nagios este cel mai comun instrument de monitorizare, fiind încă considerat standard în industrie, ne vom referi la el ca şi instrument de monitorizare pentru platforme VMware.

Avantaje:
    - integrează monitorizarea VMware cu cu instrumentrul de monitorizare existent (dacă se utilizează deja Nagios)
    - nu adaugă complexitate în procesele existente (echipă, instrumente, proceduri)
    - odată ce au fost implementaţi câţiva senzori, configurările ulterioare devin un proces simplu

Dezavantaje:
    - dificil de instalat. Plug-in-urile de monitorizare VMware nu sunt native Nagios. Ele necesită şi proceduri de instalare specifice.
    - dificil de configurat. Plug-in-urile Nagios pentru VMware, chiar dacă sunt documentate, sunt mai complex de utilizat decât alertele vCenter. Ele necesită şi testare din linia de comandă.

Deci, ce plug-in-uri putem să utilizăm cu Nagios pentru monitorizarea serverelor VMware?

Mai întâide toate, infrastructura VMware poate fi complexă, constând în următoarele :
    - servere VCenter(Windows sau Linux)
    - hosturi ESX / ESXi (sistem de operare VMware – bazat pe linux)
    - storage partajat (Windows, Linux sau sistem de operare dedicat)
    - alte echipamente de reţea

Trebuie sa monitorizăm două categorii de parametri:
    - parametri de sistem generici, ca: disponibilitate, încărcare CPU, spaţiu pe disc,...
    - parametri specifici VMware ca: starea Datastore-urilor, starea maşinilor virtuale,...

Monitorizarea sistemelor Windows şi Linux este uşor de implementat în Nagios, deoarece exista multe plug-in-uri, atât native cât şi dezvoltate de comunitatea Nagios, pentru a monitoriza parametrii generici.
De obicei, aceste plug-in-uri sunt bazate pe SNMP, care trebuie să fie instalat şi configurat pe maşinile respective.
Pentru echipamentele de reţea şi de stocare există plug-in-uri disponibile în cadrul comunităţii Nagios.
 (http://exchange.nagios.org/#/ )
Cea mai dificilă este configurarea monitorizării serverelor ESX / ESX.

Avem două moduri de a implementa monitorizarea serverelor ESX / ESX:
    - Utilizând plug-in-uri IPMI pentru monitorizarea parametrilor generali de sistem (în cea mai mare parte legaţi de hardware, ca: stare CPU, ventilatoare, alimentare electrica, ...)




    - Utilizând plug-in-uri specifice VMware, ca check_vmware_api.pl, pentru a monitoriza parametri specifici (utilizare CPU, IOPS, memorie utilizată pe Host, starea Datastore-urilor,...)




Check_vmware_api.pl se bazează pe vCenter Server ce acţionează ca şi PROXY pentru accesul la datele specifice ESX /ESXi. Această metodă de monitorizare este mai mult sau mai puţin echivalenta cu monitorizartea prin alertele vCenter şi prezintă următoarele avantaje şi dezavantaje:
Avantaje:
• integrat cu Nagios
• nu adaugă complexitate în procesul de monitorizare

Dezavantaje:
• tipurile de parametri care pot fi monitorizaţi cu check_vmware_api.pl sunt un subset al parametrilor ce pot fi monitorizaţi cu alertele VCenter
• dificil de configurat

Concluzie
În mod obişnuit, soluţia de monitorizare va fi bazată pe cât de puţine instrumente se poate (de exemplu doar Ngios Nagios/Centreon) şi o varietate de plug-in-uri, după necesităţi.

Monitoring VMWARE virtualization platforms with Nagios

Introduction
Virtual environments require special attention due to their continually growing importance. Maintaining them on optimal parameters requires periodical specific administration tasks. However, monitoring these systems can reduce risks and improve overall performance of virtualized systems.
In this post we chose Nagios as monitoring tool, for some reasons:
• Well known
• Good community support
• Free
Nagios is considered the traditional and most used free tool for network monitoring, being capable to monitor both physical and virtual environments, due to the rich set of plugins available on the Nagios community.




Sample of a network monitored with Nagios


Nagios Isn’t the ideal tool – it has limitations:
• Native configuration method is ineffective and difficult.
• WEB interface is ugly and not customizable
However, it has some advantages:
• Rock-solid
• Can monitor huge networks (can use multi-node monitoring)
• Many built-in plugins and large community-based plugins available
• Relatively easy to write own plugins
• Centreon is a must-have add-on tool, offering excellent configuration abilities, overcoming the difficulty of configuring Nagios hosts and services

As more and more of servers are virtualized, the need for monitoring virtual platforms becomes critical.

Monitoring virtualization platforms
The main players on virtualization market are VMware and Microsoft.

As Microsoft’s virtualization product, Hyper-V, runs on Windows, this doesn’t put any problems to monitor it, because all monitoring tools (including Nagios) have integrated plugins for monitoring Windows parameters like:
    - processes
    - services
    - CPU load
    - disk space
    - Windows events

Monitoring is more difficult to set-up for VMWARE environments, our recommended virtualization platform.

There are some approaches to set-up monitoring for VMware:

Monitoring by configuring VCenter alerts
VCenter alerts can be defined by setting up the following:
    - Type (ex: Hosts, Clusters, Datastores,…)
    - Trigger (ex: Datastore used space over 80%,..)
    - Action (ex: send email, execute script,…)

Advantages:
    - integrated in both WEB Client and Vsphere Client
    - can monitor all possible parametres
    - various alerting capabilities

Disadvantages:
    - difficult to see the list of configured alerts
    - the alerts window presents only the problems, not the monitoring sensors that are “OK”
    - alerts rely on VCenter. what if the VCenter goes down?
    - it is a dedicated tool, very difficult to integrate into other (existing) network monitoring tools
    - adds complexity to the monitoring processes already in place (team, tools, procedures)

Monitoring with a dedicated network monitoring tool
As Nagios is the most common used free monitoring tool,  still considered to be the industry standard, we will refer to it as monitoring tool for VMware environments.

Advantages:
    - integrates VMware platform monitoring into the existing monitoring tool (if already using Nagios)
    - doesn’t add complexity to the monitoring processes already in place (team, tools, procedures)
    - once you have set-up several sensors, the configuration process becomes easy

Disadvantages:
    - hard to set-up. Plugins for VMware monitoring are not native to Nagios. They also require dedicated installation procedure
    - hard to configure. Nagios VMware plugins, even if they are documented, are more complex to use than VCenter alerts. They also require command-line testing.

So, what plugins can we use with Nagios for monitoring VMware servers?

First of all, the VMware infrastructure may be complex, consisting of elements like:
    - VCenter Servers (Windows or Linux)
    - ESX / ESXi hosts (VMware OS – linux based)
    - Shared storage (Windows, Linux or dedicated OS of storage system)
    - networking equipment

We have to monitor two categories of parameters:
    - generic system parameters like : availability, CPU load, free disk space,…
    - specific VMware parameters like: Datastore status, VM status…

The monitoring of Windows and Linux systems is easy to implement in Nagios, because both built-in and custom Nagios plugins exist for all generic parameters. They usually require SNMP, which must be installed and configured on these machines.
For networking and dedicated storage equipment there are plugins available on the Nagios Community (http://exchange.nagios.org/#/)


The most difficult is to set-up monitoring for ESX / ESXi servers.

We have two ways of implementing monitoring of ESX / ESXi servers:
    - Using IPMI plugins for monitoring general system parameters (mostly hardware-related, like, CPU and FAN health, power state, …)



    - Using specific VMware Nagios plugins, like check_vmware_api.pl to check virtualization specific parameters (CPU utilization, IOPS, Host memory used, Datastore status and free space, ..)



Check_vmware_api.pl relies on VCenter Server to act as a proxy for accessing specific ESX /ESXi data. This method of monitoring is more or less equivalent with VCenter Server alerts, and presents the following advantages and disadvantages:
Advantages:
• integrated with Nagios
• doesn’t add complexity to the monitoring process itself

Disadvantages:
• the types of parameters which can be monitored with check_vmware_api.pl is a subset of the parameters which can be monitored with VCenter alerts
• harder to set-up

Conclusion

Usually, the monitoring solution will be based on as few monitoring tools as possible (ex: only Nagios/Centreon) and a rich mix of plugins, adapted to the needs.

Tuesday May 27, 2014

Monitoring of IT systems

Introduction
The need for network monitoring appears on every situation where critical business processes are running, regardless of the size of the network. Taking into account the specifics of network (size, types of OS), business (monitoring needs, legal, budget…) and other aspects (ease of installation and configuration, technical staff competencies,...),  a network monitoring tool must be selected.
Some monitoring tools are free, some have more editions and some are not free.
Some can be configured to use plugins, in order to extend built-in capabilities.
(see
http://blog.monitis.com/2011/02/22/11-top-server-management-monitoring-software/
http://www.webhostingbuzz.com/blog/2012/05/19/what-is-the-best-server-monitoring-software-to-use/)

Monitoring Tools

Some of the most used monitoring systems are
1. Nagios                               (free / paid versions)
2. Hyperic HQ                         (free / paid versions)
3. ZABBIX                              (free)
4. ICINGA                              (free)
5. SolarWinds                         (paid versions)
6. WhatsUp Gold                     (paid versions)
7. ManageEngine OpManager     (paid versions)
8. GFI Network Server Monitor   (paid versions)
9. OpenNMS                           (free)
10. PRTG Network Monitor         (very limited free version / paid versions)

Let’s see some benefits and limitations for some of these tools.

Nagios

It has a free version (Nagios Core) and a payed version (Nagios XI)
Pros:
• Nagios offers a huge set of collector plug-ins that allows users to gather performance and availability data from a broad range of operating systems. More plugins can be found on the community resources.
• Can monitor huge networks
• Very stable product
• It is considered as being industry-standard and has a huge base of users
Cons:
• Web GUI lacks advanced features.
• For managing config files and services and to run tests a learning phase is required.
• Built-in management is very difficult, requiring text files editing. To overcome this disadvantage, another open-source – Centreon – is commonly used in conjunction with Nagios.

Hyperic HQ
It has  free (open source) and  paid versions
Pros:
• Powerful, high-level monitoring functions;
• Very well-designed user interface, with graphs and alerts
• Integrates with Nagios
Cons:
• Hyperic HQ falls short of automatic corrective actions;

Zabbix

It is free to use for both commercial and non-commercial users.
Pros:
• It’s open-source and has a well-designed Web GUI and overall concept; ZABBIX offers good alerts, dedicated agents and an active user community
• Completely configurable from its WEB front
• Offers trending functionality
Cons:
• Not very easy to configure.
• ZABBIX is not suitable for large networks with 1,000+ nodes, due to PHP performance and Web GUI limitations.

ICINGA

Free, open-source project initially derived as a fork of Nagios.
Pros:
• Rewritten WEB interface and core
• Tries to be easier to configure than Nagios, while keeping all good things from Nagios
• Icinga2 is on the way, with more advantages over Nagios (https://www.icinga.org/nagios/) - architecture, interface, reporting capabilities, features for easier addon development, as well as  its open and transparent development style.
Cons:
• It is not a mature product yet

A more detailed chart of monitoring systems, including various capabilities criteria, can be found on Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems

WhatsUp Gold
Commercial versions only
Pros:
• Easy setup and network discovery
• Great feature set
• Many notification options, including via email and SMS.
• Detailed, customizable reporting; supports custom date ranges.
Cons:
• Non-intuitive
• Strange interface
• Configuration requires both Web and Windows consoles;

Conclusion

The need for monitoring is continually growing, because the importance of virtualization machines is also growing as virtualization ratio grows.

There is no such thing a perfect monitoring tool. The choice of a monitoring tool is a strategic decision and must be based on many factors, like:
    - Network size, complexity and structure
    - Business processes
    - Human resources (technical team size, training and working schedule)
    - Monitoring tools already in place
    - Need for historical graphs for various parameters

The need for a dedicated monitoring team or monitoring service is something to take into account in the process of analysis, based on factors above.
The monitoring team not only observes the network behavior, but also takes some actions, based on procedures:
     - Debugging (event analysis)
     - Alerting people (superior technical levels) following debugging
     - Recovery actions
     - Reporting



Monitorizarea sistemelor IT

Introducere
Nevoia de monitorizare a reţelei IT apare în orice situaţie unde există procese critice de business, indiferent de mărimea reţelei. Luând in considerare specificităţile reţelei (mărime, tip de sisteme de operare), tipul de business (necesităţile de monitorizare, restricţii legislative, buget,...) şi alte aspecte (uşurinţa instalării şi configurării, competenţele echipei tehnice,…) se poate alege un instrument (program) de monitorizare.
Unele programe sunt gratuite, altele au mai multe ediţii (gratuite sau nu) iar altele nu sunt gratuite.
Unele pot fi configurate pentru a utiliza module plug-in, pentru a extinde capabilităţile native.
 (vezi
http://blog.monitis.com/2011/02/22/11-top-server-management-monitoring-software/
http://www.webhostingbuzz.com/blog/2012/05/19/what-is-the-best-server-monitoring-software-to-use/)

Programe de monitorizare
Unele dintre cele mai utilizate programe de monitorizare sunt :
1. Nagios                               (gratuit / comercial)
2. Hyperic HQ                         (gratuit / comercial)
3. ZABBIX                              (gratuit)
4. ICINGA                              (gratuit)
5. SolarWinds                         (comercial)
6. WhatsUp Gold                     (comercial)
7. ManageEngine OpManager     (comercial)
8. GFI Network Server Monitor   (comercial)
9. OpenNMS                           (gratuit)
10. PRTG Network Monitor         (ediţie gratuită foarte limitată / comercial)

Să analizăm beneficiile şi limitările unora dintre aceste programe.

Nagios
Are o ediţie gratuita (Nagios Core) şi una comercială (Nagios XI)
Pro:
• Nagios oferă un set imens de plug-inuri care permit utilizatorului să colecteze date de performanţă şi de disponibilitate pentru o plajă foatre mare de sisteme de operare. Alte plug-inuri pot fi găsite în cadrul resurselor comunităţii de utilizatori Nagios.
• Poate monitoriza reţele foarte mari
• Produsul este foarte stabil in funcţionare
• Este considerat standard în industrie şi are o mare bază de utilizatori
Contra:
• Interfaţa WEB nu dispune de funcţii avansate
• Pentru a putea edita fişierele de configurare si a configura serviciile monitorizate este necesară o perioadă de invăţare
• Configurarea nativă este foarte dificilă, ea implicând editarea de fişiere text. Pentru a depăşi acest dezavantaj un alt program open-source – Centreon –  este deseori folosit impreună cu Nagios

Hyperic HQ

Are o versiune free (open source) şi versiuni comerciale
Pro:
• Funcţionalităţi avansate de monitorizare
• O interfaţă foarte bine proiectată, ce include grafice şi alerte
• Se poate integra cu Nagios
Contra:
• Hyperic HQ nu gestionează acţiuni corective automate

Zabbix

Este gratuit atât pentru utilizatorii comerciali cât şi pentru cei non-comerciali
Pro:
• Este open-source şi are un concept general şi interfaţă WEB bine proiectate. ZABBIX oferă alerte bune, agenţi dedicaţi şi o comunitate de utilizatori foarte activă
• Este complet configurabil din interfaţa WEB
• Oferă funcţionalităţi de estimare a tendinţelor
Contra:
• Nu este uşor de configurat
• Nu este recomandabil pentru reţele mari, de peste 1000 noduri, find limitat de performanţele PHP şi ale interfeţei WEB

ICINGA
Este gratuit, open-source, fiind iniţial derivat din Nagios
Pro:
• Interfaţa WEB şi nucleul programului au fost rescrise
• Încearcă sa fie mai uşor de configurat ca Nagios, în timp ce păstrează toate avantajele acestuia
• Icinga2 este în curs de maturizare, cu şi mai multe avantaje faţă de Nagios (https://www.icinga.org/nagios/) – arhitectură, interfaţă, facilităţi de dezvoltare a modulelor add-on cât şi un stil de dezvoltare transparent şi deschis
Contra:
• Nu este incă un produs matur

WhatsUp Gold
Doar versiuni comerciale.
Pros:
• Instalare uşoară si funcţie de auto-detecţie a elementelor reţelei
• Multe funcţionalităţi
• Multe opţiuni de notificare, incluzând email si SMS
• Posibilităţi de raportare detaliate
Contra:
• Neintuitiv
• Interfaţă bizară
• Configurarea necesită atât consola Windows cât şi interfaţa WEB

Un tabel mai detaliat cu programe de monitorizare, incluzând mai multe criterii de clasificare, poate fi găsit pe Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems

Concluzie

Nevoia de monitorizare este în continuă creştere, deoarece importanţa maşinilor virtuale este de asemenea în creştere, odată cu creşterea ratei de virtualizare.

Nu există noţiunea de program perfect de monitorizare. Alegerea unui program de monitorizare este o decizie strategică ce trebuie să se bazeze pe diferiţi factori, ca :
    - Mărime, complexitatea şi structura reţelei
    - Buget
    - Pro esele de business
    - Resursele umane (dimensiunea echipei tehnice, calificarea acesteia, programul de lucru,...=
    - Programe de monitorizare aflate deja în uz
    - Nevoia de a avea acces la grafice şi date isotrice pentru diferiţi parametri

Nevoia de a avea o echipă de monitorizare dedicată sau un serviciu de monitorizare este un lucru de avut în vedere în procesul de analiză bazat pe factorii de mai sus.
Echipa de monitorizare nu numai că observă comportamentul reţelei, ci şi declanşează anumite acţiuni, bazându-se pe proceduri :
     - Debugging (analiza evenimentelor apărute)
     - Alertarea altor persoane (nivelele tehnice superioare) în urma activităţii de debugging
     - Acţiuni corective
     - Raportare



Friday Apr 25, 2014

Cei trei muşchetari Scrum şi d’Artagnan ca Project Manager

Introducere
Toată lumea ştie că cei trei muşchetari au fost de fapt patru. Dacă cei trei muşchetari sunt Product Owner, Scrum Master şi Delivery Team, atunci al patrulea este Project Manager*.

În continuare, voi prezenta rolul unui Project Manager în cadrul unui proiect care utilizează Scrum şi cum colaborează el cu echipa Scrum.



Echipa Scrum sau cei trei muşchetari Scrum
Conform "8th Annual State of Agile Survey", VersionOne 2013, Scrum şi variantele Scrum (73%) rămân cele mai populare metodologii Agile folosite.

Echipa Scrum este formată din Product Owner, Scrum Master şi Delivery Team. Echipele Scrum sunt auto-organizate şi multi-funcţionale şi livrează produse în mod iterativ şi incremental.

Product Owner reprezintă clientul/utilizatorul şi este singura persoană responsabilă de gestiunea Product Backlog (o listă ordonată cu tot ceea ce ar putea fi necesar în produs şi singura sursă de cerinţe pentru orice modificări care trebuie aduse produsului).

Scrum Master este responsibil de faptul că echipa Scrum aderă la teoria, practicile şi regulile Scrum, şi este lider-servant pentru echipa Scrum.

Delivery Team realizează incrementele potenţial livrabile ale produsului la sfârşitul fiecărui Sprint (perioadă limitată la o lună sau mai puţin, în timpul căreia este creat un increment utilizabil şi potenţial livrabil al produsului).

De ce d’Artagnan se alătură echipei Scrum ca Project Manager?
Dacă echipa Scrum se auto-organizează şi îşi selectează activităţile din lista ordonată a cerinţelor, ce face un Project Manager în proiectele Scrum? De ce a devenit d’Artagnan un muşchetar Scrum şi Project Manager?

Când se utilizează o metodologie ca Scrum, Project Management-ul nu poate fi eliminat. Există mai multe motive: costuri, riscuri, alţi "stakeholders" decât Product Owner, calitate, dezvoltare echipă, interfeţe cu alte sisteme, etc. În multe organizaţii există o reală necesitate de a combina practicile de Project Management şi "framework"-urile Agile.

Ce putem să spunem despre leadership? Modelul de leadership este diferit în proiectele Scrum, în comparaţie cu proiectele convenţionale (pentru că membrii echipei creează valoare). Accentul se pune pe:
• Modelarea comportamentului dorit
• Dorinţa de a provoca status quo-ul
• Responsabilizarea şi încurajarea echipei

În acest caz, Project Manager-ul d’Artagnan va oferi spijinul său deplin celor trei muşchetari Scrum, încurajându-i să livreze rezultatele aşteptate, în timpul fiecărui Sprint.

În fiecare proiect există "stakeholders" cum ar fi Cardinalul Richelieu şi Milady care îşi utilizează influenţa pentru a schimba perimetrul, durata sau bugetul proiectului.  Deci, avem nevoie de d’Artagnan ca Project Manager pentru a gestiona toate aceste probleme şi nu singur, ci împreună cu cei trei muşchetari Scrum.

De asemenea, el poate coordona mai multe echipe şi gestiona "stakeholders" externi, deoarece asigurarea unei comunicări eficiente în cadrul proiectului rămâne o responsabilitate de bază a unui Project Manager.

Ce ar trebui să facă el mai precis?

Project Manager-ul într-un proiect Scrum:
• Inspiră încredere şi deschidere
• Acţionează pentru bunăstarea comună a echipei şi a proiectului
• Creează un mediu de responsabilitate funcţională
• Gestionează nevoile membrilor echipei
• Evită să intervină în cadrul echipei şi consideră un conflict ca pe un pas pozitiv
• Realizează proiecţii de buget şi cost
• Gestionează riscurile
• Gestionează problemele şi elimină obstacolele
• Coordonează mai multe echipe
• (Re)Comunică viziunea proiectului
• Este responsabil de gestiunea contractelor
• Gestionează "stakeholders" externi
• "Provoacă" procesele

Unele persoane spun că în realitate, Project Manager-ul acţionează ca interfaţă a Product Owner-ului faţă de Delivery Team şi ca Project Manager faţă de organizaţie. Motivul este că personalul funcţional, de obicei, nu are timp să o facă. Majoritatea spun că Project Manager-ul nu poate fi Scrum Master deoarece ei au roluri extrem de diferite. În opinia mea, cei patru muşchetari trebuie să rămână patru muşchetari, nici mai mult, nici mai puţin. Fiecare dintre ei are activităţi specifice care trebuie realizate.

Tânărul d’Artagnan îşi poate găsi cu uşurinţă rolul de Project Manager într-un proiect Scrum, chiar dacă numele lui nu este menţionat în ultimul "roman": The Scrum Guide, Iulie 2013, de Ken Schwaber şi Jeff Sutherland. Şi cele mai bune argumente sunt dorinţa sa pentru succesul proiectului şi cum modelează el comportamentele pentru a atinge obiectivele proiectului.

Project Manager-ul nu preia responsabilităţile Scrum Master-ului, chiar dacă unele dintre activităţile menţionate par comune. Într-un articol viitor, voi prezenta relaţia dintre Project Manager şi Scrum Master precum şi task-urile care îi diferenţiază.

Concluzii
Cei patru muşchetari şi prieteni nedespărţiţi s-au ghidat după binecunoscutul motto: "toţi pentru unu, unu pentru toţi". Pentru succesul unui proiect Scrum, colaborarea dintre Project Manager, Product Owner, Scrum Master şi Delivery Team trebuie să se bazeze pe acelaşi principiu (care este cunoscut în Agile ca ''responsabilitate comună pentru eficacitatea echipei'').

Procesul de Project Management implementat în Kepler, ne permite să adaptăm "framework"-urile Agile (ca Scrum, Kanban, etc) la specificul fiecărui proiect. Astfel, d’Artagnan ca Project Manager va fi capabil să maximizeze valoarea de business a proiectului fără să se lupte cu echipa Cardinalului Richelieu.


*Voi păstra denumirile din engleză

The three Scrum musketeers and d’Artagnan as Project Manager

Introduction
Everyone knows that the three musketeers were actually four. If the three musketeers are the Product Owner, Scrum Master and Delivery Team, then the fourth one is the Project Manager.

Next, I will present the role of the Project Manager within a project that uses Scrum and how he collaborates with the Scrum team.



The Scrum team or the three Scrum musketeers
According to the "8th Annual State of Agile Survey", VersionOne 2013, Scrum and Scrum variants (73%) remain the most popular Agile methodologies being used.

The Scrum team consists of a Product Owner, a Scrum Master and the Delivery Team. Scrum teams are self-organizing and cross-functional and deliver products iteratively and incrementally.

The Product Owner represents the client/user and is the sole person responsible for managing the Product Backlog (an ordered list of everything that might be needed in the product and the single source of requirements for any changes to be made to the product).

The Scrum Master is responsible for ensuring that the Scrum team adheres to Scrum theory, practices, and rules, and is a servant-leader for the Scrum team.

The Delivery Team does the work of delivering a potentially releasable increment of the product at the end of each Sprint (a time-box of one month or less during which a useable and potentially releasable product increment is created).

Why d’Artagnan joins the Scrum team as Project Manager?

If the Scrum team self-organizes and selects their own work from the prioritized feature list, what is doing the Project Manager in Scrum projects? Why d’Artagnan become Scrum musketeer and Project Manager?

When using a methodology as Scrum, the Project Management cannot be discarded. There are many reasons: costs, risks, other stakeholders than the Product Owner, quality, team development, interfaces with other systems, etc. In many organizations there is a true need to combine the Project Management practices and Agile frameworks.

What about the leadership? The leadership model is different in Scrum projects, compared with conventional projects (because team members create value). The emphasis is on:
• Modeling desired behavior
• Willingness to challenge the status quo
• Empowering and encouraging the team

In this case, the Project Manager d’Artagnan will give his full support for the three Scrum musketeers, encouraging them to deliver the expected outcomes, during each Sprint.

In every project there are stakeholders as Cardinal Richelieu and Milady who use their influence to change the project scope, time or budget.  So we need d’Artagnan as Project Manager to manage all these issues and not alone, but together with the three Scrum musketeers.

Also, he can coordinate multiple teams and manage external stakeholders, because ensuring effective communication within the project remains a core responsibility of a Project Manager.

What should he do more exactly?

The Project Manager in a Scrum project:
• Instills trust and openness
• Acts for the simultaneous welfare of the team and the project
• Creates an environment of functional accountability
• Manages the team members’ needs
• Resists meddling and recognize team conflict as a positive step
• Makes budget and cost projections
• Manages risks
• Owns issues and removes obstacles
• Coordinates multiple teams
• (Re)Communicates the project vision
• Is responsible for contract management
• Manages external stakeholders
• Challenges the processes

Some people say that in reality, the Project Manager acts as Product Owner interface to the Delivery Team and as Project Manager to the organization. The reason is that the functional staff usually does not have time to do it. Most of the people say that the Project Manager cannot be Scrum Master because they have highly different roles. In my opinion, the four musketeers must remain four musketeers, no more, no less. Each of them has specific activities that must be performed.

The young d’Artagnan can easily find his role as Project Manager in a Scrum project, even his name is not mentioned in the last "novel": The Scrum Guide, July 2013, by Ken Schwaber and Jeff Sutherland. And the best arguments are his desire for project success and how he shapes behaviors to achieve project objectives.

The Project Manager does not take over the responsibilities of the Scrum Master, even some of the mentioned activities seem common. In a future article, I will present the relationship between the Project Manager and the Scrum Master and the tasks that differentiate them.

Conclusions
The four musketeers and inseparable friends were guided by the well-known motto: "all for one, one for all". For the success of a Scrum project, the collaboration between the Project Manager, Product Owner, Scrum Master and Delivery Team must be based on the same principle (which is known in Agile as ''shared responsibility for team effectiveness'').

The Project Management process implemented in Kepler, allow us to adapt the Agile frameworks (as Scrum, Kanban, etc) to the specifics of each project. Thus, d’Artagnan as Project Manager will be able to maximize the project business value without fighting with the Cardinal Richelieu team.

Wednesday Mar 26, 2014

Management de Proiect Activ, Proactiv şi Adaptiv

Introducere
Succesul oricărui proiect este strâns legat de Managementul de Proiect  corespunzător. Pentru a fi eficient, acesta trebuie să aibă mai multe caracteristici. În acest articol, voi prezenta ce înseamnă şi de ce este necesar Managementul de Proiect activ, proactiv şi adaptiv. În plus, în această ordine, aceste trei atribute marchează şi etape distincte din istoria Managementului de Proiect.

Pentru fiecare din ele, am făcut o căutare în PMBOK* Ediţia 5, am interpretat rezultatele şi am făcut diverse consideraţii.

Definiţii
Activ = Care participă intens (în mod efectiv) la o acțiune; energic; harnic
Proactiv = (unei persoane sau acţiuni) Crearea sau controlul unei situaţii, mai degrabă decât doar să răspundă la ea după ce s-a întamplat
Adaptiv = Care se poate adapta (transforma pentru a corespunde anumitor cerințe)


Management de Proiect Activ

Căutare cuvânt «activ» în PMBOK Ediţia 5: 22 rezultate (strict legate de Managementul de Proiect, fără Anexe)
* 4 se referă la Comunicare: Manager de Proiect - actorii proiectului (eng: stakeholders), abilităţi de influenţare şi ascultare
* 11 se referă la Actorii Proiectului: implicarea lor în diverse activităţi, gestiunea actorilor proiectului
* 1 se referă la Procese: gestiune interacţiuni între procese
* 4 se referă la Riscuri: gestiune riscuri, strategii pentru riscuri negative şi pozitive
* 2 se referă la Achiziţii: gestiune contracte, evidenţă resurse

Managementul de Proiect este motorul care «împinge» proiectul să îşi îndeplinească obiectivele. Acest motor trebuie să funcţioneze în permanenţă şi la turaţie ridicată. Pentru ca el să fie mereu activ, este necesar să fie susţinut de Comunicare, Actorii Proiectului şi Gestiunea Riscurilor.

Comunicarea în cadrul proiectului trebuie să fie activă, eficientă şi colaborativă. Un Manager de Proiect consumă cea mai mare parte a timpului pentru comunicare (uniii spun că 90%, alţii mai puţin, alţii mai mult). În acest sens, este esenţial ca Managerul de Proiect să aibă abilităţi ridicate de comunicare (de exemplu: ascultarea activă şi eficace, punerea întrebărilor şi sondarea ideilor pentru o mai bună înţelegere, convingerea unei persoane sau echipe pentru a realiza o acţiune, etc).

Implicarea şi atitudinea actorilor proiectului poate fi activă sau pasivă iar interesul lor faţă de proiect pot fi pozitiv sau negativ. Din acest motiv, Managerul de Proiect trebuie să realizeze o gestiune activă atât a actorilor proiectului cât şi a aşteptărilor acestora, pe întreaga durată a ciclului de viaţă al proiectului. Aceasta este necesară pentru a nu fi afectate obiectivele şi performanţele proiectului, precum şi valoarea lui de business. În plus, succesul unui proiect este strâns legat de implicarea activă a principalilor actori ai proiectului şi Managerul de Proiect trebuie să monitorizeze în permanenţă acest lucru.

Identificarea şi evaluarea riscurilor, precum şi determinarea şi monitorizarea acţiunilor de reducere şi eliminare a acestora, sunt activităţi care se desfăşoară permanent şi necesită implicarea întregii echipe de proiect. Gestiunea activă a riscurilor de proiect pune în primul rând accent pe planificarea, urmărirea şi realizarea acţiunilor corective, în scopul eliminării potenţialelor probleme sau a reducerii impactului acestora.

Management de Proiect Proactiv
Căutare cuvânt «proactiv» în PMBOK Ediţia 5: 10 rezultate
* 5 fac parte din capitolul Gestiunea Riscurilor: gestiune riscuri cunoscute şi necunoscute, acţiuni de  reducere şi eliminare riscuri
* 2 se referă la Comunicare: echipa de proiect - actorii proiectului, networking
* 1 se referă la Audituri de Calitate: asistenţă pentru a îmbunătăţi implementarea proceselor
* 1 se referă la Resurse Umane: acţiuni pentru ridicarea nivelului de competenţă (formări, angajări, etc)
* 1 se referă la Actorii Proiectului: câştigarea suportului acestora

Toate acţiunile cu caracter proactiv menţionate sunt legate într-un fel sau altul de riscurile de proiect, respectiv de minimizarea impactului negativ al acestora. Acest lucru este absolut normal având în vedere caracterul pur proactiv al Gestiunii Riscurilor şi faptul că anticiparea anumitor evenimente în proiecte implică identificarea unor riscuri (fie ele negative sau pozitive).

Este evident că trebuie să fim proactivi atunci când suntem implicaţi într-un proiect (indiferent că suntem Manageri de Proiect sau facem parte din echipă). Experienţa ne face să anticipăm anumite evenimente dar şi lucrul în echipă. Şedinţele de proiect au drept scop nu numai analizarea progresului proiectului şi a problemelor curente, ci şi identificarea de noi riscuri şi acţiuni de reducere asociate. Sau definirea şi revizuirea punctelor de control ale proiectului, care să ne permită să menţinem proiectul pe drumul cel bun (referitor la costuri, durată, calitate, etc). Din acest motiv, Managerii de Proiect trebuie să obţină periodic feedback de la actorii proiectului.

Din punct de vedere al inteligenţei emoţionale, există două lucruri pe care trebuie să le luăm în considerare: îngrijorările şi influenţa. Oamenii proactivi îşi extind sfera de influenţă. Cei reactivi, sunt îngrijoraţi de lucrurile pe care nu le pot controla. În acest sens, Managerii de Proiect proactivi sunt cei care îşi concentrează eforturile şi atenţia pe termen lung, îşi extind influenţa asupra actorilor proiectului şi gestionează eficient riscurile majore.




Management de Proiect Adaptiv
Căutare cuvânt «adaptiv» în PMBOK Ediţia 5: 5 rezultate (fără Definiţii şi Anexe)
* 4 fac parte din capitolul Ciclul de Viaţă al Proiectului
* 1 se referă la Factorii de Mediu ai Organizaţiei

Conceptul de Management de Proiect Adaptiv a apărut după 2001, data apariţiei Manifestului Agile, deşi elemente de Management Adaptiv au fost enunţate încă din 1970.

Metodologiile Agile folosesc un ciclu de viaţă al proiectului adaptiv (condus de schimbări), faţă de metodele clasice care folosesc unul predictiv (condus de un plan).

În prezent, foarte multe echipe de proiect şi organizaţii aplică abordarea Agile iar una dintre ideile de bază este «dezvoltarea flexibilă a produsului». Aceasta oferă capacitatea de a face schimbări în produs, chiar mai târziu în ciclul de dezvoltare.

Observaţie
Foarte multe articole, prezentări şi publicaţii folosesc noţiunea de Management de Proiect Agile (eng: Agile Project Management - APM). Aceasta este contestată de un număr semnificativ de experţi, din mai multe motive. De exemplu, faptul că unii înţeleg că APM = SCRUM sau că se confundă APM cu procesul de dezvoltare Agile.


Managementului de Proiect Adaptiv nu se bazează neapărat pe metodologiile Agile. El se concentrează în principal pe aspectele organizaţionale ale procesului de adaptare. Două principii sunt foarte importante:
* Luarea deciziilor sau realizarea alegerilor se face iterativ, pe baza lecţiilor învăţate din rezultatele deciziilor luate anterior
* Flexibilitatea strategică sau evitarea deciziilor ireversibile

Dezvoltarea Managementului Schimbării (eng: Change Management) din ultimii ani a influenţat decisiv apariţia Managementului de Proiect Adaptiv. Cu cât Managementul Schimbării este aplicat mai eficient, cu atât proiectul are mai mult succes. Managementul Schimbării şi Managementul de Proiect sunt discipline complementare cu un obiectiv comun. Atunci când sunt integrate în realizarea unui proiect, ele oferă împreună o abordare unitară pentru atingerea rezultatelor şi efectelor dorite.

Managementul de Proiect modern, adaptat schimbărilor dese şi bruşte, atât la nivel organizaţional cât şi economic, trebuie să fie unul adaptiv. Proiectele sunt făcute pentru a aduce valoare de business iar în business nimeni nu stă pe loc.




Concluzii
Managementul de Proiect a evoluat foarte mult. În prezent, conducerea unui proiect este precum conducerea unei maşini pe o stradă aglomerată. Trebuie să fim activi referitor la comenzile maşinii, să fim proactivi prin anticiparea acţiunilor şoferilor din proximitate şi să fim adaptivi la condiţiile de trafic şi evenimentele adiacente.


*Project Management Body of Knowledge (PMBOK) este cel mai cunoscut ghid de standarde, concepte şi orientări de management de proiect. Este editat de Project Management Institute (www.pmi.org) şi ultima versiune este ediţia a 5-a (2013)

Active, Proactive and Adaptive Project Management

Introduction
The success of any project is closely linked to the appropriate Project Management. To be effective, it must have several characteristics. In this document, I will present what it means and why the active, proactive and adaptive Project Management it’s necessary. Besides, in this order, these three attributes mark also different stages in the history of Project Management.

For each of them, I did a search in PMBOK* 5th Edition, I have interpreted the results and I have expressed various thoughts.

Definitions
Active = Intensely involved (effectively) in an action; dynamic; hardworking
Proactive = (to a person or action) Creating or controlling a situation, rather than just responding to it after it happened
Adaptive = That can adapt (transform to meet certain requirements)


Active Project Management
Searching the word «active» in PMBOK 5th Edition: 22 results (strictly related to Project Management, without Annexes)
* 4 are related to Communication: Project Manager - Stakeholders, influencing and listening skills
* 11 are related to Stakeholders: their involvement in different activities, project stakeholder management
* 1 is related to Processes: managing process interactions
* 4 are related to Risks: risk management, strategies for negative and positive risks
* 2 are related to Procurements: managing agreements, resource calendars

Project Management is the engine that «pushes» the project to meet its objectives. This engine must continuously operate at high speed. In order to be always active, it must be supported by Communication, Stakeholders and Risk Management.

The communication within the project must be active, effective and collaborative. A Project Manager spends most of the time for communication (some say 90%, some less, some more). In this respect, it’s essential that the Project Manager have high communication skills (for example: active and effective listening, questioning and probing ideas to ensure better understanding, persuading a person or team to perform an action, etc).

The stakeholders’ involvement and attitude can be active or passive and their interest to the project can be positive or negative. For this reason, the Project Manager must perform active management of both stakeholders and their expectations, throughout the project life cycle. This is necessary in order not to be affected the project objectives and performances, as well its business value. Moreover, the project success is closely linked to the active involvement of the main stakeholders and the Project Manager must permanently supervise this.

Risk identification and assessment, as well defining and monitoring actions for risk mitigation and avoidance, are ongoing activities and require the involvement of the entire project team. The active project risk management first focus on planning, monitoring and fulfillment of corrective actions, in order to eliminate the potential problems or reduce their impact.

Proactive Project Management
Searching the word «proactive» in PMBOK 5th Edition: 10 results
* 5 in the chapter Risk Management: management of known and unknown risks, actions for risk mitigation and avoidance
* 2 are related to Communication: project team - stakeholders, networking
* 1 is related to Quality Audits: assistance to improve implementation of processes
* 1 is related to Human Resources: actions to raise the level of competence (training, hiring, etc)
* 1 is related to Stakeholders: wining their support

All indicated proactive actions are somehow or other related to the project risks, i.e. minimizing their negative impact. This is absolutely normal given the purely proactive nature of Risk Management and that the anticipation of certain project events involves the identification of risks (either negative or positive).

It’s obvious that we must be proactive when we are involved in a project (whether we are Project Manager or we are part of the team). The experience leads us to anticipate certain events but also the teamwork. Project meetings are intended not only to analyze the project progress and current issues, but also to identify new risks and associated mitigation actions. Or defining and reviewing the project checkpoints, which allow us to keep the project on track (on cost, duration, quality, etc). For this reason, the Project Managers must obtain regular feedback from stakeholders.

In terms of emotional intelligence, there are two things we need to consider: concern and influence. Proactive people expand their circle of influence. The reactive ones are worried about things they can’t control. In this respect, the proactive Project Managers are those that focus their efforts and attention on long-term, extend their influence on stakeholders and effectively manage the major risks.




Adaptive Project Management
Searching the word «adaptive» in PMBOK 5th Edition: 5 results (without Definitions and Annexes)
* 4 in the chapter Project Life Cycle
* 1 is related to Enterprise Environmental Factors

The Adaptive Project Management concept emerged after 2001, the release date of Agile Manifesto, although elements of Adaptive Management have been stated since 1970.

The Agile methodologies are using an adaptive project life cycle (change driven), versus the traditional methods which are using a predictive one (plan driven).

Currently, many project teams and organizations are applying the Agile approach and one of the basic ideas is the «flexible product development». This provides the ability to make changes in the product, even later in the development cycle.

Remark
A lot of articles, presentations and publications use the concept Agile Project Management. This is contested by a significant number of experts, for several reasons. For example, the fact that some understand that APM = SCRUM or there is a confusion between APM and the Agile development process.


The Adaptive Project Management is not necessarily based on Agile methodologies. It’s focused mainly on the organizational aspects of adaptation process. Two principles are the most important:
* Iterative decision-making or making choices based on learning from the outcomes of decisions previously taken
* Strategic flexibility or avoidance of irreversible decisions

The development of Change Management from the last years has decisively influenced the release of the Adaptive Project Management. More effectively is applied the Change Management, more successful is the project. Change Management and Project Management are complementary disciplines with a common objective. When integrated in the delivery of a project, they together provide a unified approach for achieving the desired results and outcomes.

The modern Project Management, adapted to frequent and sudden changes, both organizational and economic, must be an adaptive one. Projects are made to bring business value and in business no one stand on place.




Conclusions
The Project Management has evolved a lot. Currently, the Project Management is like driving a car on a busy street. We must be active on the machine controls, we must be proactive by anticipating the actions of nearby drivers and we must be adaptive to traffic conditions and adjacent events.


*Project Management Body of Knowledge (PMBOK) is the best known guide of standards, concepts and guidelines for project management. It is published by Project Management Institute (www.pmi.org) and the last version is the 5th Edition (2013)


Thursday Mar 13, 2014

A new challenge

Still atypical in Romania, we launch a company blog that aims to promote knowledge among colleagues as well as among clients and all our friends. We intend to promote our areas of expertize assuming you will find interesting subjects among our posts.


The subjects will include: programming, project management, process modelling and implementation, (tele) communications, products developed or distributed by Kepler-Rominfo including JIRA and Confluence.


As far as possible the posts will be written both in Romanian and English.

We wish these words will inspire dialogs with you, so we wait for your contributions and comments. Anyone interested in the proposed subjects is welcomed to our blog.

O nouă provocare

Încă atipic în Romania, un blog de companie, care-și propune să promoveze cunoașterea atât in rândul colegilor, cât și al clienților si al tuturor prietenilor noștri, se lansează astăzi. Ne propunem să popularizăm domeniile noastre de expertiză în speranța că veți găsi subiecte de interes printre articolele noastre.


Dintre teme nu vor lipsi: programarea, managementul proiectelor, modelarea si implementarea proceselor, (tele)comunicațiile, produsele dezvoltate sau distribuite de către Kepler-Rominfo printre care JIRA si Confluence.


Pe cat posibil, postările pe blog vor fi bilingve in română și în engleză.


Dorim ca aceste cuvinte să fie surse de dialog cu dumneavoastră așa că așteptăm contribuții și comentarii din partea tuturor celor interesați de subiectele propuse.

Copyright © Kepler Rominfo Legal Notices