Agile Raw Affinity Estimation

Let’s say You have just finished to create the user stories for your product and, a bit proudly, your product backlog now counts two or three hundred of items. How can you estimate them, effectively?

---

It is not always possibile to have all the items of the backlog estimated using the planning poker game. This estimation is somehow precise, but it is actually time consuming and not practicable in one-shot against the whole backlog.

Having a quick first rough estimation of the whole backlog, however, could be the right answer in order to start planning for the development of the product, dividing the effort in releases and giving some forecasts to the management, in terms of schedule and budget.

Actually, we are assuming that these first estimations won’t be perfect but, at last, what estimate is perfect? And moreover during the initial phase?

A technique that could help here, is the Agile Raw Affininity Estimation. I usually organize a workshop of 3/4 hours, within which the team usually can estimate more than two hundred stories.

Participants, material & preconditions

The participants involved are: the ProductOwner, the ScrumMaster and the core team. One important constraint is a logistic one: the room where you are going to hold the meeting, must have wide walls where to stick the user stories.

This is the material you will need:

• A4/Letter sheets
• Markers
• Post-it notes
• Paper tape

And these are some pre-conditions:

• well-formed stories (U-INVEST),
• the ProductOwner should have already presented the stories to the team even if at high-level (epics)
• the stories must be all printed each on a A4/Letter sheet (take care of the font size you use: every story must be clearly readable from 2/3 meters away from the wall) ,
• a printed copy of the team’s definition of done.

These are the main steps of the technique:

• Workshop explanation
• Silent estimation
• Story points estimation
• Estimation review
• Consolidation

Workshop explanation (Coach/ScrumMaster)

The Coach/ScrumMaster explains the team and the ProductOwner, the scope of the meeting and come into a detailed explanation of the process’s steps.

It’s important that s/he stresses the rules underlying the agile estimation (story points, complexity, relative weight, delphi, etc.) and remembers the team that each story estimation should aim to satisfy the definition of done the team already decided.

The Coach, then, sticks on the very bottom-left side of the wall, a sheet of paper reporting the word “SMALL” on it and on the opposite bottom-right of the wall another sheet with the word “BIG”. Finally, he rolls the tape from left to right, joining the two words.

 

This because, the team will hang the stories on the wall according to their size, forgetting, for this first step, about the estimation in figures, but reasonging about a gut estimation and positioning them in respect of the scale (SMALL>BIG) and of the other stories already attached (relative estimation).

The ProductOwner, then, gives the team the pile of user stories already prioritized (top of the pile most important stories).

Silent estimation (Team)

Now it’s time for the team to step in. During this phase the team remains silent. Every member has two possibilities: estimate a new story or change the estimation someone already did of a story.

Estimate a new story

In turn every team member, take a story from the pile, a piece of paper tape and stick the story to the wall, according to his/her perception of the story’s complexity (SMALL vs BIG) and in respect of the other user stories already hanging.

Change an existing estimation

The team member do not take any new story from the pile.

S/he detaches the story to re-estimate and sticks it again in a new position, according to her/his complexity perception and the other stories already hanging.

 

The process above described, continues until all the stories have been estimated.

Every team member can ask clarification about the user stories to the ProductOwner.

Story points estimation (Team)

Now it’s time to transform a position on the wall, in the corresponding estimation in story points. My suggestion here is to use the Fibonacci series.

The team writes each number of the series on a single post-it (1,2,3,5,8,13,etc) and attaches them near the line of the scale.

 

 Estimation review (ProductOwner)

Well, the team now deserves a break and a coffee and leaves the room.

The ProductOwner, which remained silent during the whole estimation process, could necessitate some clarifications.

Thus, she takes small orange/red post-its and attach them on each story that needs a clarification about the estimation done.

When the team comes back, it gives the clarifications the ProductOwner needs about the estimations. Sometimes it happens that after the discussion, the team has new elements and decides to change the estimation, moving the stories down the scale.

Consolidation (Team + ProductOwner)

This is the last step of the workshop.

The team and the ProductOwner write on each user story, the right estimation according to the position and the corresponding number.

The ProductOwner, finally,  gathers the stories and inserts the figures into hte product backlog and that’s it!

 

Who is still saying we agilists do not plan at all?!

One of the worst myths of agile, is that people think agile means to not plan at all. Actually, we do not plan in a traditional way, beacuse we use the rolling wave planning technique and we make a great use of visual management.

---

When starting a new agile project, there are some mandatory plan steps that, in my opinion, every organization should take. Before the first line of code is written, management needs estimations, even raw, dates, plans; this to understand how to finance the project.

Usually, we have a bunch of events we should keep into account.

First of all, a first high-level requirement gathering must be done in order to have clear understanding on what main features the product should have, according to the business value to reach.

This is the responsibility of the ProductOwner, who is the client or a representative of it.

Then, the product roadmap must be arranged: start and end date of the project, release dates, any important deliveries, final UAT, main milestones in terms of operations, marketing, etc.

 

 

Yet, now it’s time to arrange the user story mapping workshop (see here), to start creating the first version of the product backlog.

 

 

Ok, ok, I know. You already did a lot of work and you want to start asap with the first sprint. But, please, listen to me, calm down.

There are some last steps to perform.

To start the next sprint, you need to be sure that the most important user stories, the ones the team will work on immediately, are correctly decomposed and fine-grained. So, you should arrange a meeting with the ProductOwner and the team (Backlog Grooming), to be sure the stories are sized properly according to the sprint lenght and the team velocity.

Ok. Now it’s important to estimate the complexity in user story points, of each story and, indirectly,of the whole backlog. This will help you to make the release and iteration planning.

Use the planning poker game it’s not feasible when estimating too many user stories: it’s too much time consuming. One of the technique I use is the raw affinity estimation, which I’m going to describe shortly in one of my next posts. This technique let you to assign a first rough estimation to all the product backlog stories.

Now, you should have enough data to plan the product deadlines in terms of product release.

You [should] have:

• the total complexity of the product backlog,
• the velocity of your team/s,
• the main milestones

This leds you to the release planning (see here) where you put the epics (main features) on the timeline according to data above.

Finally, you are ready to sprint!

A lean approach to portfolio definition

When adopting agile as a product development methodology, the organizations wouldn’t forget to manage their portfolios accordingly.

It happens frequently that when organizations want to adopt agile, they think it’s only a matter of introducing just one more new methodology in the “assembly line”. They wrongly imagine that it’s only a matter of having the teams doing new things or, either, performing the old ones, better and more efficiently.

What they usually lose, is that introducing agile means to be ready to change organizational habits, behaviours, rules, policies, processes, tools, etc.

The portfolio management is one of the practices that should change.

Ok, let’s imagine you must arrange a portfolio of three different but inter-connected products, which will be developed using agile methodologies. You should have a first raw list of the main features each product should have (EPICS).

Then, You should arrange a workshop in which the most important stakeholders should attend: product managers, program & project managers, CEO, etc.

Be sure you will have post-its of different dimensions and paper tapes available and a large wall where to stick them: you will make great use of some visual management techniques.

Start the meeting, deciding the time-frame within which the products should be deployed.

Then, write the name of the products involved on the Y axis.

Now it’s time to ask the first product manager (or ProductOwner in SCRUM) to write each feature of the product on one post-it and hang it to the wall, positioning it on the timeline where it is supposed the feature must be available. This first chronological prioritization, must be done according to the business value each feature is supposed to bring to the organization.

Then it’s the turn of the second product manager.

Finally, the third product manager does the same.

Now it’s time to analyze and verify the interconnections between the products, asking the three product managers and the other stakeholders, to recognize and highlight any dependencies. This is one of the most important moment: the dependencies, indeed, can be conditioned by several factors: technical, tactical, financial or business ones; thus, choosing the right attendees for this meeting is paramount. It happens that during this phase new features arise.

According to the dependencies just drawn, the attendees must reason on how to reconcile every concern and necessity, by moving the features anticipating or delaying their availability.

Once the reconciliation above is finished, it’s time to analyze risks and impediments. This is a brainstorming session: each person writes on a post-it a risk or an impediment and stick it apart from the portfolio chart just defined.

The facilitator, arranges the items by category, clustering them, remove the duplicates and when the list is consolidated, asks the attendees to sort them by importance. Then, s/he assignes an identification number to each.

The facilitator, then, asks the audience about the impact of each impediment against the portfolio in terms of features, dependencies  or even months and/or products.

The workshop is almost finished. Now it’s time to collect the features and the related attributes (sequence, dependencies, dates, impediment references), into the product backlogs and the impediments list.

 

More reading here (see the book list page):

• Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum Craig Larman – Bas Vodde
• Scaling Software Agility: best practices for large enterprises, Dean Leffingwell
• Lean-Agile Software Development: Achieving Enterpise Agility Alan Shalloway, James R. Trott, Guy Beaver Net Objective Lean Agile series

Be good

Agile PM e matrice debole: due mondi paralleli?

In questo post affronto un tema a mio avviso molto interessante: come è possibile conciliare la metodologia agile per sotto-progetti IT,  che supportano progetti di creazione di nuovi prodotti in organizzazioni che lavorano per funzioni?

---

Nel post Influenza delle organizzazioni aziendali nella gestione dei progetti  ho parlato delle differenti tipologie di organizzazioni e del loro approccio nella gestione dei progetti.

Ognuna di esse, attraverso il proprio management, sviluppa nuove idee di business per lo sviluppo di nuovi prodotti o servizi da lanciare e posizionare sul mercato.

Il primo “slancio” creativo, infatti, lo fanno le persone che conducono l’azienda; persone che hanno decisio la  strategia aziendale e che hanno una visione a 360° del mercato in cui opera l’azienda.

Le idee nate, vengono quindi poste nelle mani dei manager di seconda linea (middle management), affinché siano approfondite e concretizzate.

Queste persone ne sviluppano, o fanno sviluppare, studi di fattibilità, analisi sul ritorno degli investimenti (“investment payback period”, ROI,ecc.) stime dei costi, dei tempi e delle tempistiche di lancio.

Quest’ultima per verificare l’effettivo inquadramento del prodotto sul mercato, all’interno delle finestre temporali richieste dal management; periodo in cui si presuppone di massimizzare la profittabilità dell’azione svolta.

Questa fase di assesment dell’idea (tempi/costi/benefici), porterà alla selezione di quei progetti più convenienti per l’organizzazione.

 

Gli stessi manager che hanno terminato questa fase, probabilmente diverranno gli sponsor dei singoli progetti incaricati di rilasciare i prodotti sul mercato. Loro sceglieranno, o dovrebbero scegliere, i project manager adatti a prenderne la guida e forniranno loro, tutte le informazioni raccolte e le risorse necessarie allo svolgimento del progetto stesso.

Coinvolgimento del dipartimento IT

Ogni progetto fa uso di notevoli quantità di dati e necessita di strumenti adeguati di comunicazione, che obbligano di fatto  il coinvolgimento del dipartimento IT (Information Technology) o IS (Information Systems).

Tale dipartimento, infatti, dovrebbe fornire al project team gli strumenti adatti per la conduzione del progetto, come per esempio:

• Sistemi per lo scambio di Email
• Instant Messaging Systems (es. Messenger, Skype, ecc.)
• Attrezzature per phone/video conference
• Intranet dedicate per la pubblicazione e centralizzazione dei documenti di progetto
• Software di project management

In molti casi, però, il prodotto in fase di progettazione, necessiterà dello sviluppo di procedure software dedicate, ospitate su opportuni sistemi hardware e di rete. Responsabilità, quelle, ancora in carico all’IT.

Il progetto di fatto potrebbe essere suddiviso in due distinti sotto-progetti.

Il primo legato all’area prettamente “business” dell’idea, e che dovrebbe produrre documentazione, modelli e studi, che porteranno alla concretizzazione del progetto nel prodotto/servizio.  Il secondo, a supporto del primo, si occuperà di implementare procedure software, processi, flussi dati e workflow, governando anche le tematiche più prettamente sistemistiche.

E’ in questo momento che possono insorgere problemi tra i due line/functional manager (project manager e responsabile IT), che si trovano a dipendere l’uno dall’altro per la buona riuscita del progetto nella sua totalità.

La prima considerazione riguarda le differenti aree lavorative delle persone coinvolte e il loro differente approccio al lavoro.

Il pm, figura spesso prelevata dall’area di business o funzione aziendale interessata dal progetto, ha spesso un approccio molto “macro” al problema, conosce piuttosto bene il mercato, ha una visione ad alto livello del contesto progettuale, dei vincoli, delle limitazioni e delle opportunità.

Potrebbe in effetti, non parlare  un linguaggio tale da riuscire a trasmettere le informazioni all’IT, con la giusta granularità, precisione e minuzia proprie delle necessità ”informatiche”.

Dall’altra parte il responsabile IT: di probabile estrazione tecnica, necessita appunto di informazioni dettagliate (micro) sui processi e sulle procedure da implementare.

Deve capire i processi coinvolti, conoscere natura e tipologia dei dati, algoritmi di calcolo, corrispondenza tra informazioni di input e output, visibilità dei dati e modalità di trattamento. Le informazioni fornite, dovrebbero anche metterlo nelle condizioni di percepire eventuali possibilità di astrazione dei processi, al fine di renderli generalizzati e riusabili per successive necessità con un conseguente risparmio di denaro.

La seconda considerazione riguarda invece le criticità legate al fattore tempo e alle conseguenze che ne derivano,

Mi spiego meglio. Può accadere che un progetto di importanza vitale per l’azienda, venga lanciato in tempi brevissimi, senza avere a disposizione i piani e i documenti analitici di riferimento, requirements e business case,  budget solo accennati, risorse necessarie non sempre disponibili,  descrizione mancante della qualità necessaria.
L’unica cosa certa è appunto il vincolo tempo: la data di consegna è già decisa.
Questa situazione è paradossale, se consideriamo che è solo in funzione della pianificazione dettagliata di cosa deve essere fatto (WBS + scomposizione attività + stime tempi + stime costi) e con quali risorse, sarà possibile fissare una data di rilascio.

Il project manager, quindi, si trova a dover dialogare con il responsabile IT, non avendo a disposizione informazioni di dettaglio sufficienti per poterlo attivare nel migliore dei modi.

Come fare allora?

Come conciliare i mondi “micro” e “macro” delle due figure?

Come gestire la mancanza di dettaglio analitica del progetto?

 

A mio parere si dovrebbe lavorare su diversi livelli.

Innanzitutto si dovrebbe colmare la distanza di “comunicazione” tra il mondo business e il mondo IT, al fine di rendere più facile e veloce la successiva stesura dei piani analitici necessari.

Si procederebbe quindi alla definizione degli obiettivi strategici da perseguire con il progetto e per questi procedere alla definizione  di un buon livello di dettaglio degli stessi.

Affidarsi all’agile project management e allo sviluppo iterativo, affinche sia possibile sin da subito, cominciare con lo sviluppo delle funzionalità a maggiore priorità.

Utilizzare infine, la tecnica roll wave planning  per condurre in parallelo fasi analitiche dettagliate delle funzionalità  da sviluppare nelle prossime iterazioni.

Nel prossimo post, illustrerò con maggior dettaglio, una possibile soluzione…..ecco un esempio di roll wave planning!

Stay tuned

Statement of Work

Quanto è importante lo statement of work?

 

 

Wikipedia definisce così lo statement of work (SOW) .

Il PMBOK(r) definisce il SOW come una descrizione “narrata” del prodotto/servizio che il progetto dovrà realizzare e  che  solitamente dovrebbe contenere:

• le motivazioni di business che spingono l’azienda ad istanziare il progetto (strategia commerciale, adeguamenti legali, avanzamenti tecnologici, ecc.)
• decrizione dell’ambito del prodotto/servizio: verranno qui descritte le funzionalità, caratteristiche e gli attributi che il prodotto dovrà possedere, preferibilmente messe in relazione alle motivazioni di business sopra descritte
• piano strategico: gli obiettivi e i tempi che si vogliono perseguire attraverso la realizzazione del progetto

Il PMBOK(r) definisce inoltre che tale documento dovrebbe essere frutto di sforzi fatti internamente all’azienda.

Questo, dal mio punto di vista, è ovvio in quanto chi conosce le reali esigenze che ha l’azienda, quali le necessità da soddisfare e in quale modo, sono solo le persone interne all’azienda stessa.

Il documento compilato potrà quindi essere inoltrato ai fornitori in gara, per poter procedere alla compilazione dell’offerta.

La mia esperienza quotidiana, ahimé, mi dice che quanto sopra scritto non è sempre vero.

Spesso il cliente ci convoca quando ancora non sono definiti completamente strategia e caratteristiche del prodotto, ma semplicemente quando è nata un’idea che lui stesso non ha avuto ancora il tempo di sviluppare, se non in maniera generica.

Ed è proprio a questo punto che capita di incappare in una prima situazione di stallo.
Il cliente crede che la chiacchierata di qualche ora in cui ci ha spiegato per sommi capi cosa desidera, possa essere sufficiente a redigere un’accurata offerta.
Quando poi accenniamo, data la mancanza di dettaglio, alla necessità di esporre in fase di offerta la fatidica “forbice di prezzo” più o meno ampia a copertura dei rischi e delle incertezze date dal mancato dettaglio, nascono spesso le prime incomprensioni.

A quel punto per riappianare la situazione, sfoderiamo la carta della consulenza che noi, in quanto project manager, possiamo erogare al cliente per aiutarlo nella fase di prima analisi e  redazione  congiunta dell fatidico statement of work che servirà, quindi, anche alla redazione di un’offerta più mirata.

Ecco il secondo punto di stallo: il cliente, con fare piuttosto scocciato, ci chiederà “Perché mai ti dovrei pagare per permetterti di farmi un’offerta?”.

Il cliente raramente capisce che quel documento dovrebbe redarlo da solo.

Questo gli permetterebbe realmente di analizzare, capire in profondità, strutturare e dare risposte alle reali esigenze aziendali, creando condivisione tra le persone interne coinvolte e ponendo una prima importantissima pietra miliare per il successo del progetto.

Ecco, questo è lo scenario.
Ovviamente ogni regola esiste per essere smentita o per permettere alle eccezioni di manifestarsi, fiere e splendenti.
Ecco quindi, che nel giro di due settimane mi si sono presentate non una ma due eccezioni a quanto appena raccontato.

La prima riguarda la progettazione di un portale piuttosto corposo, rivolto ad un mercato relativamente nuovo, portale che richiede particolari attenzioni stilistiche, funzionali, navigazionali.

La seconda, diametralmente opposta, riguardante la creazione di un’applicazione aziendale volta ad automatizzare articolati processi di gestione del ciclo di vita dei prezzi di prodotti di una importante azienda multinazionale, in cui entrano in gioco meccanismi composti di approvazione delle richieste, di integrazione con sistemi pre-esistenti, vincoli stringenti di facilità d’uso, necessità avanzate di reporting e business intelligence.

Bene, per entrambi oltre alla richiesta di quotazione, ho ricevuto un dettagliato ed esaustivo statement of work.

In entrambe vengono descritte: la situazione di lavoro iniziale, le motivazioni per cui si vuole intraprendere quello sviluppo, le diverse funzionalità del prodotto, il tutto corredato da esempi mirati e particolareggiati, meccanismi di calcolo, modalità di approccio in funzione delle utenze previste.

Insomma un SOW come “disciplina comanda”.

Certamente quanto fatto dai pm delle due aziende li ha visti impegnati per parecchio tempo, nella revisione dei processi esistenti, in tentativi “infiniti” di coinvolgimento dei colleghi in diverse riunioni, nella redazione dei suddetti documenti e nel rendere partecipe il management.

Quanto fatto da loro, sicuramente permetterà all’azienda di meglio indirizzare i propri investimenti nel perseguire le strategie di business, ottenere quotazione mirate dai singoli fornitori e indirettamente aumentare le possibilità di successo del progetto, dovuta ad una generale maggiore chiarezza intorno ai requisiti di progetto.

Quindi non importa da che parte stiate: se siete il committente dedicate il tempo opportuno per la compilazione del SOW la vostra azienda se ne gioverà, se siete invece chi ha l’incarico di eseguire il progetto, insistete perché il SOW vi venga fornito.

Planning a kick-off meeting

Un buon kick-off è garanzia di successo del progetto?

 

Un paio di giorni fà, ho condotto presso un cliente il kick-off di un nuovo progetto.

Progetto non particolarmente complesso nei suoi requisiti, che però nasconde diverse insidie in quanto obbliga un’interazione e integrazione molto forti con i sistemi del cliente, vede coinvolti diversi stakeholder, alcuni dei quali fuori dall’Italia e che, infine,  impone un adattamento a standard procedurali e di documentazione in uso presso il cliente.

La fase analitica inziale che ha dato vita alle stime e all’offerta, non è stata particolarmente dettagliata; diversi erano quindi i punti aperti e i dubbi circa alcune implementazioni.

Il kick-off sarebbe stato quindi momento fondamentale per cercare di chiarire al meglio quanto era ancora sfumato, privo di contorni nitidi.

Ho voluto affrontare il tema facendo uso di una mappa mentale in cui potessi raccogliere tutte, e dico proprio tutte, le tematiche che sarei andato a discutere nel meeting.

La prima cosa che ho fatto, è stata quella di fare una review completa di tutta la documentazione a mia disposizione suddividendo le tematiche nelle seguenti categorie:

• Open Points, in cui ho raccolto tutte le questioni non ancora chiare alle quali si sarebbe dovuto dare risposta nel kick-off
• Functionalities, categoria nella quale ho raccolto tutte le funzionalità del prodotto, implementando rami gerarchici a raggruppare funzionalità dello stesso tipo, in stile WBS
• References, tutti i documenti di riferimento (allegati alla mappa) che hanno dato luogo alla formalizzazione del plan di progetto
• Systems Involved, i diversi sistemi (hardware e software) esterni coinvolti, con i quali l’applicazione dovrà dialogare
• Application Roles, i diversi ruoli applicativi con relativi permessi
• Stakeholders, le persone coinvolte direttamente o indirettamente dal progetto
• Risks, la categoria che raccoglieva una prima analisi dei rischi

Grazie a questa prima iterazione, la mappa ha cominciato a prendere corpo.

Con l’aiuto di un membro del team che si occuperà dello sviluppo, si è proceduto alla scomposizione delle funzionalità in attività; questo ha permesso di delineare la WBS (allegata in formato excel alla mappa) e sulla quale è stato possibile procedere con stime di dettaglio (primo riscontro della mia stima draft fatta in fase di offerta).

Al kick-off ci siamo voluti presentare subito con i layout di esempio delle pagine dell’applicazione, per permettere a tutti di discuterle e di trovare da  subito condivisione sulle interfacce e sulla loro navigabilità.

Anche questa presentazione è stata allegata alla mappa.

Un altro passo è stato organizzare le funzionalità in deliverable del prodotto.

Questo punto è stato ispirato dalla metodologia agile:

• rilasci frequenti e temporalmente vicini
• inclusione già primi rilasci delle funzionalità più importanti (customer business value)

Sono state quindi identificate 4 deliverable, a rilasci distanziati di circa due settimane lavorative l’una dall’altra, includendo le funzionalità più importanti nelle prime due.

Quest’ultimo punto permetterà di:

• innalzare subito l’attenzione del cliente perché in grado di verificare subito le funzionalità più importanti
• garantirci una maggiore “probabilità” di feedback sulle deliverable
• fugare sin da subito dubbi o malintesi sulle funzionalità più importanti invece di scoprirlo alla fine con conseguenze dannosissime

Ho,infine, aggiunto:

• una categoria “Legenda” che riportava le descrizioni delle diverse icone o simboli grafici presenti
• una categoria “Agenda” che riassumeva i macro-punti che sarebbero stati discussi nel meeting
• Una categoria “Attendees” che elencava i partecipanti al kick-off

Il kick-off è andato benone.
Ho potuto mostrare la nostra idea di implementazione del progetto e raccogliere diversi suggerimenti, correzioni, aggiustamenti da parte del cliente.

I punti nella categoria “Open Point” sono stati tutti completamente evasi ed hanno ricevuto le risposte attese.

Gli stessi, a fronte delle risposte, sono stati inclusi nella categoria “Decisions”.

E’ stata prevista un’ulteriore categoria “Action Points” in cui sono state aggiunte le azioni immediate che si sarebbero dovute svolgere e a carico di chi.

Infine sono state aggiunte alcune segnalazioni nella categoria “Risks”.

La mia mappa alla fine conta le seguenti categorie:

• Legenda
• Agenda
• Attendees
• References
• Functionalities
• Stakeholders
• Systems Involved
• Applications Roles
• WBS
• Draft Layouts
• Deliverables
• Decisions (prima chiamata Open Points)
• Action Points
• Risks

 

 

Ora non mi rimane che utilizzare una delle funzionalità di cui sono più innamorato di MindJet MindManager: l’esportazione in word. Questo permetterà la redazione della meeting minutes in pochi minuti, la spedizione agli altri partecipante del kick-off e finalmente….possiamo cominciare a lavorare.

Un buon kick-off non garantisce certo la riuscita del progetto, ma sicuramente siamo riusciti a creare commitment, responsabilità e chiarezza su cosa e come dovrà essere fatto il lavoro e chi e quando dovrà essere svolto.

Project Cost Monitoring

In questi giorni ho avuto modo di ragionare abbastanza approfonditamente sul ciclo di vita dei progetti e su quali attività di controllo sui costi sia possibile attivare nelle diverse fasi.

La crisi in cui versano i mercati impatta fortemente, riducendoli, sui budget di progetto. Quanto inizialmente stimato come costi, può cambiare sensibilmente in poco tempo.

Poter valutare in tempi rapidi e con efficienza il livello dei costi, mettendo in atto le famigerate tecniche di earned value, è vitale per qualsiasi realtà piccola o media che sia.

 

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

Risks Analysis

Questo post apre un argomento piuttosto interessante: il risk management.
Tratteremo qui alcuni principi base per poi, in futuri interventi, dettagliarne tecniche, modalità e approcci.

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

Il coltellino sWBSizzero (2^ parte)

Questa seconda parte del post sulla WBS si prefigge di affrontare la tematica della stima dei tempi e costi di un progetto.
Parleremo di scomposizione dei work package in attività, di scomposizione dell’attività in sotto attività e finalmente dell’utilizzo delle tre tecniche di stima più usate: analogous estimating, parametric estimating e three points estimation. 

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.