Creating an opening for contrary opinions

Because I can be quite intimidating on first encounter — I’m 6’4″ and err…250 lbs. — there are times when I get little feedback. People aren’t willing to speak up for fear of provoking the bear.

Quick tip I was given to get around this: explicitly seek out a colleague who will challenge me in such situations. It usually takes some time after taking over an organization or program, but I find someone with credibility and ability to do so. This approach makes it clear, in a concrete and visible way, that I value and reward contrary opinions.

And that I don’t bite or maul.

Adapted from a comment on a cross-post to LinkedIn by Diana Jensen on “Sparring: Why You Should Love Critics“.

How frequent releases help you satisfy and retain your best employees

Paul Ritchie:

Interesting piece on how continuous — or at least frequent — delivery of releases is good for employee satisfaction and engagement. Some customers for certain applications may need to be retrained to deal w/ frequent releases, but SaaS models have eased that learning curve.

Originally posted on Jayme C Edwards:

Think back to the last time you released to your customers. There was probably a brief feeling of satisfaction, hopefully a validation from the customer that you delivered what they wanted, and your team learned a thing or two about how effective they are at deploying and testing the changes that were delivered with the release. Soon afterwards, the team gets to start all over again and these lessons are forgotten.

If you think about a long term relationship, when two people haven’t talked for a while they can get nervous. “Does he still remember what I said about what we were going to do?”. “I wonder if they still feel the same way about me?”. This phenomenon is also present in product development, and the longer your team goes before releasing, the bigger impact these psychological (and measurable) effects have on the profitability of your business goals.

Keeping delivery staff satisfied

When a change…

View original 980 more words

Good meeting “rules” seed list and its use in practice

I like this meeting rules/tips list from Harry Hall (@harrythall). They’re all good, though I’d add “no open devices (e.g., PCs or tablets)” and “schedule the meeting’s end-time to allow people to get to their next meeting (e.g., end agenda at 9:50 AM vs. 10:00 AM)”.

One process tip: if this meeting will be an ongoing event or part of a project, have the participants make up the ground rules. In other words, don’t set a list like this — no matter how good — in front of the group. It says “here’s how we do business in my meetings”, which implies it isn’t their meeting. For one thing, some of these are meant only for the leader. For another, one loses an easy way to start one’s group norming, storming, etc.

My experience is that such lists are good aide memoires to that you can use to augment your team’s ideas…via a suggestion at the end.

Probing questions for your change management candidate

The methodology topic is a great one to use when interviewing potential change management consultants. My experience is that there’s a large group of “change” consultants who are merely rebranded MarCom (marketing communications) types.

  1. Challenge them to give you an example of how they used a change methodology.
  2. Bonus points if they can discuss how they integrated it with another framework (e.g., project or implementation methods).

Adapted from my LinkedIn comment to Rick Rothermel’s blog post.

Talent Development for Complex IT Programs

I just received a McKinsey brief on “Developing talent for large IT projects” that has the usual recommendations, but adds two useful insights.  From the opening section:

The responses [to a survey on levers for improving IT performance] reflect the challenge of attracting, developing, and retaining the right IT talent at a time when building a digital enterprise has become a priority for most companies. To succeed, organizations need to cultivate in-house talent for roles that require intimate knowledge of the business and the organization. Enterprises must recognize the value and scarcity of employees who combine IT savvy with business acumen and must build and support a staff of such people.

The authors lay out three recommendations:

  1. Focus on the roles that really matter: Here’s the first useful point. There are plenty of skills and competencies that can be outsourced, but the piece suggests ensuring that IT program manager, business change leader, and lead IT architect roles stay in-house.
  2. Attract talent by improving culture, benefits, and career paths: I really like the recommendation around career paths, because it identifies the biggest barrier to nurturing project-oriented staff. Where do they go next? From the post:”Career paths for leaders of large IT-driven projects are rarely clear or compelling, and they’re often nonexistent, which is one reason these leaders are in short supply.”
  3. Build IT project-management capabilities: a.k.a., train and build a PMO…err, a Center of Excellence.

Here’s one point of my own, related to career paths. Project and program managers need to drive this discussion, even if it’s in their own heads. While firms could be more proactive in career planning, we own our careers. If the project is sufficiently important and strategic — whether you accept the role, refuse the role, successfully deliver the project, or light a Viking Funeral — your next move may well be out of the organization. If you’re being asked, you’ll have a choice in front of you sooner or later.

Whether you like it or not.

Why is digital transformation disruptive?

I’ve found that other functions struggle with innovative technology when:

  1. They don’t know their processes particularly well. In this scenario, discussions about a mere port to a new platform get stuck on basic process misunderstandings.
  2. They try to jam existing processes on a new platform without considering new opportunities the technology brings. It’s a reasonable implementation strategy to simply port processes, However, if one doesn’t account for new cases — e.g., using mobile form factors to present demos or quote and approve in real-time — one may inadvertently foreclose those opportunities via short-sighted design choices.
  3. They deploy new process cases without a organizational change strategy beyond training. Take my CRM example above: if one’s sales force is made up of “order takers”, will they be able to leverage the new capabilities without intervention? If nothing else, one must ensure that debriefs of the top performers in this new capability happen and are passed along (via training, coaching, etc.).

Adapted from a comment I made on LinkedIn on this ZDNet post by Sven Denecken, noting some concrete reasons why digital innovation is disruptive:

Maintaining Outsourced Development Quality

Many firms that outsource want to reap all the savings from cutting costs on developers without accounting for the additional overhead they’ll need to manage developers who aren’t right down the hall. All the informal code reviews, requirements clarification, etc. that was done real-time and face-to-face must be made explicit and conducted remotely…often across multiple time zones. Furthermore, the project management performed by the outsourcing company is done for the benefit of the outsourcing company, not one’s own firm.

This overhead can only be ameliorated a bit with tools and technique: there is effort inherent in making inarticulate or tacit knowledge explicit. My heuristic is to add from between 25 and 33 percent more project management effort (beyond the typical in-house estimate range) to such projects.

From my comment on a long-standing LinkedIn post, this one on outsourcing QA.

Follow

Get every new post delivered to your Inbox.

Join 1,448 other followers

%d bloggers like this: