How to Help PMI Chapters & Members

After speaking with a few PMI Chapters, I see them (at least the ones I spoke to) suffering from one major issue.  How to they grow their membership?

Membership

Because PMI has created an ecosystem where people pay serious money to prepare for certification exams and then continue to pay good money for Professional Development Units (PDU)s to maintain those certifications, why don't the Chapters capitalize on that?  The PMI Chapter is much more than a monthly opportunity to exchange business cards.  They are a conduit to continued education.

PMI Chapters are trying to provide value to and grow their memberships.  If the membership drops too low, clearly there can be a problem. With the average annual dues for a PMI Chapter (in the United States) at $25, what value can they provide as an incentive to join the Chapter? Additionally, without collecting enough membership dues, PMI Chapters have to find other forms of revenue to sustain themselves.

I believe the solution to growing PMI Chapter membership (or PMI membership) is to make it more cost effective to be a member (of both) than it is to be a n0n-member pursuing or maintaining a PMI credential.  PMI and PMI Chapters should adopt the old American Express slogan membership has its privileges.

Idea 1:

The cost for PMI membership is $129 to join and $119 to renew (annually).  The cost for annual PMI Chapter membership averages $25.  PMI should require all Registered Education Providers (REP) to extend a discount to exam preparation training by more than $150 to PMI Chapter members.  Right there, the membership has paid for itself.  On top of that, they should discount single PDU offerings by at least 10%.

Idea 2:

REPs should profit share with the PMI Chapters. I see PMI Chapters selling advertising to training providers.  That model doesn't really scale.  Training providers are paying for advertising in the hope there will be revenue generated to justify the cost.  This caps the revenue the Chapter can make and provides no guarantee to the training vendor that the investment is worth while.  Why don't the Chapters just ask for a percentage of revenue with the agreement to distribute the training option to their membership?  It's a win-win agreement.

Idea 3:

PMI Chapters should make deals with authors and suppliers, to offer the same type of profit sharing model.  Think of Amazon affiliate links.  It costs you nothing to promote these products but if people trust your recommendation, you could potentially create revenue.  The same goes for the PMI Chapters.  If their membership trusts them, they could provide them discounts on products and services AND get a referral fee.

Summary:

Again, remember the old slogan for American Express.  Membership has its privileges.  It doesn't matter if you are a member of PMI, The Scrum Alliance, or Agile Leadership Network.  Membership SHOULD also provide discounts.

Or course I want to put my money where my mouth is.  My PMI-ACP 3-day workshop is $1495.  If a PMI Chapter member wants to take my class, they need only to identify the chapter they are a member of and I'll discount the cost of the workshop to $1250.  That will save them $245.  Additionally, I'll send $150 to the PMI Chapter they belong to.  If interested, just contact me.

Image Source: Pictofigo

ALN Arin Sime and User Stories

A quick thank you to Arin Sime and the local Agile Leadership Network chapter for an excellent workshop.  Tonight, Arin Sime of AgilityFeat facilitated a workshop on User Story splitting.  What I felt was compelling was not the discussion about the best size of a user story, what INVEST was, or even the best way to write a user story.  What I liked the most about the workshop was Arin's purposeful misdirection early on, having us write bad user stories.  That's right. Arin gave us instructions and had us write bad user stories by way of anti-patterns.  In software engineering, an anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.  Sometimes it's hard to write really good user stories.  Knowing if it's a good story usually falls under  IKIWISI (I'll know it when I see it), though people can commonly write really bad user stories and think they are great.  I'm not going to go into detail about what makes a "good" user story.  I'm about to turn into a pumpkin and I wanted to get this post out within hours of the event. If you get a chance, look up Arin and look up Agile Leadership Network.  Either way, you're going to walk away with something of value.

Image Source: My really sad Droid X

Waste In Software Projects

This evening I attending the monthly Agile Leadership Network event. I noticed a very familiar slide on Waste In Software Projects. It looks familiar because I have it in my training deck as well! Yes, my Introduction to Agile class has a slide that credits the Standish Group Study reported at XP2002 by Jim Johnson, Chairman.  In reviewing software systems, Jim Johnston, Chairman of the Standish Group, determined that in systems defined and delivered using a traditional / waterfall style approach almost half of all features developed and paid for are never used.  The question this evening was, for the 45% of the features that were never used, what was the cost incurred?  Well, I can tell you it's probably a lot more than 45% of the budget!  What if the features that were never used were actually the most costly as well? The rule we should learn here is we should eliminate the waste at the source, before it makes it all the way to the Production environment.  If a feature or product is never used, it's waste. But, since XP2002, have we learned our lessons?     Are we still delivering features that customers will never use?  I figured I would create a quick Google Doc that would collect some data. After giving it some thought, I decided to remove the link to the Google Doc.  The collection of data was just a distraction from the actual blog post.  Thank you to those to participated.

Niko-Niko Calendar

niko-niko

While I was at the recent Agile Leadership Network (ALN) event earlier this month, Dave Nicolette presented a talk on metrics.  I'll admit, I'm fascinated by metrics.  I remember working on the NIH Executive Dashboard and then the NCI Dashboard between 2004 and 2007 .  But since then, I've grown to look at metrics differently.  Though I've taken steps to ask myself questions to ensure my metrics are worth something,  I've seen the Hawthorne Effect in action and it made me question how metrics can be easily manipulated. Don't you hate it when you're trying to measure team performance and then they start acting all crazy due to upcoming dates like the end of the sprint or the end of a deployment cycle?  I've seen developers start to rush.  Risk goes up and quality can go down, just to try and maintain a velocity.  Well, Dave showed a slide in his metrics presentation that really hit home for me.  It's called the Niko-Niko (mood) Calendar. Let's say your position in the company is to ensure customer satisfaction.  A useful unit of measure would be NPS (Net Promoter Score).  Think of it as a customer satisfaction or “happiness” metric.  NPS is based on the fundamental perspective that every company’s customers can be divided into three categories: Detractors, Passives, and Promoters. By asking one simple question — How likely are you to recommend [Company X] to a colleague or friend? — you can track these groups and get a clear measure of company performance through its customers’ eyes.  I've written about it before in a post titled Outdated Success Criteria.

That's all fine and good but what if your position in the company is to ensure employee satisfaction?  As a manager or a leader you should be working to keep your employees happy.  How would you measure their happiness?  You could use a Niko-Niko calendar.  Each individual on a team should identify their daily mood in one of three ways: happy, indifferent, or unhappy.  Because I keep a daily journal of what I do, I recreated a calendar to see if there were any trends.  Do you see any?  Can you see the the days I was working at my other job and I was dreading a particular meeting?  Can you see the days I spoke to LitheSpeed or when I was hired by LitheSpeed?  Though you can't make everyone on your team happy, as a manager or servant-leader, you should be creating an environment that will, in the end, make them happier and more productive.  If everyone on the team maintained a mood calendar, a manager or leader could take action before negative feelings become caustic to a team.

P in your Network

I've recently been paying more attention to signs and indicators. Though Stop signs or Yield signs are a given, I'm talking signs that you find around homes (Welcome to our ool. Notice there is no "P" in it. Let's keep it that way) and businesses (Drink coffee. Do stupid things faster with energy). Last night, I attended the monthly APLN DC (Washington DC Chapter of the Agile Project Leadership Network). When friend and colleague Manoj Vadakkan kicked off the event last night, he announced that both the name (APLN) and logo had changed.  It will now be known as the Agile Leadership Network.  After telling people for the last few years that they could leverage agile principles and values in areas other than software development or just projects, I'm happy to see the change.  It should certainly help reinforce concepts like servant-leadership, outside of the application development world.  I went to the "new" ALN website and read a message on behalf of the board of directors.

In keeping with the agile spirit, APLN has continued to evolve since its inception. Over the last year or so, the national board has had an ongoing discussion about “getting the ‘P’ out”. That’s ‘P’ as in ‘Project’; as in Agile ‘Project’ Leadership Network. Why do that?

As agile practices for software development projects have become more prominent, broader application of agile principles and values has come more to the forefront. It is not that we no longer want to talk about these projects; we do and will. But we also want to talk about more than projects and we think the 10-year anniversary of the Agile Manifesto is an appropriate milestone to recognize that evolution.

Let this be notice to everyone out there to start updating their websites or documents listing APLN.