Tag Archives: project

Crowdsourcing and co-creation elements applied to your project


You don’t have to be very innovative nowadays to be confronted with terms like ‘crowdsourcing’, ‘co-creation’, ‘hackathon’, etc. But how can you apply these techniques in practice for your next project? We compare a classic project approach with more innovative ones with elements of crowdsourcing and co-creation, to learn that there are many ways to engage the colleagues and tap into the wisdom of the crowd. 

The classic project approach

The process would probably like:

  • One team gets the assignment.
  • Interview with stakeholders and customers.
  • Make a proposal.
  • Present proposal at decision committee.
  • Rework proposal.

That’s great because:

  • We’re more in control.
  • The accountability is at the level of one team

But watch out for:

  • Thinking of & working out ideas by same people.
  • Limited amount of different solutions.
  • Iteration time can be long.

Crowd sourcing & co-creation

So, what’s crowd sourcing? It’s a collaborative technique of obtaining ideas by distributing tasks to a large group of people.

Yes! But …

  • + we’ll get many ideas.
  • – there will be much crowd noise.
  • – there will be more chaos.

And co-creation is:

  • Through a series of steps, people are invited to contribute, evaluate, and refine ideas and concepts.
  • The call is not put to an open forum or platform but to a smaller group of individuals with specialized skills and talents.
  • Companies can automate and track some processes while still getting creative ideas

Yes! But…

  • + there are more experts involved.
  • + it’s faster.
  • + we’ll get better ideas.
  • – people are not used to work with customers.
  • – the project team gets feeling of handing out responsibility.

Let’s look at some approaches in practice!

Approach 1 – crowd sourcing with 1 assignment

The process:

  • The project lead writes out an assignment.
  • All employees of the department can hand in a proposal.
  • The project lead select the best 3 (different) proposals that can be worked out.
  • The ideators can form a team and get time & resources for the assignment. Optional: one person of the project team is in the idea team.
  • The teams pitch their idea to the project team and steering committee.
  • One solution is selected to be worked out by the project team, the ideators are involved.

That’s great because:

  • More people are involved.
  • The colleagues feel involved.
  • The employees have the possibility to prove themselves.
  • Very different ideas can be harvested.
  • Different proposals are worked out in parallel by people with a fresh view (new people).

But watch out for:

  • The interest and participation rate can be low.
  • The project lead is not fully in control of worked out solutions.
  • Commitment of time & resources is needed from management.
  • The throughput time can be much longer.

Approach 2 – crowd sourcing with hackathon

A hackathon originates from the IT world where it’s an event in which computer programmers and others involved in software development collaborate intensively on software projects. The efforts of all are focussed on a short time deliverable of tangible software. The principle can be applied for non-IT projects too.

The process:

  • We call for colleagues who want to think along.
  • We reserve an offsite location for 1 or 2 days.
  • The participants are divided into teams.
  • The project lead gives the context and the assignment.
  • The teams work out the assignment and during the day they can ask questions and receive help.
  • The ideas are pitched in front of a jury composed out of management and customers.
  • One solution is selected and will further be worked out by the project team.

That’s great because: (some repeated from the previous approach)

  • More people are involved.
  • The colleagues feel involved.
  • The employees have the possibility to prove themselves.
  • Very different ideas can be harvested.
  • Different proposals are worked out in parallel with a fresh view (new people).
  • Very concentrated effort in 1 or 2 days, which means a very short throughput time.
  • The project lead and management can steer the solutions during the day. (more in control)

But watch out for:

  • The interest and participation rate can be low.
  • Commitment of time & resources is needed from management.
  • Management participation is needed.
  • Additional costs for venue and food & drinks.

Approach 3 – crowd sourcing with multiple assignments

This approach is used in the marketing sector for coming to creative solutions. Eg. when asked for working out a campaign for a laundry softener, one team gets the actual assignment, the other team gets the assignment to sell really nice smelling and soft towels.

The process:

  • We call for employees who want to think along.
  • The project lead writes out multiple assignments and changes the description or terms per assignment. The teams don’t know this.
  • The participants form a team and get time & resources for the assignment. Optional: one person of the project team is in the idea team.
  • The teams pitch their idea to the project team and steering committee.
  • One solution is selected to be worked out by the project team, the ideators are involved.

That’s great because:

  • More people are involved.
  • The colleagues feel involved.
  • The employees have the possibility to prove themselves.
  • We are sure that the same challenge is looked at from different angles.
  • Different proposals are worked out in parallel with a fresh view (new people).

But watch out for:

  • Interest and participation rate can be low.
  • The PL is not fully in control of worked out solutions.
  • Commitment of time & resources is needed from management.
  • Experimental approach.

The leap to co-creation

By adding some co-creation elements you can involve other people to think along. A non-exclusive list of examples:

  • Internal customers (eg. leaders from other departments and business lines)
  • External partners
  • External experts
  • External community

This involvement can be integrated in:

  • Ideation & working out the ideas.
  • Evaluation, giving feedback.
  • Jury.

Additional reading

Tagged , , , , , ,

Why projects fail

Projects have been here for ages and many organizations get more mature in project based work, but still projects keep on failing. I was asked to participate in a brainstorm about project failures and my input can be found below.

The Root Cause Analysis (RCA) framework was used to take a look at the different areas of which a project exists.

Please click on the image for a bigger view.

Click here for the PDF with large overview

If you would turn the negative ones into positives, you have a checklist for your next project!

A Root Cause Analysis on why projects fail

A Root Cause Analysis on why projects fail

Tagged , , , , , ,

The Bridge Game – Learning to live the project

The Bridge Game

The Bridge Game

Last year in September i attended an international cooperation around project management organised by the Xios Hogeschool (Belgium) and the Hogeschool Utrecht (the Netherlands). We did an interesting game about project management that is called The Bridge Game.

The Bridge Game is a game to get acquainted  with project management. The challenge is to build a Meccanno like bridge as a team effort. During the game you will learn to work project, but most of all you will learn what the pitfalls are by experiencing them yourself.

The total time needed for the game is 2 hours, but i’m convinced the game has (educational) value for the participants.

In short, i will give an overview of the game, it’s challenges and it’s learnings.

Goals of the game

  • Bridge the gap in people skills
  • Team dynamics
  • Personal leadership
  • Customer driven focus
  • Effective communication
  • People learning to work with people

Some steps in the game

You follow the steps, just like with a real project.

  • Reconnaissance phase
  • Agreeing on the project lead
  • Making the project charter and budget estimation
  • Risk estimation
  • Requesting time & materials
  • Handling budget, time, scope and quality
  • Delivery and inspection

Some real world difficulties

During the game, some unexpected real world difficulties are introduced by the game leader.

  • Power goes down
  • Team members get sick
  • The project lead is changed
  • A saboteur is introduced
  • Extra resources are added
  • Requests open for interpretation
  • Difficult interfaces to work with
  • If you assume, you make an ass of u and me

How did I become a promoter?

  • The game puts theory into practice
  • Somewhat confronting
  • After the game you get an AHA moment
  • Team work/play
  • Lessons are learned in a “save” environment
  • Reflection and sharing experiences afterwards

Usage in your company

  • Applicable for both novices and experienced project and program leads
  • Addition to the (rather theoretical) standard project management training
  • Recap exercise for project/program leads
  • Team activity in combination with HR event
  • Develop soft and job skills

Be careful! Playing the game can improve your PM skills!

Tagged , , , , , , ,

RCA: there’s more meat to this fish

FishThe Root Cause Analysis (RCA) problem solving technique is typically used for studying a specific problem to get to its root causes and to find solutions that solves the real causes and not only the symptoms.

The RCA technique makes use of the Ishikawa or fish bone diagram and this fish bone makes it possible to use as framework for other workshops.

Positive RCA

As said before, the RCA starts from a SMART problem, but you can also use it to brainstorm solutions. Put the wanted result in the head of the fish and use the bones to capture ideas.

I often refer to this technique as the positive analysis.


We can take the brainstorming one step further: the fish bone is also handy when brainstorming solutions, issues and risks. For example when creating a project charter and you want to identify all possible risks of your project.

Other categories

Why limit yourself to the default categories of process, people, organization, equipment, measurement and procedure? (I actually had to look up the default categories again)

Just use what fits the purpose. If you’re discussing an IT failure in the production environment you can apply for categories like database, front end, infrastructure, network, catalogue and so forth.

Voice Of the Customer survey

You can use the RCA framework even for a VOC survey. At the head of the fish you  put the area you want to evaluate and together with the customer you capture positive and negative remarks for each bone to evaluate.

The advantage of this technique is that you can receive feedback you would never have heard when providing a fixed list of questions. The disadvantage is that the survey (workshop) requires more energy and participation of your customer, and not all customers are willing to participate in such a workshop.

So there’s more to this fish than just getting to the root causes! Why not try it next time?

Tagged , , , , , , , , , , , , , ,

From guesstimate to estimate

When asked for giving an estimate, we often hit the pitfall of giving a guesstimate.

“How many days would it take for this website adjustment?” “About 5 days.”

The guess here is the five days. When the push comes to the shove, you might you run out of time/budget and get into trouble.

A real estimation has a range:

  • 5 tot 10 days
  • 5 days +- 100%

It is not always easy to make an estimation of a complex task. Though, an excellent way to get to it is described in the PMBok (Project Management Body of Knowledge) as a Work Breakdown Structure.

From WBS to PBS to estimations that make sense

The Work Breakdown Structure (WBS) is, as the name tells, a breakdown of the whole assignment in various pieces. The goal is here to make your pieces so small that you can estimate them easy.

An example. If you would ask a website developer to give an estimate of designing a website, he might not pull off a near correct one. But if you would ask him how much time he needs for the different pages, the database design and the object model, … he can get a pretty darn good idea how much work it will take him.

A PMBok representative, Chris, explained it to me once like estimating the length of a pile of rope. You can ask various people to give an estimate and as for result you could take the average. (Let’s put the Wisdom of the Crowds theory aside for now) The best way to estimate the rope is actually to cut it in small(er) pieces, estimate the pieces and take the sum of the pieces.

If you want to take it one step further, you can start your estimations by first creating a Product Breakdown Structure (PBS), from it you can create the Work Breakdown Structure and estimate the different pieces. The Product Breakdown Structure is a hierarchical tree structure of deliverables that make up the project, arranged in whole-part relationship.

An example. If you would need to create a website, the PBS would include elements like the different pages at the first level, at the second level you would find the contents, images, links, model objects, database access, …

And what about padding?

Padding is the effect of adding extra time/budget when calculating risk in. Typically you would see risk margins in the area of 10%. When this is made explicit, it is not that big of a problem: you reserve a separate budget for mitigating risks and issues. And of course, you do not use it for other stuff then handling the risks.

Padding becomes a problem when it is done behind the scenes. If you work with different interfaces or get estimates from different parties, you expect them to be correct. If other parties would hide the fact that 10% risk is calculated in, you would get a wrong image as project lead.

Also, what is happening when the assignment is finished and the budget is not spend? Will the other party come clean and free up the budget?

As project lead you can do following:

  • Ask your third parties to be open with their estimates. Ask for their WBS. How did they get to this estimate?
  • Be very transparent about this: padding is not tolerated.
  • Only use your risk budget for risks.
Tagged , , , , ,

GAP analyse: Agile projectmanagement en de PMBok aanpak voor kennisgebieden Project Integration, Scope en Time Management

Agile Project Management

Agile Project Management – cycle

Deze white paper gaat de kennisgebieden Project Integration Management, Project Scope Management en Project Time Management uit de PMBok vergelijken met de Agile manier van werken.

Eerst wordt Agile kort uitgelegd en vervolgens kijken we naar de oorsprong van Agile. Op één van deze gaan we dieper in: Lean Principles.

Verder worden de verschillende ontwikkelingsmodellen vergeleken en de link met Unified Process gemaakt.

Voor we de kennisgebieden gaan vergelijken, bekijken we ook twee implementaties van Agile: Scrum en eXtreme Programming.



Er bestaat een algemene aversie tussen de uitvoerders van de verschillende methodologieën. De PMBok probeert vaak (onterecht?) te bewijzen dat ze al Agile werken; Agile probeert te bewijzen dat ze net niet volgens de PMBok werken.

De waarheid is dat Agile in de PMBok past (of minstens complementair is), maar zich ontdaan heeft van verschillende onnodige of te strikte praktijken. Daarentegen promoot Agile dan weer niet cowboy coding door alles toe te laten, maar gaat zelf nieuwe en soms striktere praktijken opleggen.

Verder voert Agile ook de verschillende PMBok activiteiten iteratief uit, maar ook dit kunnen we in de PMBok zelf terugvinden.

The organization and/or project management team is responsible for determining what is appropriate for any given project. – PMBok

Het is het best om uit de verschillende methodologieën de goede dingen uit te pikken en je eigen methodologie te maken in plaats van de one-size-fits-all aanpak.

We merken hier ook een valkuil op: zowel bij de PMBok als bij Agile nemen sommige bedrijven deze frameworks te letterlijk over en laten geen ruimte voor interpretatie toe.

Terwijl de PMBok er op staat om alles officieel vast te leggen, lijkt de focus bij Agile op het officieuze te liggen. Het nut van documentatie en planning wordt erkend, maar er wordt geen tijd in gestoken om deze in dezelfde mate af te werken.

Vaak maakt men ook een planning of een breakdown, maar in plaats van deze in te voeren in de projectmanagementsoftware die vandaag ter beschikking is, wordt het ontwerp verder gebruikt of gewoon vastgelegd op foto.

Vaak wordt onterecht gedacht dat Agile niets van documentatie weten wil. In de literatuur vinden we deze component wel nog steeds terug, maar deze wordt vaak anders aangepakt. Er worden bijvoorbeeld wel tests, high level designs en documentatie voor de eindgebruiker opgesteld.

Tagged , , , ,
%d bloggers like this: