Sif E. Elharti's Blog

Even small acts can have a great impact…

Posts Tagged ‘Project Management

Planning Poker Game

leave a comment »

One Agile hidden principle is to shift hard, annoying, and unpleasant work to amusing game. Thus, whether is it for teaching, practicing or using Agile, playing games (also called Serious Games) is widely used to simplify these activities and make them more attractive and fanny.

Are you serious? How can you be productive while playing?

A straightforward answer is that you are more productive when you like what you are doing and when you are forced to do some task your productivity goes down. Agile professionals understand that very well and try to use it as much as possible in practice. To mention only some games that are used, we have :

  • The marshmallow challenge to teach elementary concepts for successful project;
  • The Business Value Game to practice customers and features selection techniques;
  • The Planning Poker that teams use as a technique (or game) for voting, for estimating, and for leveling feature’s or task’s understanding.

If you have ever played Poker, you would have notice that participants play in rounds using cards distributed to them. For the Planning Poker, we will keep only these two elements. -I am not qualified to show you how to play and win real poker game. But if you insist on me to do so, be sure to end up washing dishes in the casino :(-

Let take an easy example to practice this game. Suppose you, me and three other organizers are preparing a party for the next Sunday and we want to estimate how many people will show up this day. -It happens that while writing this, the next Sunday coincides with Valentine’s Day !-

To answer the estimation question, let’s do the following:

  1. Four from us (organizers) will participate and one will be a moderator
  2. We write down on cards, with the same size and color, values like: 5, 10, 15, 20, 25, 30, 35, 40, 45 and 50 (we suppose the number will not exceed 50). We make 4 copies of this deck one for each player.
  3. The moderator will ask the question: “how many people will attend?”
  4. The moderator will ask players to play a round by selecting a card form their deck without showing it to the others
  5. The moderator will ask players to show their cards to everybody at the same time
  6. If the values are equal, no need to go further. The game ends and the estimation is set to the common value.
  7. If the values are different (which is in general the case for the first rounds), two people with the highest and lowest values will explain why they choose their values. The moderator must keep an eye on the running time so that explanations do not exceed few minutes.
  8. The moderator will ask players to play another round as in step 4 and we continue looping until we all agree on some reasonable value for the estimation.

Wait here! if some players stick to their selected different values, this can go forever!

  1. If we don’t agree on a common value after some rounds (2 or 3 ) we can apply 1 of these 2 possibilities:
    1. Take the mean of the values as estimation, or
    2. Take the most common value (majority)

Let’s play:

Player

Round

Organizer 1 Organizer 2 Organizer 3 Organizer 4
1

 

Explanation

15

20 35

40

Talk first: Valentine’s Day, people will prefer to spend it with their beloveds. Talk after: 2 months ago, we had around 40, but I forgot about the Valentine’s Day!
2

 

Explanation

25

25

35

35

Talk after: I took in account Organizer 4 comments but I did not add that much since the proposed music is different and especially adapted to Valentine’s Day. Yet, I forgot about the bad weather! Talk first: Most people cannot travel because of the announced bad weather.
3

30

30

30

30

 

In fact, this leads us to estimate the number of attendees but more important if generates all the discussions around that helps us to have a better understanding of the party conditions.

For the planning Poker, we use a deck of cards a little bit different from the one used for our party. We prefer a nonlinear reparation of the values in order to magnify the differences.

These values are inspired for a well-known Fibonacci’s sequence defined using this formula: Un+2 = Un+1 +Un. First elements are: 0, 1, 2, 3, 5, 8, 13, 21, 34….

For our Planning Poker game, we can use this sequence for example:

0 1 2 3 5 8 20 40

The selected values after 5 or 8 might vary depending on author or team. Some teams add cards with values as ½, 100 or infinity and card with “?” mark. This is to allow half value of the metric unit, to reflect a huge amount as a value or to request more explanation about what is under estimation.

PlanningPokerCards

Planning Poker Cards

Two last points regarding Planning Poker:

  • The metric unit used is defined and agreed between participants and must stay still for the whole project,
  • Using Person-Day to estimate a task duration for example might not be a good choice since it depends on the developer working on it; thus we suggest using the following technique:
    • Between all the items to estimate, select a small (but not too small ) one that everyone understand very well and set it as reference,
    • When voting, every participant gives an estimation by comparing the item being estimated to the reference one. So one might vote the card “2” to indicate that, for him, the estimation for this item is 2 times the estimation for the reference item.

Have fun … 🙂

I hope this helps,

Sif E. El Harti

Advertisements

Written by selharti

February 12, 2016 at 7:19 am

Agile hidden mindset

leave a comment »

No need to convince you about the benefits of Agile methods and how they can help you build the software that your customer really needs in incremental and iterative way. mindYou can easily find a lot about this subject everywhere. In this paper, we will focus on some principles unmentioned openly in Agile Manifesto. This thought came to us from real failed and successful experiences about Agile implementations.

Values and principles, defined in Agile Manifesto, are not only some rules to follow in order to have the label: ‘We are Agile!’. We have a deep conviction that behind the scene there is a fundamental consideration for person as a human being. Indeed, the central actors for any organization are the people behind it. Thus, in order to be productive and to keep being productive for a long time, there is a real need to take care of the building blocks of your organization. You will agree, for sure, that foundations have to be considered first.

Therefore, here is a first draft about some principles we think are necessary to comply with Agile hidden mindset. We noticed that when some of them are missing, this leads to Agile implementation failure. We propose these principles under three sets: “as a person”, “as a team” and “as an organization” and we give no explanations in order to keep it open to your interpretations.

As a person

  1. I have fun while working
  2. I respect my life (personal one)
  3. I respect my customers and coworkers
  4. I learn that learning has no ends and I learn that I can learn from everything
  5. I wish for the others what I wish for yourself
  6. I’m brave
  7. I’m honest
  8. I believe in myself
  9. I challenge myself
  10. I keep in mind that I’m professional and that I have to act as a professional
  11. I never underestimate the others
  12. I regularly think about these questions: how am I doing? How can I become better?

As a team

  1. We talk the same language (exp.: be sure to share the some definitions)
  2. We are all for one and everyone for all
  3. We know that : 1 mind plus 1 mind gives 3 minds
  4. We interact positively
  5. We share: knowledge, ownership, responsibility
  6. We make team decisions
  7. We agree on objectives
  8. We challenge our team
  9. We believe in our team
  10. We are suggestive rather than directive
  11. We accept differences
  12. We regularly think about these questions: how are we doing? How can we become better?

As an organization

  1. We trust our employees
  2. We enhance belonging to the organization
  3. We respect your employees
  4. We share success, and we share failures also (with moderation)
  5. We share the same vision
  6. We regularly think about these questions: how is our organization doing? How can our organization become better?

Et Voilà!

For sure, as usual, your comments and suggestions are welcome.

Sif E. El Harti


 

Even small acts can have a great impact.

Written by selharti

February 8, 2016 at 12:56 pm

Project Management: Part 5 – Basic concepts – Mapping Project Management Process Groups and Knowledge Areas

leave a comment »

Manage a project is a hard to summarize task. By the PMBOK standard, it’s about managing the following NINE areas, but not restricted to: Integration, Scope, Time, Cost, Quality, Human Resources, Communication, Risk and Procurement. 

Each area has a defined set of processes. The set of all the processes for all the areas can be partitioned in FIVE process groups: Initiating, Planning, Executing, Managing and Controlling and Closing. 

PMBOK definition: “A process is a set of interrelated actions and activities performed to achieve a pre-specified product, result, or service. Each process is characterized by its inputs, the tools and techniques that can be applied, and the resulting outputs.”  

Thus, project management consist of selecting the processes that apply for the underlying project and execute these processes in order to achieve the target of the project. 

Many factors can influence the subset of selected processes and the way they are applied. But the main elements to consider are: The organization process asset and the enterprise environment factors. Those two must be watched all over the project life. 

 

You may wonder where all these are coming from. Recall, from our previous posts, that a lot of projects have is undertaken, and a large common experience was developed during ages. And this is the common experience as seen and addressed by the PMI. 

We’ll see each the process groups, the knowledge areas, and the processes listed progressively (fig. above). 

But keep in mind the here following points: 

  • Even if we are talking about processes here, the job is actually done by people. So the focus on process will help define a path to follow but will never replace the special care to be given to people to make that path leading to the projected target of the project.
  • On the other hand, each project is unique, and one must not be flowed thinking that if he applies religiously all the processes, the result is guaranteed. It takes some “Agility” to take the “right” decisions, or may I say the “best”, at the right time depending on the information available and the special context of the project.
  • And the last one: if you are new to the domain do not try to be so much innovator. Try first to understand, apply and experiment and find your way smoothly. But most of all, learn from others and share your experience.

See you later.

Sif E. Elharti,

Written by selharti

March 16, 2010 at 6:27 pm

Project Management: Part 4 – Basic concepts Project / Program / Portfolio

leave a comment »

For a large organisation, projects can be gathered in two kinds of collections: Program or Portfolio.

The PMI definitions are as following PMBOK (4th Ed.):

A “Program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside of the scope of the discrete projects in the program.”

 “A portfolio refers to a collection of projects or programs and other works that are grouped together to facilitate effective management of what work to meet strategic business objectives.”

 An easy way to figure it out is to imagine portfolios and programs as containers that can include projects.

Portfolio, program and project organization

A portfolio is at business strategy level. Its scope is larger than any program or project within the organization and has strategic goal to reach. Thus it contains a set of project or programs that complete each other for that purpose. Nevertheless, those programs and projects are not necessarily related or dependent.  The main raison for creating a portfolio is to centralize, synchronize and prioritize all the components needed to carry out the business goal.

A program is a component of a portfolio that groups a set of related projects that need to be coordinated to accomplish a larger target than the target of the projects individually.

Let’s apply this to an example:

Suppose a developing country “Alpha” has identified tourism as major axe to develop to enhance its economy. “Alpha” has identified also that a large number of pediments that act against this opportunity such as:

  • Bad infrastructure: few international airports with limited capacities, missing highways and roads.
  • No easy access to natural parks and historical sites
  • Limited high standing Hotels.
  • Poor marketing
  • Restrictive lows
  • Etc…

So “Alpha” creates the following projects (to keep it simple, we will stop at this infrastructure and hotels level)

  • Portfolio: “Welcome to Alpha”

    • Portfolio1.1: “Transportation program”

      • Program 1.1.1: Highway between cities “A” and “B”

        •          Project 1.1.1.1: Highway Section 1 (“A” to “N”)
        •          Project 1.1.1.2: Highway Section 2 (“N” to “M”)
        •          Project 1.1.1.3: Highway Section 3 (“M” to “B”)


      • Project 1.1.2: Highway between cities “A” and “C”
      • Project 1.1.3: Enlarge the international airport of city “A”
      • Project 1.1.4: Add a road from city “B” to the historical site “H”
      • Project 1.1.5: Add a road from city “C” to the natural site “N”


    • Portfolio1.2: “Hotels”

      • Project 1.2.1: Build Airport hotel in city “A”
      • Project 1.2.2: Extend hotel “X” in city “B”
      • Project 1.2.3: Build hotel near the site “N”
      • Project 1.2.4: Build hotel near the site “P”
      • Project 1.2.5: Build hotel in city “C”





The role of the portfolio managers is to coordinate and prioritize all these programs and projects by providing all the necessary infrastructure, processes and assistance needed to facilitate the accomplishment of the main goal.

But one has to keep in mind that applying this model of projects hierarchy requires a maturity in the organization. In fact, a bad implementation or misunderstanding can lead to more chaotic results and can go against the original purpose for which it was undertaken.

See you later.

Sif E. Elharti,

Written by selharti

March 6, 2010 at 2:52 am

Project Management: Part 3 – Basic concepts Project / Phase

leave a comment »

Large projects may be divided in smaller and more manageable subprojects or phases. This holds to reach a large result through a set of complementary, sequential and/or parallel steps. Each phase (a step) is managed as proper project.

Let’s suppose that I bought an old house (a really old one that needs immediate renovation). Knowing, there is no chance that some angels for “The extreme makeover: Home edition” will do that for me within 7*24 hours, I decided to handle it by myself and at my own speed.

Basically and roughly, we can say that we need three phases:

• Phase 1: Demolition

• Phase 2: Building

• Phase 3: furnishing

At first sight, we can say that those three steps must be done in sequence in the same order they are presented. In fact, it seems logical to execute building tasks after demolition ones but before furnishing tasks.

Nevertheless, there may exist a way to start one phase before the end of its preceding one. This is called overlapping – we will see that again in further posts-.

To carry out this, it requires the observation of two conditions for the task to be started:

• All the tasks that the task is depending on are executed.

• All the remaining tasks from the previous phase are independent form the task.

We will note also that, any task that will be done later will not affect the task by any way.

To tie it to our example –and keep it simple-, let’s suppose that the demolition phase has 3 tasks:

• T1.1 – Demolish the bathroom.

• T1.2 – Remove the old kitchen.

• T1.3 – Demolish a wall in the kitchen side.

And the building phase has 2 tasks:

 • T2.1 – Install a new bath and a new shower.

• T2.1 – Install a new kitchen.

Note: the task identification used here will be detailed in the WBS (Work Beakdown Structure) later.

So, since installing the new bath and shower (T2.1) depends only on the demolition of the bathroom (T1.1), the former one can be started immediately after the later is done. But we have to make sure the remaining tasks have no effect on task  (T2.1).

Let’s end with the following definition of a phase from the PMBOK Guide (4th Ed.):

Project phase is a collection of logically related project activities, usually culmination in the completion of a major deliverable. But not that a project phase is not a Project Management Process Group.

See you later.

Sif Elharti,

Written by selharti

February 7, 2010 at 2:06 am

Project Management: Part 2 – Basic concepts

leave a comment »

Project

The PMI definition of a project in the PMBOK Guide fourth edition is as following: “A project is a temporary endeavour undertaken to create a unique product, service, or result.” (page 5).

It comes out from this definition that a project has the following characteristics:

  • First of all, a unique target or goal: this can be either a physical result as a build a bridge or a house, or logical result as an audit report about a company. This last example even if it may seem physical (a report) but actually the result is the content, analysis and recommendations, and not the physical container used to express it.
  •  The second characteristic is the limitation in time: a project has a starting and ending dates. And the term “temporary” is the PMBOK definition is used to enforce this characteristic.

Project / operation / Product

The second characteristic above mustn’t be neglected since many people are mixing project, operation and product concepts.

Let’s clarify that through some examples. Build a house, for a building company, is a project. Each new house is a new project even if the same tasks must be done repetitively. On the other hand, paying employees (builders for example) is an operation, a repetitive task with a unique goal but with no ending date while the company is active.  For software providers, a product is the deliverable software that responds to some users needs. It has no ending date while the product is on the market and maintained. Yet, working on each new version or release of that product is a project with the new version as target and a timeframe within which it should be done.

Notice here the use “should” instead of “must” or “will”. All project stakeholders would like it to be “will” but, unfortunately, it’s not the case because things don’t go always as we want them to do (We will more see about that in further posts). But for now, just remember a project has a starting date and “must” have an ending date even if it’s aborted.

See you later

Sif E. Elharti,

Even small acts can have a great impact…

Written by selharti

January 9, 2010 at 3:56 pm

Posted in Project Management

Tagged with , ,

Project Management: Part 1 – Getting started

leave a comment »

Project management is a real challenging world. Indeed, there is no magical recipe that guaranties a 100% result. This is a built-in characteristic of this domain. – It’s not the only one, for sure, but let’s focus on this one only -. It remains in our limited capacities to surround all the elements that may, directly or indirectly, influence our project path. But fortunately, we have a great gift from the nature: learning capacities.

Thus, a large number of organisations, thinkers and experimented persons tried, and are still trying, to define standards, frameworks, check lists and tools (theoretical and practical) for project management. Those are the result of a long-term experience (starting from, or may be before, The Great Alexander to nowadays) and all the learned lessons aggregated. The main purpose is to help project managers to reduce, as much as possible, the difference between actual results and expected outcomes throughout the project life.

Before going further, we will need to ensure some concepts as basic as what is a project? What is a result (real or expected)? We will also need to specify what does “reduce the distance” means? Is there a measuring system? What is a project life? And so many other questions we will encounter and try to answer during our journey in this large ocean.

Once we are done with that, and it will be neither a short nor an easy task, we will explore other facets not less important as Priority, Focus, Causal set and more other elements that affect project life or may help to make better decisions.

We will refer principally to PMBOk fourth edition (Project Management Base Of Knowledge) the PMIs (Project management Institute) standard for Project management.

See you later,

Sif,

Even small acts can have a great impact…

Written by selharti

January 2, 2010 at 7:16 pm

Posted in Project Management

Tagged with , ,

%d bloggers like this: