Posted on September 15, 2014 by Paul Ritchie
Steve Kerr uses a General Motors cautionary tale to show us that it isn’t enough to have incentives that appear to reward desired behavior. In this HBR blog post, he notes that:
Although managers’ bonuses are based partly on vehicle-quality improvements, and safety is supposed to be paramount, cost is “everything” at GM, and the company’s atmosphere probably discouraged individuals from raising safety concerns. Earlier this summer, a former GM manager described a workplace in which the mention of any problems was unacceptable.
Kerr’s critical insight is that while GM could point to formal quality incentives, these incentives didn’t have the required impact on its managers’ behavior. The money quote for me is this:
In order to properly align its incentives to support its mission and objectives, a company must determine what managers and employees believe they are being encouraged to do and not do.
Filed under: PMO | Tagged: General Motors, Harvard Business Review, incentive schemes, Quality, Quality Assurance, Quality Management | Leave a comment »
Posted on September 9, 2014 by Paul Ritchie
[The proposal of a BYOD (Bring Your Own Device) communications campaign] strikes me as a bit too “happy/clappy” about promoting BYOD adoption. Explaining the process won’t address deep-seated privacy concerns like Peter Nolan’s. If done the wrong way, such promotions smack of the old IT “if we explain it to you lunkheads one more time it will sink in” mentality.
I started as a BYOD advocate and I’m OK with it for myself, at least for certain devices (e.g.,work email on a personal tablet). However, if we in IT want to control devices, we should expect that some won’t want to hand over their personal property. Therefore, if we want to control them, we should be prepared to provision them.
Also, I’m just not sure that BYOD is a great lever for preventing shadow IT. My suggestion would be to start with a more open IT portfolio process, which would ensure that everyone buys into what’s proposed, being executed, and how approvals and controls work.
Adapted from a LinkedIn comment on this post re: shadow IT and trust as a strategy to prevent it.
Filed under: PMO | Tagged: bring your own device, BYOD, choose your own device, CYOD, IT Strategy, Mobile, Portfolio Management, shadow IT | Leave a comment »
Posted on September 8, 2014 by Paul Ritchie
[The study delivers] a tough, but needed, message. HR leaders get thrown under the bus for these projects too often, which leads them to reach for visible, but ineffective, change implementation tactics.
To that end, I really like the point about realism re: expectations. Many change initiatives are heavy on marketing-style communications, which are easy to produce and point to as a tangible work product. But they’re often only one-way messages about how great the Brave New World will be. A multi-layered stakeholder management approach is a lot tougher, requires sustained effort over time, and has less-tangible payback.
Ultimately, function and process leaders need to own the change initiatives for their areas, which is why CEO ownership and involvement — again, sustained over time — is so critical. Line managers and staff won’t respond if it’s just a speech, new PowerPoint templates, and a monthly newsletter. They will wait until the change project is noticed, measured, and rewarded by the leadership team.
Adapted from my comment on a LinkedIn post re: this Forbes article from Victor Lipman: “New Study Explores Why Change Management Fails – And How To (Perhaps) Succeed“.
Filed under: PMO | Tagged: executive buy-in, executive sponsor, Human Resources, leading change, Organizational Change Management, stakeholder management, two-way communication | Leave a comment »
Posted on September 3, 2014 by Paul Ritchie
From a Quora question: What can I learn right now in just 10 minutes that could be useful for the rest of my programming career?
This was an excellent answer that focuses on planning for code vs. jumping right in. I learned this working with my son on his Scratch game. When it had a bug, I had to steer him back to the storyboard, then back to diagnosing the problem.
Answer by Jeff Darcy:
That programming is about solving problems, not writing code. Here are the four basic tasks that an individual programmer must perform.
- Define the problem (requirements and constraints).
- Define the solution (algorithms and data structures).
- Express the solution in code.
- Prove and/or test correctness.
A lot of people get really good at #3 because it’s by far the easiest, but never master the other parts and as a result remain mediocre programmers at best. Often a good programmer can solve a problem without writing any code at all, by using their knowledge and experience to avoid a problem or find solutions that don’t require new code. In a team, an experienced programmer can often contribute most by helping people with the other non-coding tasks, including a vast array of tasks and skills that don’t even come into play for an individual working alone (and were thus left off the list for the sake of brevity).
Once you’re proficient in using the tools of your trade, further expertise comes from understanding a particular problem domain other than programming. It might be something serious like physics or medicine. It might be something venal like ad targeting or high-frequency training. It might be something frivolous like games. You might switch specialties several times during your career. In any case, being a great programmer means applying the technologies and techniques at hand to some goal other than programming itself.
Filed under: PMO | Tagged: Application Development, Coding, planning, Quora, requirements | Leave a comment »
Posted on September 2, 2014 by Paul Ritchie
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“.
Filed under: PMO | Tagged: contrarians, criticism, negative feedback | Leave a comment »