The LinkedIn forum The Project Manager Network - #1 Group for Project Managers which I sometimes wonder if that is actually the case, has a conversation going on around project failure. A Master's student asked about project failure modes. That led to the use of Earned Value. One participants made some pretty boneheaded statement around EV:

1. (EV) It's a tool and anyone who thinks it is an actual depiction of real progress is fooling themselves.
2. Percent complete, unless 100%, is at best an educated guess.
3. I've heard of the 0/100 and the 0/50/100 methodologies. I disagree with the 0/100. If you are trying to accurately portray progress, it is best to develop a set of standard credits, for example when doing drawings or, actual measurement such as in construction. Each activity has a value from which percent complete can be derived. 
4. An equipment general arrangement drawing is a good example (percentages shown are individual contributions) - using 40 hrs/drawing as the allowance (we get)...

5% (2 hrs)for applying the border and title
20% (8 hrs) for defining the area - boundaries and overall dimensions
30% (12 hrs) for showing all the equipment
5% (2 hrs) for the drawing being checked
10% (4 hrs) for it being Issued for Approval
15% (6 hrs) for it being Issued for Bid
15% (6 hrs) for it being Issued for Construction.
100% = 40 hrs. 

So, silly me, I responded that determining physical percent complete was a straight forward process once you have Quantifiable Backup Data or measures of Physical Percent Complete, or even better, Technical Performance Measures. Let's look at each concept

1. EV, when percent complete is measured in tangible units of physical percent complete is a depiction of real progress. Why because the progress is physical percent complete. It's a tautology.
2. Percent complete is NOT an educated guess, it is tangible proof. This is call Quantifiable Backup Data. Bring the number of drawings to the table you said you were going to do on the day you said you were going to do them, and you'll get the prorated share of the earned value for the total drawing package. Bring 8 of the planned 10 on the day you planned to produce 8 and you'll get 80% of the total work package for producing 10 drawings.
3. 0/100 is best, all others skew the performance. The last piece of that concept is actually correct. For a 10 drawing package, with each drawing weighted the same, that is 10%, 5 drawings, completed on the planned day, gets you 50% physical percent complete.
4. No we go straight into the ditch. Progress is NEVER measured with the passage of time except in Level of Effort work. The actual costs (ACWP) is interesting to cost accounting, but it tells us nothing about the progress of the project except how much money we have spent compared to our budget. If the assigned (apportioned) value were all there was, then OK. But the conversation included the number of hours, and there where the problem starts.

Then the final come back from the OP.

If you're doing a drawing and it takes 40 hours to do the drawing and no two drawings are alike, how do you determine what percentage complete you are? When estimates of the work to be completed are put together, they will estimate X drawings at 40 hrs/drawing. They will have different standards by discipline. Will a person ever report 41% complete on a drawing? Most likely not. It will be shown as 40%. Collectively all the drawings may be 41%, but not individual. No matter how you look at it, it is still an estimate.

First measuring progress to plan by the number of hours consumed is called Level of Effort. Second LOE is a very poor measure of anything other than the passage of time and consumption of resources.

In the end the poster was insistent that ANSI-748-B is just a guide, and doing EV was a local issue. No doubt that is true in his domain. But as a practitioner of EVM using ANSI-748-B for programs subject to DCMA Validation, as well as engagements with the DOD office that own the Earned Value Management processes for the DOD, I'd be laughed out of the room with an approach like that.

For a summary Earned Value in a Nutshell using a similar drawing example.

So Here's The Way TO Do Earned Value

1. Using the WBS define the Work Packages that produce the deliverables for the program
2. Assign an Earned Value Technique to each of these Work Packages - 0/100 for the individual tasks inside the Work Package is the absolute best. You're either done with the task or you are not. Weight the tasks if you want, but sum up the "done ones" and compare that to the total work and compute a percent complete.
3. Sequence these Work Packages in an Integrated Master Schedule
4. Assign budget (BCWS) to each of the Work Packages
5. Collect the actual costs to perform the work (ACWP)
6. Compute the Earned Value (BCWP) using a simple formula BCWP = BCWS x Physical Percent Complete.
7. Compute Cost and Schedule variance. Make management decisions based on these and take corrective actions to get back to GREEN.
8. Repeat step 5, 6, and 7 every month at a minimum, more often if possible.

That's all there is - essentially - for doing Earned Value Management. Of course if you read ANSI-748-B, the NDIA Earned Value Management Intent Guide, and the DCMA Intent Guide, there is a lot more.

You Can't Make Stuff Up

OK, you can. But if you do, it makes having a conversation about EV much harder. 

Related articles What is Earned Value? Definitions, Yes They Are Important In Earned Value, Money Spent is Not a Measure of Progress! Rings of Success Earned Value says its Name Issues with Deploying Earned Value Management

Here is our monthly selection of interesting knowledge material on programming, software testing and project management: Blog: Agile Scenarios and Storyboards Blog: The difference between Test First and Test Driven Development Blog: Daily Process Thoughts: Agile Coach or Scrum Master Blog: Daniel Cook on 8 Laws of Productivity Blog: 5 Things That Will Make Your Agile Development Project FAIL Article: Transitioning to Agile Article: Exploratory test adventure: a creative, collaborative learning experience (PDF) Article: Designing Experiences for Responsive Web Sites Article: Is Agile Always Appropriate? Article: SQL Performance Issues: Query Compilation Article: The Implications of Having a Definition of Done on ...

I’ve been asking around on email and on the social networks what makes a conference memorable, special, or amazing.  This topic has my special interest, not only because I attend between 20-25 conferences per year, but also because I’m trying to help make the DARE 2013 conference in Antwerp, Belgium a great experience.

The obvious replies that people usually have are “amazing speakers” and “great hallway conversations”. I agree, and there’s plenty that organizers already do (or should do) to make that happen. But personally, I am more and more convinced that “greatness” is an emergent result of the complex interplay of little things.

Here are some suggestions I received:

• Have great coffee available during the conference. (Johan Oskarsson)
• Have dinner with strangers at the end of a conference day so that attendees get to know each other better (Ángel Medinilla)
• Let people rate speakers directly after their sessions, and repeat the best session at the end of the conference. (Tiago Andrade e Silva)
• Use feedback/happiness doors to capture quick feedback after each session.
• Do phone interviews of speakers and edit their descriptions to match the audience. (Lee Copeland)
• Have an icebreaker party before the conference with a jam session of speakers and organizers. (Alexey Krivitsky)
• Print people’s first names on badges in big letters, and on both sides of the badge. (Jon Jagger)
• Use conference apps so that people can easily see the program on their smartphones and mark their favorite sessions.

And there’s much more, ranging from the very obvious, such as give away free books, to the somewhat-less-obvious, such as invite a circus act.

There are three weeks left until DARE 2013. The number of participants is growing steadily, while time is shrinking fast. I’m afraid we cannot implement all ideas people have suggested. But we’re trying hard to hear at least those three most important words, “That was great!”

p.s. I have a discount code for friends. Contact me.

I gave a talk at Devs in the ‘Ditch last week when I was in London. I posted the slides on slideshare: Overcoming Three Pitfalls of Transitioning to Agile.

The very nice people at 7digital made a video and posted it, too. If you can take the time, watch the entire video. Rob Bowyer gave a great talk about kanban and theory of constraints. My part about overcoming these three pitfalls starts at about 42 minutes in.

There are many other pitfalls to transition. This talk had just three of them: the stories are too big, you need experts to do the work, and you implement as layers instead of through the architecture.

I hope you enjoy the presentation and the video.

 

I've always been envious of those with nice handwriting or even distinctive printing. I've always been in too much of a rush to do be better than barely legible at either. My handwriting ranks somewhere between a eight-year-old's and a doctor's. Pretty bad.

But, I've learned that means I'm ideal for writing a team's user stories.

Research by Daniel Oppenheimer and two colleagues found that fonts (such as my handwriting) that are hard to read lead to greater recall than fonts that are easy to read.

They gave a group of students two documents--one in easy to read, 16-point, black Arial; the other in hard to read, gray, 12-point Comic Sans. After distracting the students for 15 minutes, they tested their recall of facts in the two documents. They recalled 87% of the facts in the hard-to-read font but only 73% of the facts from the easy-to-read font.

From now on, I suggest having the team member with the worst handwriting write all user stories and be the one with the marker during all team meetings. And, if I'm on your team, that's likely me.

I also apologize that you'll immediately forget 27% of this blog post because of the nice readable font.

The conversation on Twitter around No Estimates #NoEstimates brings a smile. Here's some samples

• Marketing needs a rough idea of when alpha-level code will be available. Allowing a few weeks for alpha testing and a few more for beta testing provides a time line. That may well be good enough. 

That's called an estimate. A rough estimate for sure, but it's an estimate

From the same blog (a good one BTW)...

• We're on an enterprise system now and management needs to know how long and how much cost it will take to get to a Minimal Viable Product. The first release has to be functionally complete in order to be competitive. Everyone understands that this effort will take several months to get to beta-level code.  Management needs some idea of what they’re getting into, how long it will take, and how much it will cost.

Now we're into the realm of actual estimating

Are No Estimates Better Than Estimates?

Before answering this another question needs to be answered...

What is the value at risk?

This means how much money and time are you willing to risk without understanding how much time and money is at risk.

So before anyone can answer the question about estimating value, that question needs to be answered by the owner of the money. NOT to consumer of the money. 

This at risk question rarely comes up in the agile world. It doesn't come up enough in our formal FAR/DFARS acquisition work either. The at risk question is a risk management question. Agile claims to be a risk management process - which of course is laughable in our DOD/NASA/NRC/FDA/NNSA risk management world. All software intensive by the way.

So before venturing further, what's the value at risk must be answered. Then the owner of that risk, can tell those who should be working in the best interest of the owner of the risk, if an estimate is needed. Not the other way aorund.

Without this answer, the discussion on #NoEstimate is just sharing of personal opinions in the absence of any value at risk.

Related articles Time to Revisit The Risk Discussion When We Say Risk What Do We Really Mean? More Uncertainty and Risk Measurement of Uncertainty Estimates in Software Development. New Frontiers. Risk Management

There is a twitter discussion going on around Neil's post of People Need Estimates. This is a typical agile approach. No real domain or context, just a principle looking for a problem to solve. 

First let's establish some ground rules:

• I'm a strong advocate of agile development. I work prorgams that use agile. Big programs. Billion dollar programs. 
• When we are spending other people's money it's not about "us" and our favorite method of spending that money. It's about governance. Don't like governance, then don't work on projects that spend other peoples money.

And the final one ...

• Agile - in many cases - is spending people's money to discover the requirements. That's fine. But acknowledge it. Requirements emerge. Requirements change. Requirement are wrong many times. But don't say it'll be OK to use agile and ignore that you're spending - maybe even wasting - other people's money and calling it progress.

Neil says "People need certainty about what they will get and how much they have to spend. " This is not factually true in many domains, not is it actually possible. Those with the money need to know the confidence in the spend plan and the project duration. Certainty is not possible. But don't use that as an excuse for not having a confidence interval estimate:

• We will complete this project on or before the 3rd week in November, 2014 with an 80% confidence and a 12% error band on that confidence. This is easily developed and is done every month on the programs we work.
• We will complete this project at $1.6M or less with 80% confidence and a 10% error on that confidence.

This is what those spending the money need to know. Otherwise the project is Level of Effort. Work producing good things till the money runs out, get some more money continue doing good things. No problem. That is called maintenance. This is how PayPal uses Scrum. They budget annually for features, develop those features within that budget, repeat forever.

I love the notion "When estimating a date or cost you are creating uncertainty around those things, because you are guessing. "

Well stop guessing. Start being a software professional and start estimating. Have you done this before? How long did it take. Has anyone you know done it before? Go ask them. Guessing is lame. No estimates is even lamer. Worse, it's just being lazy. 

One last thing, "People still need 500-page business requirement documents." This is bogus. We work multi billion programs, with 100's of millions of dollars of embedded sofwtare and don't have 500 page requirements documents. Nonsense. 

If you don't know where you are going, if you don't have some notion of what done looks like, if you can't tell me approximately how much and how long, please don't start. You can be a binary search process for duration and cost for any tangible piece of software and within five question get without 20%. That's good enough to start. So start and take corrective actions with ne estimate along the way.

Finally "However, I would argue that #NoEstimates gives greater certainty than estimating does." There is absolutely no evidence for this. This is pure speculation and therefore also nonsense. Think about it,

• A builder comes to your house for a kitchen remodel.
• You tell him roughly what you want done. 
• You ask "how much will this cost, approximately?"
• "Oh I don't know, we're not good at making estimates, let's just get started and see where this takes us."

Are you out of your !@#$'ing mind. It is no different for software. Here's a nice short intro from Target Process, that actually makes sense.

Let's say the CIO comes and says "I need these features", and asks "how much and how long?" You say "Oh we get better outcomes when we don't estimates." Really, and some one believes that nonsense? I guess so.

Related articles Probabilistic Cost and Schedule Processes Estimates and all that... Cost (and Schedule) Estimating Foundations A Point Measures Need A Variance

Imagine that the government decided an intake of 2.500 calories per day should be the maximum for each person, regardless of age, gender, health, metabolism, dietary habits, etc. And imagine that the government also measured and enforced this every day, claiming it is “for your own health”, and handing out daily fines for each person who went over target. How would you feel about this practice?

Now imagine that the government decided that a speed of 130 km/hours should be the maximum for each driver, regardless of age, health, mental condition, road condition, traffic condition, weather condition, or the condition of their cars. And imagine that the government measured and enforced this, claiming it is “for your own safety”, and handing out fines to anyone who went over this “target”. How would you feel about that? Oh, wait… this is an actual practice in many countries!

I drove 14 hours from Bologna to Brussels yesterday, with a proper break every 2 hours, good nutrition, a healthy mind, a well-serviced car, and an excellent track record as a driver. During that trip I saw people not using their indicator lights when switching lanes, people overtaking others on the emergency lane, people using their mobile phones, and people driving vehicles that barely deserved the name “car”. And among those many thousands of drivers, I’m sure there were also some with mental problems, physical problems, mechanical problems, etc. However, the one who got picked out by the government was me. I got flashed twice because I drove “too fast”.

For every complex goal, there is a metric that is clear simple and wrong.

In organizations we see this all the time. Managers have a goal, such as faster time-to-market or higher productivity. But productivity is a very complex thing. It depends on motivation, creativity, innovation, collaboration, etc. And managers can’t measure all that stuff easily. So they reduce the metric to the simplest possible thing that can be measured with a computer: the number of hours people are physically at the office. And then they turn it into a target: the computer requires at least 8! Or else…

Measuring something meaningful is hard, so let’s measure something that is meaningless but easy.

Measuring real safety on the streets for everyone is next to impossible, so the government reduces it to the simplest possible metric that can be delegated to computers: speed.

I fear the day when governments find a way to have computers measure our daily intake of calories.

I’ve learned a lot about the challenges people face over the years across varying organizations when it comes to agile development and Scrum. But I’m always looking to help people solve their toughest or most nagging problems – and sometimes it’s easier to find out what those are just by asking.

So today, I’m asking you to take a moment to fill in a one-question survey for me. It’ll help me ensure I'm discussing the topics you are most interested in. The feedback you provide in this survey will be added to our list of topics to address in our blog and newsletter .

Please take a moment to fill in the survey here.

Thank you.

My friend and colleague, Gil Broza, is interviewing me for his Individuals and Interactions virtual training event. My topic? “Focus Keeps You Going.”

If you read my personal kanban series a couple of weeks ago, you saw how my focus kept me going. Even with a big interruption last week, due to a death in the family, I was able to maintain my focus, because I knew exactly what I had to do, to finish my work, to get ready for my trip today.

Gil has other great people in his event: Doc List, Ellen Gottesdiener, Mary Gorman, David Spann, Christopher Avery and Bob Schatz might be names you recognize. How about Rick Ross? David Spann? Caren DesBrisay? You might not recognize these names, and you should listen to what they have to say, too.

Check out Gil’s Individuals and Interactions training. Sign up. It’s a steal.

Code reviews and software inspections have existed for a long time in the software engineering world. They have been however only adopted by a minority of software development projects. Programmers have always been reluctant to submit their code to the criticism of their peer. The pair programming technique promoted by the Agile approaches has faced the same obstacles and is regularly ranked in the bottom of the agile practices adoption surveys. The situation has a little bit evolved with the development of tools for static code analysis. The automation of the ...

Actually, the previous blog post was number 700. This is blog post #701.

I wrote blog post #600 almost a year ago. In that year my readership has dropped from 1528 to 853 page views per day, and from 1078 unique visits to 629 per day.

Why? Well, I can make an educated guess.

I have changed my focus to writing the Management Workout articles, which of course means less time for my blog. And there are other new side-projects, such as Happy Melly and DARE. And I stopped making the Top 100 lists, which have traditionally been the biggest traffic magnets on my blog.

But I’m not complaining!

The Management 3.0 book has sold 17,000 copies in its first two years, and my self-published How to Change the World sold 3,600 copies in its first year. (Most self-published books sell less than 150 copies.) The number of RSS feed subscribers of my blog climbed from 6,600 to 7,290, and the number of Twitter followers climbed from 6,800 to 8,700. And the articles of my upcoming book, Management Workout, have (so far) been viewed or downloaded 37,000 times.

You win some and you lose some. :-)

Yes, this is an actual post on a LinkedIn forum

When the role of the project manager is to push the rock up the hill and then let it roll down again, there is little chance of success, and in the end little need for project management or the project manager. Cancel the project, everyone just go home.

Risk Management is how adults management projects - Tim Lister

 

There have several rounds of how to use analogies and how not to use analogies in the past few years. 

These involved notions like agile is an untended garden. Actually and untended garden and called a weed patch.

Or we can't really stop and develop a strategy, because we're always putting out fires. Actually firemen rarely put out fires. They spend the majority of their time preventing fire with fire safety, inspections, fire inspections. Their job is to never have fires start.

And of course for false analogies of the double pendulum as a stand in for chaos and unpredictability. Since the equations of motion are easily defined - an exercise for any upper division physics student - and a MathLab plugin, you can plot the path of the double pendulum. 

And my favorite the attractor analogy, in which it is presumed that some how in chaos theory the attractor attracts. Without understanding  that those pretty pictures of the attractor are the result of the underlying equations for the system.

So with that in mind, there is a new book from one of my favorite authors, Douglas Hofstadter, Surfaces and Essences. In the book Hofstadter makes the case for analogy as the fuel for creative thinking. Using Robert Oppenheimer's quote... 

whether or not we talk about discovery or of invention, analogy is inevitable in human thought, because we come to new things in science with what equipment we have, which is how we have learned to think, and above all how we learned to think about the relatedness of things.

But as always we need to take care to assure that those analogies we use to expand the conversation, don't violate the laws of physics, gardening, or mathematics.

Related articles The Misunderstanding of Chaos - Again Happy 50th Anniversary, Chaos Managing in the presence of all things

Everything is simpler than you think and at the same time more complex than you imagine. ‒ Johann Wolfgang Goethe

I'm going to be speaking at Agile2013 in Nashville this summer. My 75-minute session will be part of an Agile Boot Camp track that is targeted mostly at people new to agile to help them understand the basic concepts, terminology, methodologies, and practices of agile development. My session will be on Monday, August 5 at 2 p.m. in the Delta B room. I hope to see many of you there.

Here's the session description:

Agile Planning & Project Management

In this session we will shatter the myth that agile teams can't plan. We'll start by looking at the benefits of the short cycles of iterative and incremental development. We'll then look at the six different levels of planning that occur in agile organizations. We'll see what user stories are and why they've become the preferred approach to planning and managing the work of an agile team. We'll look at how user stories are estimated with the popular Planning Poker technique. To do that we'll discuss the merits of relative estimating and abstract approaches such as story points and what a point really means. With an initial plan created, we'll look at how agile teams use the concept of velocity to measure and predict progress. We'll also look at information radiators such as task boards and burndown charts. We'll conclude by looking at how these concepts can be applied to complex situations such as fixed-date and fixed-scope projects.

I'm going to be speaking at Agile2013 in Nashville this summer. My 75-minute session will be part of an Agile Boot Camp track that is targeted mostly at people new to agile to help them understand the basic concepts, terminology, methodologies, and practices of agile development. My session will be on Monday, August 5 at 2 p.m. in the Delta B room. I hope to see many of you there.

Here's the session description:

Agile Planning & Project Management

In this session we will shatter the myth that agile teams can't plan. We'll start by looking at the benefits of the short cycles of iterative and incremental development. We'll then look at the six different levels of planning that occur in agile organizations. We'll see what user stories are and why they've become the preferred approach to planning and managing the work of an agile team. We'll look at how user stories are estimated with the popular Planning Poker technique. To do that we'll discuss the merits of relative estimating and abstract approaches such as story points and what a point really means. With an initial plan created, we'll look at how agile teams use the concept of velocity to measure and predict progress. We'll also look at information radiators such as task boards and burndown charts. We'll conclude by looking at how these concepts can be applied to complex situations such as fixed-date and fixed-scope projects.

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted here.

Standard Scrum advice is that the daily scrum is strictly time boxed to fifteen minutes. Don’t dare let it go any longer than that. I want to share an example of how I sometimes have teams throw that rule out the window.

One challenge distributed team members face is getting to know one another. Members of a collocated team get to know one another through small talk. You and I get in the elevator together and ask each other innocuous but friendly questions: Do anything this weekend? How old are your kids now? and so on. This type of water-cooler conversation doesn’t happen with distributed teams.

Further, a distributed team’s meetings rarely have any of the playfulness that may occur with a collocated team. I’ve seen members of a collocated team hold up a rubber rat when another members goes too deep into a topic (referred to as “going down a rat hole”). Even if team members could do things like that when distributed, they often don’t know each other well enough to feel comfortable doing so.

As a ScrumMaster for a distributed team, I find it important to help team members get to know each other well enough that they can exhibit this type of playfulness. A great way I’ve used to do that is by starting each daily scrum with a bit of small talk--the type of conversation that happens naturally when collocated but won’t with a distributed team unless someone explicitly makes time for it.

I’ve gone so far as to tell teams that their daily scrums are required to start with five minutes of mandatory small talk. No mention of the project is allowed. Team members need to talk about their hobbies, what their kids did the night before, the great movie they went to, or things like that. After a mandatory five minutes of this, we start the normal part of the daily scrum, which is time boxed to a further fifteen minutes.

One of my favorite things to hear about during this part of a daily scrum is how team members in a different country will be celebrating a holiday. For example, on next Friday my friends in Norway will celebrate Syttende Mai, Norwegian Constitution Day. The first time I was on the phone with Norwegian team members and they told me they’d be off on May 17, I wanted to know what type of a holiday it was. Was it one of those holidays when you have a big meal with family (like US Thanksgiving)? Or was it a holiday best spent outside with friends (like US Memorial Day)?

Similarly, when on the phone with members of a London-based team I got to find out what Boxing Day was all about. I’d certainly heard about it despite living my whole life in the US. But I had no idea why the British were so anxious to put on boxing gloves and all fight each other. I also learned why they care about “bank holidays.” In the US, I’ve never cared when the banks were taking the day off.

I’ve learned about all manner of holidays from working with distributed teams this way. More importantly, though, I learned little details about the lives of my remote teammates. And that helped us all work together better. So, while I fully support a fifteen-minute time box to the daily scrum, for some teams, I will occasionally add another rule that we start with five minutes of small talk. I suggest you try it, I bet you’ll learn a great deal more about your remote teammates.
 

I got myself involved in co-organizing a conference.

Again.

But this is not just any conference. This is DARE!

DARE is a conference conceived by Maarten Volders, the organizer of the wildly successful Lean Kanban 2011 Benelux. Maarten has teamed up with the initiator of the weirdly successful Stoos Stampede (Amsterdam) (that’s me) and the Happy Melly business network.

DARE is for people who dare to discuss wild ideas about organizational change. For people who dare to introduce bold new practices in their businesses. For people who dare to make work more engaging. And for people who dare to quit their jobs.

DARE has a great line-up of speakers: Dean Leffingwell, Jim Benson, Benjamin Mitchell, Ken Power, Paul Klipp, Hakan Forss, Karl Scotland, and many more. And… it has a great looking website, launched yesterday! I find the layout quite daring actually.

DARE is for agile workers, lean practitioners, systems thinkers, Scrum coaches, Kanban experts, change leaders, complexity thinkers, culture hackers, lean startups, and Stoosians. Only the people who don’t dare to make at least something better in their organizations are not invited.

Will you dare to be there?

 

I have been working on a new version of the Management 3.0 license agreement, with input from the current facilitators and the friends of Happy Melly.

I needed a new agreement because: A) I want to allow other people to create Management 3.0 courseware modules; B) I needed a new pricing model that is more fair; and C) The licensing is taken over by the Happy Melly business network.

Here are 12 reasons why it’s a contract I’m proud of.

1. There is no legalese in this contract. I tested it by asking lots of people to read it, and nobody reported difficulties with the language.
2. There are no extortion prices in this agreement. It does not require USD 10,000 just for the right to use a name, which means it’s interesting for those who are not primarily motivated by big money.
3. The regional pricing based on a purchasing power parity index ensures that licenses are affordable both in wealthy countries and in developing regions.
4. The agreement introduces equality between creators and facilitators. You can produce content, or you can use content, or both. That’s up to you. There is no I-lead-and-you-follow in this system.
5. For facilitators the agreement guarantees freedom of organization, regarding event pricing, registration methods, customizations, evaluations, etc. The only constraint is the message.
6. The agreement guarantees that content creators get paid for the use of their slides, exercises, videos, and games. Free is nice, until you realize you have a mortgage to pay.
7. The agreement guarantees that translators get paid for their help in making content available in other languages and other regions.
8. The agreement has no pyramid scheme in the form of “geographical exclusivity” or “trainer accreditation”. The value is in trust and transparency, not in control and exclusivity.
9. The agreement is event-neutral. It covers everything from 1-hour presentations at conferences to full 2-day in-company courses. It is up to facilitators to decide how bring the message to those who need it.
10. The agreement is brand-neutral. It now mentions the Management 3.0 brand at the top, but this is easily replaced with any other brand. This means you can join us, if you have a great brand to share. {8-)
11. Creators and facilitators sign the contract with Happy Melly, making them a stakeholder of a new business that is cooler than Semco, Virgin, Whole Foods and W.L. Gore combined. {8-)
12. The agreement looks nice. I mean, seriously, why do contracts always look either boring or intimidating?

If you’re interested in creating content for Management 3.0 or facilitating Management 3.0 workshops or courses, go to the Management 3.0 website and fill out the form.

If you have your own brand and content and you’re looking for a way to adopt a similar licensing approach that is fair, simple, transparent, and scalable, contact me or the Happy Melly team.