Harassment

I actively support a corporate culture of inclusiveness and respect, and have no tolerance for bullying or harassment in the workplace. Work, however, is only a portion of people’s lives. Technology is all around us, and the internet can be a source of  suffering. If you, or anyone you know, needs assistance, RAINN has resources to help. No one is alone.

Privacy and Projects

“Scientia potentia est.” Thomas Hobbes, Leviathan

“Power tends to corrupt and absolute power corrupts absolutely.” Sir John Dalberg-Acton

Knowledge is power, power corrupts.

Economics classes point out that information is needed for rational decision making, and rational decisions result in the efficient allocation of resources. What happens, though, when one party has information that the other doesn’t? Suppose you bought a house that the owner knew had toxic mold problems but failed to disclose? The seller walked away with more money than would have been possible had information been disclosed, not only an inefficient solution, but one that most people would label unfair. No one would willingly pay more than something is worth to them. Knowledge is power.

The power of private and personal information has been used to impact lives all over the world. It isn’t just a potential. The United States Supreme Court nomination of Robert Bork was upended by his video rental history. Identity theft cost the US $15B in 2014 and 700,000 stolen tax returns in 2015. In World War II and elsewhere, information cost lives.

Privacy matters.

You, your projects, and your company must take privacy into account. This is an article on basic principles. There are also numerous articles to help convince a team that privacy matters. For example, this one on LinkedIn, this one from Santa Clara University, this one from The Atlantic, or this one on a blog. There are resources available from the International Association of Privacy Professionals. Privacy is an ethical obligation. Even if it wasn’t, consider the sanctions that can be levied by the European Union’s General Data Protection Regulation laws for failing to meet requirements.

Remember, information you don’t have, you can’t be forced to disclose or accidentally leak. Information you have, you also have an obligation to secure and protect. When you collect it, you must state for what purposes you will use it and then comply with that statement. Information belongs to the individual, and it’s their right to ask for it to be corrected or deleted. It’s really just that simple.

This article started with two quotes, and finishes with another:

“If you can’t be a good example, then you’ll just have to be a horrible warning.” Catherine Aird

 

Never Miss a Date!

You can make every software development project successful.

Interested?

Ready?

Here’s the secret: Apply PMI’s project management knowledge areas.

It’s that simple.

I’ve been in software development since before high school, and have seen every type of success and failure imaginable. Maybe your project isn’t year-long, involving 200 people across many countries with a budget of a hundred million dollars. Maybe it’s five developers in a basement for a couple of months. I don’t know the particulars of your situation, so I couldn’t do the business analysis necessary to suggest one development methodology over another. Instead, I’m suggesting that the application of knowledge will make your projects better in general. If you understand these knowledge areas, and understand them well, you will understand what trade-offs you are making in your process and projects. That will enable you to better direct your projects to successful outcomes, regardless of the size of your project or development methodology you choose.

In order, the top ten reasons for failure, in order of importance:

  1. Communication Management – Three articles on communication so far. That wasn’t an accident. Projects, first and foremost, live or die by communication.
  2. Risk Management – The solution has been architected, coding has progressed, things are looking good, however the implementation can’t be stabilized. Review indicates a different architecture must be chosen. The schedule is blown, the budget is gone, the project fails. The qualification and quantification of uncertainty is what risk management is about. Every project I’ve seen that failed to “make its dates” had no risk management strategy. It’s not only identifying risks, it’s actively communicating and managing them in a timely manner. A good risk plan will save a project by stating what conditions it will trigger and how act appropriately to manage the impact. Think of it as carrying an extra set of batteries for when you take photos on vacation. Batteries die? No problem! You have another set. Yup, it cost a little money – but documenting your vacation experience is priceless.
  3. Time Management – The usual cycle is for managers to look for estimates, wring every bit of “buffer” out of estimates (the estimator’s attempt to manage uncertainty, which is to say risk), then create a ship date. Has this ever produced an on-time project? Not that I’ve seen. A schedule is a map of the project. It contains all activities (scope), resources to complete (cost), and when those resources need to do the work (time). Failure to create a realistic schedule, then failure to manage against it, cause project failures.
  4. Integration Management – This failure happens on two dimensions. The first is the organization’s leadership doesn’t believe that they need any project management, so either fails to have a project manager or fails to listen to an experienced project manager. The second version of this failure is assigning a project manager who doesn’t have the knowledge or skills to do the job. “You’re great at laying bricks, Bob – we’d like you to manage the construction of our next building.” Unfortunately, Bob is great at bricks, but doesn’t know anything about monitoring and controlling a project.
  5. Scope Management – As the project progresses on an agreed plan, things get added – hey, it should be a simple fix to allow users to change background colors, right? Sure! Scope is everything you’re going to do, and, inversely, everything you’re not going to do. Poor change control, along with an unwillingness to adjust either schedule or cost baselines, results in failed development projects. Every accepted change changes the whole project; have a change control process. Reject scope when appropriate, or accept and re-plan other aspects of the project.
  6. Stakeholder Management – The project was completed in record time, and is ready for implementation. The IT director is assigned the job of deployment and says, “Hey, wait – this won’t work. Half our users are only intermittently connected!” There are basic questions for the start of every project: Were all the stakeholders enumerated? Where their needs and requirements considered? What is the urgency of solution delivery? Failures in this area causes work products to be rejected. Scrum tries to control for this with a product owner who is the source of requirements, but also assumes the product owner has done the right business analysis and thoroughly understands all other stakeholders. If the product owner isn’t a business analyst, you’re probably doing it wrong.
  7. Cost Management – A project merrily moves along, assuming full dedication of all personnel. The reality is that developers are often assigned to many different projects. Managers often fail to account for that and consequently over-allocate developers. Part of that is failure to account for the productivity loss in context switching. Also, managers wrongly assume their project is top priority. Just because it is important to YOUR career doesn’t mean it’s important to someone else’s! Adding more developers doesn’t necessarily mean a project gets done quicker, even if those developers are more senior. As the number of people go up, more work is lost to the “friction” of working cooperatively.
  8. Quality Management – Yup, we wrote a lot of code. Too bad it doesn’t work in integration. Guess we should have planned for that. A quality acceptance plan is important to ensure a development project meets the goals that are set out for it. It can also be a check against gold-plating.
  9. Procurement Management – Okay, okay, stop me if you’ve heard this one: Manager throws out an RFQ, picks the lowest quote, and three months later gets something that doesn’t remotely resemble what was expected. There’s a whole process for managing procurement properly. Not every project has a procurement component, but if one does, it is essential to manage it properly.
  10. Human Resource Management – Each part of this list has started with a dreary failure. Instead, let’s talk about success. A couple years ago, Avengers was a popular movie. I held a “bug smash” (“bash” == “finding”, “smash” == “fixing/resolving”) for one of my teams. It was Hulk-themed, as in “HULK SMASH!” A twice daily report went out recapping the contest, morning and night, for a week. We gave out $50 gift cards along with Hulk-themed prizes for most bugs, most severe bugs, most code reviews completed and most helpful as nominated by peers. It was the most fun we’d had all summer and a good team building exercise. Be a source of motivation and inspiration, and celebrate success with your team.

There you have it – your spell book for success. Go study, then be successful.

Numerical Nonsense

Figures often beguile me, particularly when I have the arranging of them myself; in which case the remark attributed to Disraeli would often apply with justice and force: “There are three kinds of lies: lies, damned lies and statistics.”
Mark Twain’s Own Autobiography: The Chapters from the North American Review

It wasn’t actually Disraeli, but numbers are persuasive. If I said, 68.7% of statistics are deceptively presented, that sounds pretty authoritative, doesn’t it? It’s also completely made up. That’s an egregious example, but one of the first uses that occurs to any student of statistics is misuse. For a clear view of what that looks like, head over to Math With Bad Drawings’ article “Why Not to Trust Statistics.”

There’s two messages here. First, as a consumer of statistics (the language of business), understand numbers and question them. Know how the information was gathered, how it was summarized and why it was presented as it was. Remember that correlation does not imply causation. Second, as a producer of statistics, you are ethically bound to represent information in an unbiased fashion. Manipulating math to use a “magician’s force” on a decision is unethical.

Spellbound!

I’ve suggested you follow James Whittaker before, and he has a new book that blends perfectly with this site’s theme. You can buy a copy from Amazon.

I like to have signed copies of things, so I attended one of James’ talks today. James was demonstrating how a single word can evoke the person who spoke it. It went something like this:

James: “I say DREAM, you think…”

Me (thinking): NEIL GAIMAN! No, that can’t be right. Well, hold on. Is that Tengwar in Quenya mode that James has tattoo’ed there? I mean, he must know about Magic the Gathering based on these slides. Probably AD&D, too, since he’s referred to verbal, somatic and material components in other talks. That’s all pretty geeky. Maybe he does mean Neil?  But that doesn’t…

James: “… that’s right! Dr. Martin Luther King!”

Me (thinking): Oh. Yes, of course. That makes more sense in context. Obvious even. <Pause> How does my brain even work?

Skill and Genius

I never really know what to say when I meet famous people.  It’s awkward.  I mean, we’re complete strangers, but I often know weird and interesting facts about them – that seems uncomfortably invasive.  For actors and writers, I’ve now settled on a simple autograph moment, “I enjoyed your work; thanks for sharing.”  It’s one thing, however, to appreciate skill, but another to appreciate genius.  I’m going to define genius as someone who blends multiple, unrelated skills into a single package that seems marvelously and magically unique.

Paul Reed Smith visited The Seattle Guitar Store in July 2015.  I heard in person some of the stories I’d watched online.  When it was my turn to get my guitar signed, I was so beside myself that I put my guitar case on the counter upside down.  Why?  I’d been reading about PRS Guitars since I was young, long before I could afford one, and here I was meeting The Man Himself – and he is a genius.  His guitars are, literally, like nothing else I’ve ever played or heard.  It’s just not the wonder that are his instruments, it’s the unusual blend of skills that got him to where he is.

What makes Paul Reed Smith a genius?  It is abilities and skills he both possessed and developed.  He started repairing guitars and determined his passion was to build them.  It’s not enough to just build guitars, you have to sell them.  He developed sales skills, pitching them to artists, with his big break coming up when Santana bought one.  To be able to scale meant learning about manufacturing and the business of manufacturing (“If you make 8% in manufacturing, you’ve had a pretty good year”).  He became an expert in marketing, creating a set of differentiated product price points for every budget. He sought mentors in the great builders of guitars to perfect his craft.  He became a better musician along the way, providing even more insight into making guitars. Most of all, the thing that sets him apart from other luthiers, is that he is an engineer and a scientist.  His quest is to understand what makes an instrument great, to know what physical qualities make an instrument special.  He creates a hypothesis, tests against it, and incorporates what he learns.  Year over year, you can see the evolution in the resulting instruments.  I’m passionate about clever engineering and, as far as I know, that engineering skill is unique among guitar builders.  Musician, manufacturer, engineer – an unusual combination.  His passion was building guitars; his genius was in building them better at scale, creating a $40M company renowned for quality and sound.  He did it by constantly learning, constantly improving, constantly developing new skills.

The photographer at Musicstorelive.com is a *genius*. Check those folks out.

What does integration of all those things looks like?  Look at the guitar on the right.  Beyond the masterful photography that highlights its beauty, it is an amazingly figured piece of maple that is unlike any other I’ve seen – look at how the grain on the horn points to the center.  Why are PRS guitars almost “too pretty to play”?  I can nearly hear Paul Reed Smith’s thoughts:  If you see it, and it’s pretty, you’ll want to pick it up.  If you pick it up, you’ll want to play it.  If you play it, you’ll hear the sound.  If you hear the sound, you will buy it.  It starts with how it looks.  If you have any doubt, watch Rob Chapman try to talk himself out of a guitar that sounds wickedly good in his hands… because of the looks!  Paul Reed Smith got it exactly right.

I write about project management, but to be successful, you are going to need to do and be more.  Although it’s said that project managers don’t need to be subject matter experts, to have a career, it’s essential to think of the full range of talent and skills you bring to the table.  What insights do you have that make you unique?  What can you dive into deeply to provide value?  What new things will you learn to maintain marketability beyond your employer?  What synthesis of things make you a genius?

Answer those questions and maybe your next introduction to genius won’t be awkward, because you’ll look in the mirror and that genius will be you.

(If you’re curious, here are some additional links about Paul Reed Smith, with the last highlighting my awkward connection to Andertons…)

Communication, Part Three

Okay, we left off with the idea that communication planning is the process of determining the information and communication needs of project stakeholders. Information needs to be available to them in a timely fashion. Projects don’t have problems, people do – communication allows you to manage stakeholders and resolve their issues. Project performance information which is accurate and predictably timed (“this report goes out every Monday morning!”) is what allows the project to be managed.

The best communicators use the appropriate medium for their message. If a matter is urgent, a text, phone call or office visit may be better than email. If a matter is long and complicated, a short paper with follow up meeting might be best. If an official document, certified mail, return receipt requested, might be the best choice.

Here are some notes on topics I think are important:

Emails

  • The best emails are:
    • Precise – clear, unambiguous
    • Concise – no one is paid by the word
    • Direct – what do you want?
    • Easy to understand – simple is good
  • Noise and misunderstandings arise from:
    • Cultural differences
    • Technical vs. non-technical
    • “Tone and voice” of writing
    • Dashing off email replies too quickly

See what I did there? 🙂

Presentations

Do you want to give awe inspiring presentations? How about a perfect interview? Look no further than Dr. James Whittaker’s presentations on stage presence and other topics.  Follow all the links on his site, watch his videos.  Here’s one of my favorites, the power of story.   Fair warning: Judicious use of bad language to make sure you’re awake.

Have Better Conversations

Crucial Conversations is a book that has been recommended for ages, and I’m doing it here. Behavior gets pathological when the pressure is too high. Stress shuts down cognitive process and starts a fight-or-flight response. This book goes through some tools to account for that. If you, or your listener, is amped to eleven, it can be very difficult to get your message across.

Put Stakeholders on a RACI Chart

RACI charts can important tools to segment the audience for communications. You can read more about them here. A RACI chart expresses roles for producing deliverables at any level of a work breakdown structure. I don’t use them a lot, but find them pretty handy when dealing with matrix organizations.

  • Responsible – Role responsible for performing the task. There may be multiple “Rs”
  • Accountable – Role with overall management responsibility for a task; accountable for “showing up with the deliverable”. Only one “A” per line
  • Consulted – People who provide input to help perform a task
  • Informed – People with a vested interest who should be kept informed

Status/Performance Reports

Reports help manage the project. The best status reports clearly direct the reader to action. Like email, they should be precise, concise, direct and easy to understand. It’s important to be consistent report to report. The reports should contain information, not just a collection of data.

Status reports are meant to answer questions and direct action. Where are we on schedule, budget, and deliverables? What was planned for and what changed? What corrective action do we need to take? Consider, if your features are getting completed, but your bug counts are skyrocketing, *maybe* you want to a) review your code quality validation procedures and b) pause to remediate those bugs. “Testing in quality” is almost always more expensive than producing better code in the first place. And are we “done” if we’ve produced all the features, but the product isn’t good enough to ship?

Meetings

Meetings are expensive gatherings of resources, yet frequently are neither well organized nor well facilitated. I’ve also seen meetings go the other way, rigid and formulaic rituals devoid of any actual information. The first type of meeting is usually junior personnel, the second type of meeting usually executive level.

Before holding a meeting, ask some questions:

  • What do I hope to accomplish?
  • Who would need to attend?
  • Do we really need this meeting? Can it be done some other way?

There are two great resources I’m going to direct you to. The first is a book, Death by Meeting. The second is an entertaining video by John Cleese, Meetings, Bloody Meetings.  Meetings, Bloody Meetings has been used as instruction for over forty years. It is an absolute classic for structuring meetings. The video can be can be summarized as:

  • Goal: Have a clearly defined goal
  • Agenda: Publish and follow an agenda
  • Participants: Include necessary people and only necessary people
  • Structure and Control:
    • Start/end on time
    • Make introductions when needed
    • Structure logically, discuss in order of importance not urgency
    • Keep moving forward, drive toward making decisions
    • Recap
    • Listen and communicate collaboratively
  • Document: Document discussions/decisions and action items/owners
  • Summary: Send out summary and meeting notes

So that’s some tips and tricks.  Go forth, and communicate better.

Beware — Here There Be PMs!

What does it look like when two professional project managers live in the same house?  A lot like this:

This is in the back corner of our home office. There’s a deep backlog and epics on the left, backlog on the board and scheduled house items. There’s daily things that we don’t bother with (cook meal, clean dishes), but everything else gets scheduled. The calendar is rolling three weeks, since four seemed like too far out. This photo was taken in the middle of coffee scrum, as Saturday morning is when things are planned out and the calendar adjusted.  It might be too much for some — but household projects get finished.