One of the fundamental mysteries in the practice of IT management is “why cant we get better at delivering projects?”  Much has been written about the subject, with the balance focusing on the negative – project failure, IT Fail, etc.  A recent article in MIT Sloan Management Review got me thinking about another angle on this question – maybe we are ignoring some fundamental, but less obvious signs that our projects are not positioned for success.  These signs, or weak signals, require different mindsets and toolsets to gather, track and act upon.

In my last post, I outlined a few biases that I have seen in individuals and entire organizations that block our ability to see weak signals that threaten IT project success.  The next step is to think about where these important, but weak signals may come from and how to go about gathering intel.

Detecting Weak Signals

Schoemaker and Day propose six ways to gather and interpret weak signals (actually they have 9 items, but the last 3 are more about acting than detecting).  I have added thoughts on how each could apply to IT projects.  Their six weak signal detection methods are:

1. Tap local intelligence
2. Leverage extended networks
3. Mobilize search parties
4. Test multiple hypotheses
5. Canvas the wisdom of the crowd
6. Develop diverse scenarios

Tap Local Intelligence

Project information tends to be distilled like the best vodka, over a series of multiple steps and through many filters.  Any hope to understand what someone on a project team is really thinking or feeling is hopeless through traditional status reporting and meetings.

Management By Walking Around (MBWA) and Toyota’s version, Genchi Genbutsu, are both philosophies that management can learn a lot by listening to the guy on the ground.  In addition to just making time for individual project team members in their work areas, a project sponsor could invite a team member at random to each project status meeting with the goal of hearing their top 3 issues.  If the cultural or political issues of doing this are overwhelming, the project sponsor could do it over lunch a few times a month.  It’s amazing to me how many project execs and sponsors work in different buildings and never make appearances in project facilities.

Leverage Extended Networks

What extended networks exist that apply to IT projects?  Execs of several companies sit on technology vendor advisory boards.  This could be a good channel to get feedback on a vendor’s performance elsewhere and to learn where their expert resources are focused.  The same goes for user group forums and conferences, with the former providing more up-to-date information but probably not as unfiltered.

I can think of several projects where smaller vendors were used but were unable to effectively leverage their few true subject matter experts across all of their clients.  This is not something the vendor would likely tell you and may only be revealed through weak network signals.

Mobilize Search Parties

“SWAT Teams,” quickly deployable teams of experts, are pretty common for large projects and programs once the implementation gets hot and heavy.  One of our healthcare clients used a SWAT team focused on technical architecture that was heavily used across 12+ projects when they were rolling out a new services oriented architecture.  But, this isn’t exactly what Schoemacher and Day are talking about.

This one stumps me a bit.  I’m trying to envision a small team whose mission is to snoop around and look for problems.  One could argue that this is one job that a good program office should perform, but this would only work with seasoned leaders who know what signs to look for.  I’d love to hear any examples of “search parties” that work.

Test Multiple Hypotheses & Develop Diverse Scenarios

Personal and organizational biases often make us “explain away” potential problems as low probability or even impossible.  Asking “what if?” could be useful but only if leadership is willing to dedicate time and potentially money to develop plans for contingencies.  The two scenarios I see most often that would benefit from hypotheses and scenario planning are:

1. Key project leaders get burnt out and leave the project prematurely
2. Small vendors implode

One question is when and how often to develop and test hypotheses.  This can be an important tool but one that won’t typically get focus from project teams.

Canvas the Wisdom of the Crowd

Prediction markets are an intriguing technique for gathering the wisdom of crowds.  While not universally applicable, there are some incredible examples of the accuracy of group predictions outlined in James Suroweicki’s Wisdom of Crowds.

One of my colleagues, Michael Krigsman, who is an authority on IT project failure, has developed a tool through his firm Asuret, that seeks out weak signals from project stakeholders through a survey-like mechanism.  I look forward to piloting it with a few clients.

In summary, there are 3 things I’ve concluded about weak signals:

1. We need to challenge senior business and IT leaders to be more involved with our teams on the ground and act on the signals they get
2. I think that the weak signals theme highlights the need to have seasoned project leadership.  PMP-certified managers just aren’t enough, at least for large and/or complex efforts.
3. There are some techniques that we can apply to gather non-traditional project signals.