Reviving Failed Ideas and Lost Causes

I liked Pavel Brodzinski‘s comment (here) on my networking post.  His point is right on and I wished I had elaborated on the point myself.  As Pavel notes, coming from the outside with fresh energy can revive previously-lost causes.  I also see some additional benefits/approaches to surfacing “already failed” ideas during your initial networking:

  • As an outsider, you can ask open-ended and naive questions about the failed concept without appearing ignorant.  Also, this approach gets people to talk more openly about what really went wrong.
  • Even if you think it is a great idea and you’ve seen it work, listen to the answers first.  To that end, don’t immediately endorse, complement, or promote the old idea.
  • Finally, listening to the answers is a great way to assess these stakeholders.  While Byham’s article emphasizes the need to establish credibility, credibility is a two-way street.

The ideal benefits from taking the these steps are a perspective on the “real” causes of the previous failure, an understanding of whether or not it may work again, and a map of the stakeholders you’ll have to navigate around.

Networking after moving into a new role

This Harvard Business Online article on networking after a promotion caught my eye (link here).  While it’s pitched to the recently-promoted, it has great advice for anyone moving into a new role.  The piece starts fast:

Most people aren’t naturally networkers. But if you’ve just been promoted or are about to move into a new job, it’s imperative that you start talking to lots of people and make connections right away, so you can acquire crucial information about your new job and succeed early. If you don’t, you might lack the facts you need for a proposal, for example, or you might bring up an idea you think is neat but has failed in the past.

The three tips noted in the piece are just fine.  However, I particularly liked the two insights in the open about fact-gathering and avoiding already-failed ideas.  I’ve made these mistakes before, so I appreciated the reminder of the pain that a little stakeholder identification and planning can prevent.

Networking is definitely an unnatural act for me.  While that isn’t usually a deterrent for me, in this case it means that networking always goes to the end of my to-do list.  My best approach is to target and reach out per the article, then get short chats on my calendar with those folks immediately.  If I procrastinate, all is lost.  Per the article:

[T]he first 30 to 60 days are when networking matters most, because that’s when people are deciding if they can depend on you or if you’re a loser who should never have been hired.

Mentorship Start-up “Crash Course”

I very much liked this BNET article by Jennifer Alsever on starting a mentorship drive (here).  The article is rich with sources and tips, so check it out.  The four basic steps are listed below:

Decide Why You Want a Mentor Program — Set your program up to succeed by defining goals and involving top execs.
Pair Up Proteges and Mentors — Create profiles and match people according to your goals.
Set the Rules for Engagement — Make sure people meet regularly — and know what to talk about when they do.
Keep Tabs on the Program — Make sure mentoring is providing the results you want.

Not that I’m looking to integrate mentorship into my group’s social media strategy, I appreciated the explicit decision and goal-setting advice.  I’ve seen many explicit promotions of mentorship in people development efforts, but I’ve never had any real idea of what that mentorship was supposed to accomplish.  Now that I have a chance to drive this topic, perhaps I can learn from those mistakes!

Remote Development — Tips for Managing Projects

Bas has an excellent list of tips for managing projects that include remote development teams (here).  The list itself is useful, but I particularly like how he built it.  Bas leveraged the comments from another post (here) to create this meta-tipsheet.  Below are a few of the ideas that we use quite a bit at SAP:

4. If possible, visit your offshore team during the development phase and make an effort to blend in.
5. Identify a leader you are going to be communicating with regularly and make him responsible for all updates and reports so there is no miscommunication.

SAP has an exchange program with our global delivery and global development groups based in remote locations (especially India). Also, we’ve developed a strong, independent PMO in our global delivery organization in SAP Consulting. They’re mature enough to be regular contributors of remote delivery content for our ASAP methodology (overview page here, NOTE: requires registration to service.sap.com).

7. Whichever way you choose for your communication, always support verbal communication with written correspondence.
10. The bigger the better is the rule when getting projects made offshore.

#7 applies to most projects, but never forget it for remote teams.  Tip #10 is very perceptive, as it notes “small projects are usually going to get you distracted workers who will be looking for their next assignment even while they work for you.”  Also, being “stingy” with work by doling it out piecemeal usually only attracts second-tier resources or desperate firms.

Innovation portfolio planning — using stage gates to manage risk

Innovation portfolio planning — from a Gary Hamel and Lowell Bryan interview (here) on The McKinsey Quarterly site (registration required) — starts with a plan to build capabilities (earlier post here).   Of course, building these capabilities require projects and programs.

Once you’ve designed your master plan, you can launch a series of initiatives aimed at achieving your goals…. The thing that really stops innovation is risk. CEOs can be terrified of organizational disruption because it can put at risk a company’s ability to meet quarterly earnings, which in turn is often what causes CEOs to lose their jobs. So part of what you need is a bridge so that they can be innovative but also keep their jobs.

The addition of program and project portfolio standards to the PMI standards inventory has been welcome.  The PM community needs to master these disciplines in order to drive good practices like the stage gate approach Bryan outlines below:

[S]tage-gate your investments in organizational innovation, [so] you can first learn what works and then scale it, without taking excessive risk.  None of us are smart enough to see in advance the ultimate answer, because the real answer lies in discovering the operating detail to make new ideas work in practice.  You can see the broad directions, but you… can’t even understand the secondary and third-level consequences of the design decisions you make. Those have to be discovered through trial and error.

Innovation Portfolio Planning — Building Capabilities

I’m going back to a Gary Hamel and Lowell Bryan interview (here) on The McKinsey Quarterly site (registration required).  Bryan here focuses on innovation portfolio planning, a topic which PMs should focus on as they look to expand their career horizons:

I like the notion of designing a managing concept or master plan—a master architecture, if you will—for every company. Such a master plan should lay out the big foundational elements to get your organization to work differently…

We use this approach a lot at SAP, though we talk about building capabilities.  These capabilities are the foundation for enabling us to work differently, but aren’t focused too narrowly on a specific outcome.  Rather, these capabilities are focused on supporting a strategic direction — e.g., improve project management maturity vs. improve scope management practices.

Pressure, Error, and Leading Project Escalations

While we’re on escalated projects it’s a good time to hearken back to Dietrich Dorner’s book on The Logic of Failure: Recognizing and Avoiding Error in Complex Situations.   Such projects are a high-pressure leadership environment, for sure.  It is critical to have no illusions about what lies ahead, especially in the Discovery (here and here) and Decision (here and here) parts of the leadership pyramid.

Ken Thompson’s The Bumble Bee blog at bioteams.com highlights two “tangents” identified by Dorner.  These are common leadership failure modes, largely because they are very tempting to pursue during a crisis.

We may resort to “horizontal flight,” pulling back into a small, cozy corner of reality where we feel at home … Or we may resort to “vertical flight,” kicking ourselves free of recalcitrant reality altogether and constructing a more cooperative image of that reality. Operating solely within out own minds, we no longer have to deal with reality but only with what we happen to think about it.”

Read all of Ken’s post here.  Note his great tips on how to deal with a “flying” leader.

SAP, India, and Innovation — this article understates the impact

It isn’t that this article by Navi Radjou of Forrester is wrong (here), but it misses at least three areas in which SAP leverages India’s talent and mind-set  Sure, what Ranjan and the SAP India team have done (and are doing) is impressive, but the impact of India and a globally adaptive approach are far more widespread:

  • Solution Development: I won’t belabor this, but many key parts of the SAP solution portfolio are developed in India.  The various SAP Labs sites in India moved quickly from coding functions, to designing modules, to delivering entire solutions.
  • Global Services Delivery: Jan Grasshof’s team is much more than a simple “me-too” outsourcing shop.  I was in Bangalore last week and saw the sophistication and speed with which they could bring value to the table.   A great example — coincidentially with Nokia, also in Navi’s article — was when SAP Global Delivery both supply chain expertise and rapid prototyping to accelerate an implementation. 
  • Management Development: My organization’s management program includes one week in Bangalore, a measure of how integrated a global mindset has become in our way of working.  SAP sends executives and managers half-way around the world so they can feel, taste, and touch what this new business world is all about.  We also have exchange programs — even within projects — to ensure better, more consistent communications and understanding among our various teams.

SAP seeding innovation via ecosystem collaboration

In the wake of our nice Q2-2008 results (here), I’m more convinced than ever that SAP’s ecosystem collaboration model (SDN here) is a un-heralded differentiator.  It may not be so un-heralded anymore…see this article from John Hagel and John Seely Brown (here).  Two of their lessons learned jumped out:

Ecosystems evolve over time, but the orchestrator plays a key role in seeding and feeding participant initiatives:  Evangelists for collaborative ecosystems often scare off executives with rhetoric suggesting that executives need to give up control and that ecosystems are “self-organizing.”

Too many evangelists preach collaboration “religion” — with all the ideology and doctrine that implies.  Injecting some “spirituality” is the better metaphor.  Executives should be reassured that giving up control doesn’t mean giving up influence and then the approach should be explained and piloted.

On the other hand, sometimes all spirit is taken out of the pitch to appear business-like.  I’m not sure an efficiency argument carries the day either:

Ecosystems are not just about connecting to existing resources—they help provide platforms for distributed innovation and learning:  Many executives tend to view ecosystems in static terms: diverse resources can be accessed and mobilized through ecosystems.

Team Composition — Lessons from Pro Wrestling

Though it isn’t mentioned in this profile, my “most frequent” Myers-Briggs personality type (INTJ) supposedly prefers to work with colleagues of the same type.  Perhaps I’ve learned that this is a mistake, for now I am careful to ensure that my team has some degress of contrast in types.  In particular, I’ve found that conflicts between and among the same or very similar types can be explosive.  In my experience, imbalanced teams are very brittle and break when things go wrong.

Take one of the great tag teams of all times: Cactus Jack and Abdullah the Butcher.  They seemingly had it all: skill, ruthlessness, treachery, endurance, showmanship, and a shameless dedication to ethnic and cultural stereotyping.  But like all teams, it is how you handle adversity that counts…

It is hard to recommend skipping much of such a fine match, but the non-connoisseur might want to start the video about five minutes in…

%d bloggers like this: