6 Ways to Find Weak Signals

Share on LinkedIn6Tweet about this on Twitter9Share on Google+0Share on Facebook4

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.
Share on LinkedIn6Tweet about this on Twitter9Share on Google+0Share on Facebook4
  • Pingback: Tweets that mention 6 Ways to Find Weak Signals — CIO Dashboard -- Topsy.com()

  • http://www.pmhut.com PM Hut

    I can give you many reasons why IT project delivery is not getting better:

    1. Maturity: The IT industry is still not mature enough, compare it to the construction industry that is thousands of years old.
    2. Quality of the Programmers: The quality of the programmers is definitely not even remotely comparable to the quality of programmers until the early 90s. Programmers right now work with the mentality of it works, and if it doesn’t, nobody’s gonna be hurt. Which leads me to my next point:
    3. The IT Industry is still not taken seriously: Not by the top management that consider IT as an expense, not by the programmers (reason mentioned above), and not by the IT managers themselves who try their best to get the biggest budget and spend it all to get an even bigger budget next year. Even a mistake in the IT industry that costs millions of dollars is considered to be a bug (you can’t expect programmers to be perfect is what you hear in this case) and is forgivable (it’s like nursing babies), while a wrong calculation in construction with the same disastrous effects can be the subject of newspapers of weeks. An example was the Y2K bug (how many billions were spent because someone made a decision of using 2 digits). Accountability is low in IT.
    4. IT Managers just don’t like Project Managers, and vice versa. Unless you’re the project manager and the IT manager at the same time, don’t expect to get anything done without some politics involved.

    PS: I published an article on why IT projects fail offering a different perspective than mine.

  • http://www.pmhut.com PM Hut

    I can give you many reasons why IT project delivery is not getting better:

    1. Maturity: The IT industry is still not mature enough, compare it to the construction industry that is thousands of years old.
    2. Quality of the Programmers: The quality of the programmers is definitely not even remotely comparable to the quality of programmers until the early 90s. Programmers right now work with the mentality of it works, and if it doesn’t, nobody’s gonna be hurt. Which leads me to my next point:
    3. The IT Industry is still not taken seriously: Not by the top management that consider IT as an expense, not by the programmers (reason mentioned above), and not by the IT managers themselves who try their best to get the biggest budget and spend it all to get an even bigger budget next year. Even a mistake in the IT industry that costs millions of dollars is considered to be a bug (you can’t expect programmers to be perfect is what you hear in this case) and is forgivable (it’s like nursing babies), while a wrong calculation in construction with the same disastrous effects can be the subject of newspapers of weeks. An example was the Y2K bug (how many billions were spent because someone made a decision of using 2 digits). Accountability is low in IT.
    4. IT Managers just don’t like Project Managers, and vice versa. Unless you’re the project manager and the IT manager at the same time, don’t expect to get anything done without some politics involved.

    PS: I published an article on why IT projects fail offering a different perspective than mine.

  • Pingback: Learning from the weak signals of failure | IT Project Failures | ZDNet.com()

  • cornercuttin

    weak signals are not often caught because no one has made it a priority to look for them. i think that, if top-level/executive management made it very clear that they will not accept a project manager who lies or misleads about project status, weak signals would be sought after continuously.

    in the end, even if weak signals are caught, documented and discussed, it doesn’t amount to anything if no action is changed. if a project is lagging, will top-level management actually change the release data (what happens if this release date is contractually set?)? will management actually bring in more resources to solve the problems that are occupying to much time/resources within the project?

    i have been to status meetings and said that my project is doomed and hasn’t budged in weeks/months due to the fact that 3rd party software hasn’t been shipped/configured, due to the fact that i am putting out fires in other builds/software, or other reasons. i’ve seen others be as honest as i was. but nothing happened. management says to just keep working on what you have, knowing full well nothing will change by the next status update.

    recognizing weak signals is easy. actually force management to do their job, and have them manage stuff. project managers should [often] go around the team lead and talk to developers directly. department directors should skip their project managers and go to the developers directly.

    i would be interested to see you write an article about what to do once weak signals are captured and recognized.

  • cornercuttin

    weak signals are not often caught because no one has made it a priority to look for them. i think that, if top-level/executive management made it very clear that they will not accept a project manager who lies or misleads about project status, weak signals would be sought after continuously.

    in the end, even if weak signals are caught, documented and discussed, it doesn’t amount to anything if no action is changed. if a project is lagging, will top-level management actually change the release data (what happens if this release date is contractually set?)? will management actually bring in more resources to solve the problems that are occupying to much time/resources within the project?

    i have been to status meetings and said that my project is doomed and hasn’t budged in weeks/months due to the fact that 3rd party software hasn’t been shipped/configured, due to the fact that i am putting out fires in other builds/software, or other reasons. i’ve seen others be as honest as i was. but nothing happened. management says to just keep working on what you have, knowing full well nothing will change by the next status update.

    recognizing weak signals is easy. actually force management to do their job, and have them manage stuff. project managers should [often] go around the team lead and talk to developers directly. department directors should skip their project managers and go to the developers directly.

    i would be interested to see you write an article about what to do once weak signals are captured and recognized.

  • Pingback: Using Weak Signals to Detect Troubled Projects — CIO Dashboard()

  • Pingback: The Best Project Management Techniques You’re Not Using — CIO Dashboard()

  • Pingback: Twelve early warning signs of IT project failure()

  • Pingback: Twelve early warning signs of IT project failure | O-I Newswire()