New Show Announced on ThisWeekIn Network #TWiCCourtesy

You heard it here first, the ThisWeekIn Network is announcing its latest show titled This Week in Common Courtesy.  In this week's episode, Derek Huether expounds upon the topic of common courtesy.

Guest 1:

Our first guest is none other than TWiVC host, Mark Suster. Mark had quite a bit to say about the right way to cancel a meeting.  I certainly agree with his frustrations.

Thank you Mark for the short but to-the-point reply.

Guest 2:

After a (Generation Y) Mahalo employee gave his resignation notice via email, CEO of Mahalo and TWiST Host Jason Calacanis, calmly explained the value employees provide, just by showing up for work.  He went on to provide valuable insights to help some Generation Y understand their place in the world and what they deserve.

After this very instructional message, you'd think members of Generation Y would have had the common courtesy of listening.  A few days later, I reported an average performance rating for a (GenY) subordinate.  She then argued with me about not giving her a perfect 10.  When push comes to shove, I’m the one doing the assessment.  Have the common courtesy of respecting that and ask how to excel in your position, not just show up.  Jason's supporting comment to me was:

Jason, though she is no longer with our organization, I will make sure she gets her trophy.

That's all the time we have for this week.

I would like to thank @PowerVPS We're powered by the cloud

& @Jason We are entertained!

Don't forget to thank our sponsors and use the hashtag #TWiCCoutesy

My Caffeine Fueled Rant

People who know me know that I drink a lot of coffee.  I'll drink it hot.  I'll drink it cold.  I'll drink it from the pot, 9 days old.  OK, not 9 days old.  That's just gross.  One of the places I like to drink coffee is a diner.  9 out of 10 times, diner coffee is good.  It's simple, it's basic, and...did I say it was good?  Don't tell me it's organic, fertilized with bat guano from El Salvador.  I really don't care.  The other think I like?  It's usually $1 for endless refills, printed with pride on the menu. This post isn't about cheap coffee.  It's about a pet peeve of mine.  It applies to me ordering drinks at a restaurant.  Here comes the rant.

Today, my family and went out for lunch.  At the restaurant, I plainly saw the prices for everything on the menu but one thing.  Beverages.  Yes, drinks.  Where the hell are the prices for the drinks?  Is this some kind of trick or tactic? Am I to be embarrassed by the fact that I am unwilling to pay $3.00 for a fountain soda or $8 for a beer?  Chances are, if you don't post the prices for your drinks, I'm going to order plain old tap water.  Screw you and your clever lack of information.  It's not my job to ask you how much my drink is going to cost.  You are providing me with a service and that includes prices for the food and drink I'm willing to have with my meal.

If you leave the post at that, I think it stands on it's own.  If you want me to put a project management spin on it, here goes.  If you are a vendor, and you're doing contracted work, don't make your customer ask.  I hate the big reveal.  If you're going to do contracted work, and you fail to inform your customer what the cost is going to be, you should eat it.  Yep, eat the cost.  Why?  Did you promise to throw in a pair of Ginsu knives when you delivered that product?  I'm going to go out on a limb and say no.  Then why would you expect a customer to give you more money for services rendered or product delivered?

I know there are always exceptions.  What if you, as a vendor, don't know how much it's going to cost?  That's fine.  Communicate with your customer.  Treat them like the intelligent beings they are.  They were smart enough to hire you, right?  Then keep them informed and guide them through the options.  Don't sneak that $5 cup of coffee onto the final bill and expect a 20% tip.

Takeaway? Vendors:  Keep your customers informed and don't make them ask. Customers:  Don't let vendors get away with the big reveal.  It will just leave you feeling short-changed.

When Agile is no longer agile

One of the things I like about Mike Cottmeyer's blog is he sometimes asks philosophical questions, if he knows it or not.  He posed the question, How agile is Agile?

When I've asked vendors if they leverage Agile practices, I've discovered many shades of gray.  I'm sorry to say, I've seen people pervert the original 12 principles of the Agile Manifesto to the point the mere mention becomes the punchline of jokes. It's easy for me to become incited, when Agile becomes the scapegoat for poor leadership or process. I still believe the 12 principles are the framework in which we decide if Agile is still agile.  If the Manifesto is no longer the Agile bellwether, perhaps it should be refined?

Agile will stop being agile when we start to detail all possible inputs and outputs and actually believe we can predict or plan our way out of every situation.  I think it will also stop, if the Agile community as a whole, disagrees with the Manifesto.  All laws can come before the U.S. Supreme Court and be argued as to their constitutionality.   Sometimes I wish projects or activities within Agile projects had a measurement of their agility and then blessed by a governing body.  Granted, the Agile Manifesto is not the U.S. Constitution and the Agile community does not need a Supreme Court.

The best measuring device I can rely is my own limbic system; My gut feeling.  I'm sure you know what I'm talking about.  It is not as easy to say something feels Agile as it is to say it does not feel Agile.  When did this all become so overly complicated?

Image Source addogaudium.wordpress.com

And The Best Methodology Is

The question is always asked, which Methodology is best?  It is interesting to see or read the responses from people and their reasoning behind their opinion.  I actually don't like to use the term Methodology. I would prefer to use the term Approach.  Merriam-Webster defines methodology as a body of methods, rules, and postulates employed by a discipline; a particular procedure or set of procedures.  An approach is the taking of preliminary steps toward a particular purpose.  THAT is what people do.  If you review the PMBoK or the Agile Manifesto, neither are going to say in the event of A-B-C, in this sequence, do D-E-F.  Life, application development, and project management are complicated enough.  You don't need to write an algorithm to know the next step needed to accomplish goals. There is a pain point in the industry that I've seen ongoing for several years now.  In this post, I'm not going to say which approach I think is better and why.  It's really kind of irrelevant.  I think what is important is we ask ourselves and our stakeholder. What IS important?

A while ago, commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It's an insightful post and I would recommend you go and read it.

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings.

My bridge to both blog posts is identifying Wants and Needs.  Both drive motivations.  Once you understand the motivation, you can answer the question "why?"

Before analyzing why one team likes one approach or has disdain for another, you have to question their motivations. We assume we all desire the delivery of value. That’s not necessarily true. Some are more motivated at protecting the status quo or their position in the program.

The hierarchy of wants, not needs, will commonly differ between teams, if we want to admit it or not.

Image courtesy of quickandirty

Ask Derek - Peanut Butter and Jelly Interview Question

peanut-butter-jelly

I received a question in the comments as to what possible answer(s) I expect to hear from job applicants, if I ask them how to make a peanut butter and jelly sandwich.  First, I would like to point out, I didn't think of the interview question.  A colleague recommended I ask it, when I told her how I found interviewing challenging.  You don't need to give a lot of background to get someone's perspective on how they would do it.

Everyone knows what a peanut butter and jelly sandwich is. They can wrap their heads around the concept.

How to make a PB&J

I'm going to go really high level on this because interviews are all about brevity.  I would first expect the applicant ask me which approach our organization traditionally utilizes.  (Organizational Process)  I would then respond waterfall or agile.  I would expect the applicant to know both.

Let's start with Waterfall

As a Project Manager, I would expect to read a statement of work, business case, or contract.  I need to know what need the project will address.  Do we need to feed one person or 1,000?  Do we need to ship the sandwich(es) somewhere?  I expect there to be a project charter.  I need to know the goals and objectives, scope, success factors, assumptions/constraints of the project.  I want to know project authority and I want to know organizational structure, so I know who is responsible for what and where everyone sits in the chain of command.

From there, we can go as heavy or light as deemed appropriate by the scope of work, budget, and schedule.  I'm going to assume the project is in order.  There will be a WBS, a schedule, and a budget.  We'll know what level of quality we must meet.  We'll know what resources we have available.  We'll know approved methods of communication.  We'll have plans to address any risks.  I'm not saying you need a formal plans for each.  Go as heavy or light on these as appropriate, but don't ignore them!  Keep the communication flowing, get the sandwich(es) made.  Continually verify you're within scope, schedule, and cost.  Make sure the sandwich(es) meet the quality standards of the customer.  Have the customer accept the sandwich(es), and go through project closeout procedures.  That will include getting paid, do lessons learned, and disbanding the team.  Let's eat!

So that I don't bore you too much, I'm going to break this post into two parts.  My next post will be if I had followed the Agile approach.  If anything, I think this should make for good comment fodder.

Regards,

Derek

The Goldilocks & the 3 bears of project management

No, I'm not blond nor am I talking about bears.  I'm trying to get people to understand there has to be balance in project management.  Once again, one of my son's bedtime stories makes a pretty good analogy.

As I'm reviewing all of the contract deliverables due from the vendor this month, I ask myself if it is really all that necessary.  I don't think so.  What do I mean by contract deliverables?  I'm referring to anything from a high level design (HLD) to detail level design (DLD), an integrated schedule (IS) to a cost performance report (CPR).  That's hundreds and hundreds of pages of documentation, every month, with the expectation the future will be predicted or the past explained.  Organization 1: Too much documentation and process - too little value.

This is actually quite the contrast from where I started as a project manager.

When I started out in project management, I worked for a very small organization that basically flew by the seat of its pants.  Nothing was documented.  If the customer didn't like the change, we'd just redo the work.  There was a considerable amount of waste but we were able to actually delivered some product (value).  In hindsight, if we would have had more documentation and process, we would have had fewer budget and schedule overruns.  Organization 2: Too little documentation and process - too little value.

More recently, I worked for a medium sized organization that was maturing its business practices.  They realized they needed a minimum level of documentation to help lessen waste and manage stakeholder expectations.  The goal?  Have the right amout of documentation and process to deliver the greatest amount of value.  For the most part, there wasn't too little or too much documentation or process and there wasn't too little value as a result.  For the most part, Organization 3 was just right.

In all seriousness, ask yourself the question, "for the task I'm about to commit resources to, is there too little or too much documentation or process for the amount of value I can expect to deliver?"

image courtesy of fcps.org

Never forget moms are stakeholders

I think it is only fitting to write a post about the most important stakeholder on the planet, Mom.  When giving gifts on Mother's Day, as children, we did simple things like made a card by hand, offered breakfast in bed, or picked flowers from the yard.  Our goal, from my perspective, was we tried to deliver what we thought our moms  (stakeholders) wanted.  As a father of a 4-year-old, my perspective of Mother's Day has now changed, though my son views the gifts (deliverables) as I did many years ago. This year, I thought my wife would enjoy some kind of gadget. Perhaps she would enjoy a day at the spa or  some other complicated gift.  What my wife did this year was very apropos.  She proactively said she did not want any gadgets this year, notably a camera, iPad, or something I would like.  Our son, clever as he is, sang her a song and made her a necklace.  Taking his lead, I took the three of us to my wife's favorite place to eat and tried to give her some alone time later in the day.

So, where am I going with this?  Find out what is valuable to your stakeholders and customers.  What you think has the greatest value may not be the same thing.  I know, I sound like a broken record.  But it's true!  Listen to what they say; deliver on what they want or need!

ADD / ADHD Project Managers

add

While you’re probably aware that people with ADD/ADHD have trouble focusing on tasks that aren’t interesting to them, you may not know that there’s another side: a tendency to become absorbed in tasks that are stimulating and rewarding. This paradoxical symptom is called hyperfocus.  So writes HelpGuide.org I've spent my whole life with all of the symptoms but never wanted to admit actually having ADD/ADHD.  Perhaps it was out of concern someone would label me and force me to take some drug that would change me.  Though it doesn't help that I drink copious amounts of black coffee, for the most part, I think I've fared pretty well.   I think back to my childhood, remembering every report card included a comment from the teacher.

Derek has a hard time concentrating and talks too much.

Hyperfocus is actually a coping mechanism for distraction—a way of tuning out the crap and chaos. It can be so strong that I become oblivious to everything going on around me.  I still think hyperfocus is an invaluable asset.  How do you think I can sleep for 5 hours a night and get so much accomplished?  From the moment I wake up to the moment I fall asleep, I have a thousand ideas in my head.  I scramble to keep up with them, writing them down or logging voice-notes.  I still really don't like all of the negative connotations associated with ADD/ADHD.  Sure, I have a wicked temper, I'm impulsive, and I'm very forgetful.  But, I don't think the last is an issue thanks to Evernote.  As for the first two, if you cross me, I will write you off and being impulsive just means I seize on opportunities.  Perhaps this is why I'm doing well on my current engagement.  I am asked to focus my attention on specific issues or opportunities and advise.  But seriously, you think of a successful project manager or entrepreneur and you tell me they don't have ADD/ADHD.

I hate to cut this post short but I need to...

Hey, look a butterfly!

(graphic courtesy of meggitymegs )